Email authentication has a reputation for being fiddly, mostly because the three mechanisms are usually explained together as if they were one thing. They are not. Each answers a different question, and understanding which question is which makes the setup obvious.
SPF: which servers are allowed to send for me?
Sender Policy Framework is a list, published in DNS, of the servers permitted to send email using your domain. A receiving server looks at where the message came from, looks up your SPF record, and checks whether that source is on the list.
It is a single TXT record on your domain:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~allTwo things trip people up. First, you may only have one SPF record. If you publish a second, the whole check fails — they are not combined. Merge every sending service into one record using include:.
Second, there is a hard limit of ten DNS lookups when evaluating the record. Each include: costs at least one, and includes can nest. Exceed ten and the result is a permanent error, which most receivers treat as a failure. Agencies that have accumulated sending tools over the years hit this constantly.
The final mechanism matters too: ~all is a soft fail (treat unlisted senders as suspicious), -all is a hard fail (reject them). Start with ~all.
DKIM: was this message altered in transit?
DomainKeys Identified Mail attaches a cryptographic signature to each outgoing message. Your sending server signs with a private key; you publish the matching public key in DNS. The receiver recomputes the signature and confirms the message is unmodified and genuinely from a system holding your key.
The public key lives at a selector subdomain, which lets you run several keys at once:
selector1._domainkey.yourdomain.com TXT v=DKIM1; k=rsa; p=MIGfMA0GCSq...Separate selectors per sending service is the right pattern — it means rotating or revoking one service's key does not disturb the others.
DKIM has one important advantage over SPF: it survives forwarding. When a message is forwarded, the source server changes and SPF breaks, but the signature travels with the message and still validates.
DMARC: what should happen when those checks fail?
DMARC is the policy layer. It does three things: it requires that SPF or DKIM not merely pass but align with your visible domain, it tells receivers what to do when that fails, and it asks them to send you reports.
_dmarc.yourdomain.com TXT v=DMARC1; p=none; rua=mailto:[email protected]; fo=1The p= value is the policy: none (monitor only), quarantine (treat as suspicious), or reject (refuse outright).
Alignment is the part that catches people out
This is the concept worth reading twice. A message can pass an SPF check and still fail DMARC.
Suppose a third-party platform sends on your behalf. The envelope sender is [email protected], and SPF validates their domain successfully. But the recipient sees [email protected] in the From header. Those two domains do not match, so there is no alignment, and DMARC fails despite SPF passing.
The fix is to authenticate your own domain with the platform rather than accepting their defaults — which is exactly why any sending tool worth using asks you to add DNS records instead of letting you send immediately.
The rollout order that avoids breaking things
- Publish SPF and DKIM first. Get both passing for every legitimate sending source you know about.
- Publish DMARC at
p=none. This changes nothing about how your mail is handled, but starts the reports flowing. - Read the reports for two to four weeks. You will find sending sources you had forgotten — an invoicing system, a helpdesk, a marketing tool a colleague signed up for. Authenticate each one.
- Move to
p=quarantine. Watch for a fortnight. - Move to
p=reject. Now nobody can spoof your domain.
Publishing p=reject immediately is the classic mistake. It works, in the sense that it stops spoofing. It also stops your own forgotten systems, and you find out when someone asks why the invoices stopped arriving.
Failure modes worth recognising
| Symptom | Likely cause |
|---|---|
| SPF passes, DMARC fails | Alignment — SPF validated the platform's domain, not yours |
| SPF permerror | More than ten DNS lookups, or two SPF records published |
| DKIM fails after forwarding | A mailing list modified the message body or headers |
| Authentication fine, still filtered | Authentication is necessary, not sufficient — check volume, engagement and complaint rate |
Authentication is the floor, not the ceiling
Getting all three passing does not guarantee inbox placement. It removes a reason to filter you; it does not create a reason to trust you. Reputation, recipient engagement and complaint rate decide the rest. But without authentication, none of that gets a chance to matter — the message is judged before anyone reads it.