For anyone whose domain sends email
DMARC, SPF and DKIM — can someone send email as you?
Three records decide whether a stranger can put your domain in the From line of a convincing message. A gap in any one of them is what makes impersonation work.
SPF, DKIM and DMARC are the three records that decide whether someone can send email that appears to come from your domain. They work together, and a gap in any one of them is what makes convincing impersonation possible. This page explains what each does, what the common failure modes are, and how to close them without breaking your own mail.
What the three records actually do
They answer three different questions, which is why publishing only one leaves a gap. SPF says which servers are allowed to send for your domain. DKIM adds a signature proving a message was authorised and has not been altered. DMARC ties the two to the address a recipient actually sees, and tells receiving systems what to do when the checks fail.
- SPF — the list of permitted senders
- DKIM — the cryptographic signature on each message
- DMARC — the policy applied when SPF and DKIM do not line up
Why DMARC policy is the part that matters
A DMARC record can ask receiving systems to do nothing, to treat failures with suspicion, or to reject them outright. Publishing a record that asks for nothing is common and is often mistaken for being protected: the record exists, reports may be arriving, and yet nothing is actually being stopped. Moving to enforcement is what closes the door on spoofing, and it is also the step most likely to disrupt legitimate mail if taken too quickly.
- A monitor-only policy protects nobody on its own — it is a starting point, not a destination
- Move in stages, watching reports for senders you had forgotten about
- Newsletters, ticketing systems, CRMs and payroll tools all send on your behalf and all need to pass
The failure modes that catch people out
Most email-authentication problems are not exotic. They are the result of a record written years ago that no longer matches how the organisation sends mail.
- SPF records that grew past the standard's ten-DNS-lookup limit, at which point the record stops being evaluated and legitimate mail starts failing
- Old suppliers still authorised long after the contract ended, quietly widening who can send as you
- DKIM configured on the main platform but not on the marketing or ticketing tools
- A DMARC record covering the main domain while subdomains are left open
- Records published correctly and then undone by a DNS migration nobody re-checked
What this check looks at
Everything here is read from public DNS. Nothing is sent, received or intercepted, and no mailbox is touched.
- Whether an SPF record exists, and how many DNS lookups it requires
- Whether DKIM signing is configured and discoverable
- Whether a DMARC record exists and what policy it asks receivers to apply
- MTA-STS, which asks other mail systems to use encrypted delivery to you
- Supporting records that indicate how carefully the domain's mail is managed
A sensible order to fix things in
Publish SPF and DKIM first and confirm your genuine mail passes both. Only then add DMARC in monitoring mode, read what the reports tell you for a few weeks, and tighten once the list of legitimate senders is complete and passing. Rushing to enforcement before that is the main reason organisations lose real mail and roll the whole thing back.
- Get SPF and DKIM correct before touching DMARC policy
- Expect to discover senders nobody remembered authorising
- Do not forget subdomains, including ones you do not use
Common questions
›Is DMARC only relevant to large organisations?
No. Impersonation is easier and more damaging for smaller organisations, because recipients are more likely to act on an email that appears to come from a charity, a school or a supplier they know. The records cost nothing to publish.
›We have a DMARC record. Are we protected?
Only if it asks receiving systems to act. A record set to monitor only reports what is happening and stops nothing, which is a reasonable first step but is often mistaken for a finished job. The policy value is the part that matters.
›Why does our legitimate email fail SPF?
The most common causes are an SPF record that has grown past the standard's ten-DNS-lookup limit, and a sending service that was added to the platform but never added to the record. Both are fixable without changing how you send.
›Will tightening DMARC break our mail?
It can, if it is done before every legitimate sender passes. That is why the sequence matters: SPF and DKIM first, then DMARC in monitoring mode, then enforcement once the reports are clean. Taken in that order the risk is low.
›Does this check send any email?
No. It reads public DNS records only. Nothing is sent, received or intercepted, and no mailbox is accessed.
Advisory only. This is an external check of public DNS records. It reflects what those records say at the time of the check and cannot confirm how individual messages will be treated by every receiving mail system.
Also useful: checking a supplier before you sign.