August 14, 2026 · 3 min read
SPF, DKIM and DMARC, explained by what actually breaks
Three records, three different jobs. Here is what each one does, and the specific ways each one silently fails.
Most explanations of these three start with what they stand for. That is the least useful part. What matters is which one is failing when your mail lands in spam, and they fail in different ways.
SPF says which servers may send
SPF is a DNS record listing the servers allowed to send for your domain. A receiver checks the connecting server against that list.
How it silently fails: SPF checks the domain in the envelope sender — the MAIL FROM — not the From: header your recipient sees. If you send through a provider that uses its own bounce domain, SPF passes for the provider's domain, and your domain has authenticated nothing. Everything looks fine in a header dump. DMARC still fails, because SPF did not align.
This is why a proper setup gives you a bounce subdomain of your own, like bounce.mail.yourcompany.com, with its own SPF record. Then SPF passes and aligns.
The other one that catches people: SPF allows ten DNS lookups. Each include: counts, and each include: inside those counts too. Add a fourth or fifth vendor and you quietly cross the limit; receivers then treat SPF as permanently failing. Nothing tells you.
DKIM says the message was not altered
DKIM signs the message with a private key. The matching public key sits in your DNS, and the receiver verifies the signature.
How it silently fails: a 2048-bit key does not fit in one DNS character-string, so it is always published split across several. Tools that read only the first chunk see a truncated key and report a mismatch, even though the record is correct. If you are debugging a DKIM failure and the key "looks wrong", check that whatever is reading it joins the parts.
The second failure mode is anything that modifies the message in flight. A mailing list that appends a footer breaks the signature it was signed with. So does a tracking system that rewrites links after signing rather than before.
DMARC says what to do when the first two fail
DMARC ties SPF and DKIM to the From: header your recipient actually reads, and tells receivers what to do when neither aligns: nothing (p=none), quarantine, or reject.
How it silently fails: publishing two DMARC records. It happens when two vendors each tell you to add one. Per RFC 7489, a receiver that finds more than one record treats the domain as having no DMARC policy at all. Both records are ignored. The domain looks configured, reports nothing, and enforces nothing.
If you use more than one sending service, you get one record with both reporting addresses:
v=DMARC1; p=none; rua=mailto:you@yourcompany.com,mailto:reports@vendor.example
The order to fix them in
- DKIM first. It survives forwarding, where SPF does not.
- SPF on a bounce domain you control, so it aligns rather than merely passing.
- DMARC at
p=none, and read the reports for a couple of weeks before tightening.
Going straight to p=reject is how people discover, in production, the one system that was sending as their domain and that nobody remembered.