← Blog · May 18, 2026 · email, security

SPF, DKIM, and DMARC: The Email Auth Stack in 10 Minutes

SMTP was designed in 1982 with the trust model of "everyone who has a mail server is a reasonable person." Forty-plus years later, the spam war has been fought through three TXT records bolted on top: SPF, DKIM, and DMARC. Here's what each one actually does and how they fit together.

SPF — "who is allowed to send from this domain"

SPF (Sender Policy Framework, RFC 7208) is a TXT record on your domain that lists the IP addresses and other domains permitted to send mail with your domain in the envelope-from. A receiving mail server looks up the SPF record, checks whether the connecting IP is in it, and pass/fail/softfails accordingly.

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.5 include:_spf.google.com ~all"

The big gotcha: SPF only checks the envelope-from (the MAIL FROM), not the visible From: header. A phisher can writeFrom: ceo@yourcompany.com in the header while using their own envelope domain. SPF won't catch it. That's a job for DMARC.

SPF also caps at 10 DNS lookups. Stacking too manyinclude: mechanisms (Google + Mailchimp + SendGrid + …) will blow that limit and SPF will silently fail. The SPF builder warns you when you cross 10.

DKIM — "this message is cryptographically signed"

DKIM (DomainKeys Identified Mail, RFC 6376) signs each message with a private key held by the sending server. The signature lives in a DKIM-Signature:header and includes a hash of the body and selected headers. The corresponding public key sits in a TXT record at <selector>._domainkey.example.com.

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

The receiver fetches the public key, verifies the signature, and now has cryptographic proof that (1) the body wasn't tampered with in transit and (2) it was signed by a key that the claimed domain controls. Where SPF is "is this IP allowed," DKIM is "is this signature valid."

DMARC — "what should the receiver do when SPF or DKIM fail"

DMARC (RFC 7489) sits on top of SPF and DKIM. It does two things:

  1. Tells the receiver what to do with mail that fails alignment (none / quarantine / reject).Alignment means the domain shown in the visible From: header matches the domain SPF or DKIM authenticated. This is the gap SPF alone leaves open.
  2. Asks the receiver to send aggregate reports back to you — daily XML files atrua= showing pass/fail counts per source IP. This is invaluable.
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; aspf=r; adkim=r"

The first time you turn DMARC on with p=reject, expect to break something — usually a forgotten SaaS that sends invoices on your behalf. Always start at p=none and watch reports.

The rollout order that actually works

  1. Week 0: publish SPF with all your senders, ending in ~all (softfail).
  2. Week 0: enable DKIM on every legitimate sending source. Most providers (Google, Microsoft 365, Mailchimp, SendGrid) give you DKIM keys to add.
  3. Week 1: publish DMARC with p=none; rua=mailto:dmarc@example.com. Just monitor.
  4. Week 2-4: review aggregate reports daily. Fix any legitimate sources that aren't aligned.
  5. Week 4-8: move to p=quarantine; pct=10, then ramp to pct=100.
  6. Week 8+: move to p=reject. You're done.

Skip the monitoring phase and you'll cut off your own marketing emails the day you turn on p=reject. The aggregate reports are not optional.

What about BIMI, ARC, MTA-STS?

Three newer add-ons round out the picture:

Related tools

← All blog posts