SPF, DKIM, and DMARC: which one actually fixes deliverability?

SPF, DKIM, and DMARC are three separate DNS-based controls, and they are not interchangeable: SPF authorizes which servers may send for your domain, DKIM cryptographically signs each message, and DMARC ties either of those to the visible From address and tells receivers what to do when they don’t line up. None alone fixes deliverability — the working baseline that large mailbox providers now expect is SPF and DKIM both passing, plus a DMARC policy. Here is what each one actually proves and the order to deploy them.

SPF authorizes the senders

SPF (Sender Policy Framework) is a DNS TXT record listing which servers may send mail for your domain. The receiver checks the IP of the connecting server against that list and answers one question: “is this server allowed to send for this domain?” It says nothing about the message content.

Two constraints matter. First, SPF is evaluated against the return-path (the envelope sender), not the visible From — that distinction becomes important for DMARC alignment below. Second, SPF has a hard limit of ten DNS lookups during evaluation; include: mechanisms for stacked providers blow through it quickly, and once you exceed it SPF returns permerror and effectively fails. SPF also breaks on forwarding, because the forwarding server’s IP usually isn’t in your record.

DKIM proves the message

DKIM (DomainKeys Identified Mail) signs the message itself with a private key, proving it came from the signing domain and that the signed headers and body weren’t altered in transit. The receiver fetches the public key from DNS using the selector in the signature and verifies it. Unlike SPF, DKIM survives forwarding — the signature travels with the message and doesn’t depend on the connecting IP. SPF and DKIM are complementary: one checks the sender, the other checks the message. For the full mechanics, see DKIM explained.

DMARC enforces and reports

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of the other two. It does three things: it requires that SPF or DKIM not only pass but align with the visible From domain; it tells receivers what to do when a message fails (its policy); and it emails you aggregate reports of everyone sending as your domain. A DMARC record without SPF and DKIM underneath it does nothing — DMARC has no authentication of its own, it only enforces theirs.

Alignment is the part everyone misses

This is where most “but DKIM passes!” confusion lives. DMARC doesn’t care that SPF or DKIM passed on some domain — it cares that the passing domain matches the From address the recipient sees.

• SPF alignment — the return-path domain matches the From domain.
• DKIM alignment — the d= signing domain matches the From domain.

DMARC passes if at least one of the two both passes and aligns. So a message signed as amazonses.com can have a perfectly valid DKIM signature and still fail DMARC, because the signing domain isn’t your From domain. That is exactly the “via” problem: BYODKIM fixes it by setting d= to your own domain, and a custom return-path on your subdomain brings SPF into alignment too.

Side by side: what each one proves

The order to set them up

Deploy them in dependency order so you never enforce a policy before mail authenticates:

1. Publish SPF authorizing your real senders, under the ten-lookup limit.
2. Generate DKIM keys and publish the public key; enable signing.
3. Confirm both pass on test mail before touching DMARC.
4. Add DMARC at p=none — monitor-only — and read the aggregate reports.
5. Once every legitimate source passes and aligns, move to quarantine, then reject.

The full sequence, with the DNS records spelled out, is in the deliverability guide. Cherryrise handles SPF alignment, DKIM signing, and a custom return-path from two DNS records, so the alignment work above is done for you.

Common mistakes

• Jumping to p=reject first. Without a monitoring period you can blackhole your own legitimate mail. Start at none.
• Ignoring alignment. SPF and DKIM passing on a vendor domain feels like success but fails DMARC. The From domain is what has to match.
• Two SPF records. A domain must have exactly one SPF TXT record; a second one is a permerror, not an override.
• Blowing the ten-lookup limit. Every stacked include: counts; consolidate or flatten before you hit it.
• A vendor return-path. A return-path on the tool’s domain breaks SPF alignment and routes bounces somewhere you never read — see why support replies go to spam.

Frequently asked questions

Do I need all three of SPF, DKIM, and DMARC?

In practice, yes. SPF and DKIM are the two ways a message can authenticate, and DMARC is what makes that authentication mean something by requiring it to align with the visible From address and telling receivers what to do on failure. SPF or DKIM alone leaves gaps: SPF breaks on forwarding, and DKIM alone has no policy or reporting. The modern baseline — and what large mailbox providers expect from anyone sending at volume — is SPF and DKIM both passing, plus a DMARC record.

What does DMARC alignment actually mean?

Alignment means the domain that authenticated must match the domain in the From header the user sees. A message can pass SPF or DKIM on some unrelated domain and still fail DMARC if that domain is not the From domain. SPF aligns when the return-path domain matches From; DKIM aligns when the signing domain in the d= tag matches From. DMARC passes if at least one of the two both passes and aligns. This is why sending signed as a vendor’s domain fails DMARC even though DKIM itself passed.

What is the difference between p=none, quarantine, and reject?

They are the DMARC policy levels that tell receivers what to do with mail that fails DMARC. p=none means take no action but send reports — it is monitor-only and safe to start with. quarantine means deliver failing mail to spam or junk. reject means refuse it outright at the SMTP level so it never reaches the inbox. The intended path is none first to gather reports, then quarantine, then reject once you have confirmed all legitimate sources pass.

Why does SPF break when email is forwarded?

SPF checks the IP of the server delivering the message against the domain’s authorized senders. When a message is forwarded, the forwarding server’s IP is usually not in the original domain’s SPF record, so SPF fails at the final hop. DKIM survives forwarding because the signature travels with the message and does not depend on the connecting IP. This is a core reason to rely on DKIM and DMARC rather than SPF alone.