CertaDNS

Email authentication: SPF, DKIM and DMARC

How SPF, DKIM and DMARC decide whether a message claiming to be from your domain gets delivered.

Anyone can put your domain in the From: header of an email. SMTP has no opinion about it and never has — the protocol was designed in an era when that was not a problem worth solving. Everything below is the retrofit.

Three protocols, each answering a different question, plus a fourth that ties them to the address a person actually sees. Most of the trouble people have comes from not knowing which one is failing, or from assuming a pass in one place counts somewhere it does not.

What each one does

Question it answersWhere it livesSurvives forwarding?
SPFIs this server allowed to send for this domain?A TXT record at the domain apexNo — the forwarder connects from its own IP
DKIMWas this message signed by a key this domain published?A TXT record at selector._domainkeyUsually — the signature travels with the message
DMARCDo either of those results actually belong to the visible sender, and what should I do if not?A TXT record at _dmarc—

The third row is the one to read twice. DMARC is not a third authentication mechanism; it is a policy layer over the first two. Its actual contribution is alignment — the requirement that a passing result belong to the domain in the From: header, rather than to whatever domain happened to be in the envelope.

How a message is evaluated

1.  Connection from 203.0.113.5, MAIL FROM: <bounce@mail.example.com>
      → SPF checks 203.0.113.5 against mail.example.com's SPF record
      → result: pass, for mail.example.com

2.  DKIM-Signature: d=example.com; s=selector1; …
      → fetch selector1._domainkey.example.com, verify the signature
      → result: pass, for example.com

3.  From: billing@example.com
      → DMARC asks: did anything pass AND align with example.com?
      → SPF passed for mail.example.com  — aligns under relaxed
      → DKIM passed for example.com      — aligns under either
      → DMARC: pass
The same message under strict alignment would rely on DKIM alone, because mail.example.com is not an exact match for example.com.

Only one has to align

DMARC passes if either SPF or DKIM passes and aligns. That redundancy is deliberate and it is why DKIM matters even on a domain with a perfect SPF record — SPF cannot survive forwarding, so on a forwarded message DKIM is the only one left.

Where to start

In order, and each step is genuinely a prerequisite for the next:

StepWhy it comes here
Publish SPFCheapest, and it is the first thing every receiver checks. Even a domain that sends no mail should publish v=spf1 -all.
Enable DKIM on every senderThe one that survives forwarding. Also the one most often half-done — enabled at the main provider and nowhere else.
Publish DMARC at p=none with ruaNot protection. It is how you find out who sends as you, which is the information the next step depends on.
Read the reports and fix what failsThe actual work. Everything else is minutes; this is weeks.
Move to enforcementOnly now is it safe. The record is one edit — the readiness is not.

There are two further layers once that is done — MTA-STS for transport encryption and BIMI for inbox branding — but both depend on DMARC being at enforcement first, so neither is worth starting early.

In this section

The SPF 10-lookup limit, and the void lookup limit nobody mentionsWhy SPF caps DNS lookups at ten, what actually counts toward it, the separate two-void-lookup limit in the same section of RFC 7208, and what to do when you hit either.DMARC alignment: why mail passes SPF and DKIM and still failsAlignment is the step between "SPF passed" and "DMARC passed". How relaxed and strict modes differ, which domain each protocol actually authenticates, and why a forwarded message behaves differently.Getting from p=none to p=reject without blocking your own mailA staged path to DMARC enforcement driven by what your aggregate reports actually show, including how long each stage needs and the signals that say you are not ready to advance.Why your DMARC reports never arrive: external destination authorisationRFC 7489 §7.1 requires the domain receiving your DMARC reports to authorise yours. Without that record, conforming receivers drop the reports silently — the record looks perfect and produces nothing.SPF flattening: what it fixes, what it breaks, and when to use itFlattening replaces includes with literal IP ranges to get under the lookup limit. It works, and it converts a hard failure into a silent one unless it is automated. The trade-off, stated honestly.Why legitimate mail fails DMARCThe eight causes that account for most unexplained DMARC failures, what each looks like in an aggregate report, and how to tell them apart before you tighten a policy.

Check your own domain

Free, no account. Or run the full Domain Trust scan to see all of it at once.

SPF InspectorDKIM InspectorDMARC Inspector