dnsprobe v1

SPF, DKIM, DMARC: a postman's guide to email authentication

· ~3 min read · dnsprobe.net/blog

Email was designed in 1981 with zero authentication. Anyone could send a message claiming to be anyone — and forty years later, most of the spam ecosystem is still built on that fact. SPF, DKIM and DMARC are the three TXT records that retrofitted authentication onto SMTP without breaking backwards compatibility. They are independent assertions and they only become useful when you understand how a receiving server combines them.

SPF — the IP allowlist

example.com.    300    IN    TXT    "v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all"

SPF answers one question: "which IP addresses are allowed to send mail on behalf of this domain?" The receiver looks at the SMTP envelope sender (MAIL FROM) — not the visible From header — extracts the domain, looks up its SPF record, and checks whether the connecting IP matches.

The terminator at the end matters:

  • -all: hard fail. Anything not listed should be rejected.
  • ~all: soft fail. Anything not listed is suspicious but accept it.
  • ?all: neutral. Pointless; don't use it.
  • +all: pass everything. Catastrophic; never use it.

Two limits people hit: SPF allows at most 10 DNS lookups for the resolution of the entire policy (RFC 7208 §4.6.4). Stacking include: directives for every SaaS sender will blow the limit, the receiver will return PermError, and your DMARC will fail. The fix is record flattening — substitute include: chains with the actual ip4:/ip6: lists, either manually or via a managed SPF service.

DKIM — the cryptographic signature

DKIM signs the message body and selected headers with a private key. The receiver fetches the corresponding public key from DNS at <selector>._domainkey.<domain>, verifies the signature, and learns that this message was signed by someone with access to that key, and the signed content was not modified in transit.

selector1._domainkey.example.com. 300 IN TXT
    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

The selector is just a label — it lets you rotate keys without invalidating old in-flight messages. You publish the new selector, the new signed messages start arriving, and eventually you retire the old selector by removing the record.

Where DKIM bites: any mail-list software, forwarder, or anti-spam system that modifies the message body or the Subject header (adding "[LIST]" prefixes is the classic offender) will break the DKIM signature. That message will now fail DKIM at the receiver.

DMARC — the policy and reporting layer

_dmarc.example.com. 3600 IN TXT
    "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; pct=100; aspf=s; adkim=s"

DMARC asks: "I see this message claims to be from example.com in the From header. Does the SPF result or the DKIM result align with that From domain?"

Alignment is the subtle bit. A message can pass SPF (the envelope sender's domain has an SPF record that allows the connecting IP) but fail DMARC, because the envelope sender domain is bounces.mailgun.org while the header From is example.com. The two are not aligned, so DMARC does not credit the SPF pass to example.com. Same for DKIM: the signature has to be from example.com (or a configured subdomain, depending on adkim) to count.

The three policies, from least to most strict:

  1. p=none: monitor only. Receivers report results but take no action. Always start here.
  2. p=quarantine: failing messages go to spam.
  3. p=reject: failing messages are rejected at SMTP time. The sender gets a bounce.

The standard rollout: publish p=none with a rua= reporting address, ingest the aggregate XML reports for a few weeks, identify every legitimate sender that is failing alignment (you will be surprised — old marketing platforms, your billing system, anything that uses a third-party for transactional mail), fix or authorise each one, then move to p=quarantine, then p=reject.

Inspecting it

To audit your own setup, you want to see all three TXT records in one view. dnscheck shows TXT propagation across all 12 resolvers per record. Try google.com to see SPF and DMARC published consistently. For policy parsing, Cloudflare's DMARC validation reference and RFC 7489 (DMARC) are the source of truth.

Final reality check: SPF, DKIM and DMARC together do not make you trusted. They make you auditable. Receivers still apply their own reputation scoring on top. But without them, you have no chance of reliable inbox delivery in 2026.