SPF vs DKIM vs DMARC: what each one actually checks

Search results love to list SPF, DKIM, and DMARC as a set. That is fine as a headline and useless as a diagnosis. Each protocol answers a different question. Mixing them up is how you end up “fixing SPF” for a problem that was never about the sending IP.

The short version

Protocol	Question it answers	Where it lives
SPF	Is this sending IP allowed to use this domain in the envelope?	DNS TXT on the envelope-from domain
DKIM	Was this message signed with a key that domain published?	DNS TXT on a selector under the signing domain
DMARC	Did SPF or DKIM pass and align with the From header, and what should receivers do if not?	DNS TXT on _dmarc.yourdomain

Receivers check SPF and DKIM first. DMARC reads those results, applies alignment to the visible From address, then applies your policy (none, quarantine, or reject) and optionally sends you aggregate reports.

If you only need the alignment failure mode in depth, jump to DMARC alignment explained. If you are staring at rua XML, see How to read DMARC reports.

Why email needs authentication at all

SMTP was designed for a trusted network. The protocol does not prove that the person putting From: billing@yourcompany.com on a message is allowed to do that. Without SPF, DKIM, and DMARC, anyone who can open a connection can claim your domain. Phishing campaigns, fake invoices, and CEO-fraud mail all abuse that gap.

Mailbox providers (Gmail, Microsoft, Yahoo, and others) now expect domains that send real volume to authenticate. A missing or broken setup shows up as spam folder placement, soft fails, or hard bounces such as Gmail 550 5.7.26.

Authentication does not replace content filtering or account security. It removes one cheap attack: unauthorized use of your domain name in the From line.

SPF: the guest list for sending IPs

SPF (Sender Policy Framework) is a public list of hosts allowed to send mail that claims a given domain in the SMTP envelope (the Return-Path / Mail-From). The receiving server looks up that domain’s SPF record and asks whether the connecting IP is authorized.

A minimal record looks like:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Mechanisms such as include:, a, mx, ip4:, and ip6: name who is allowed. The final all qualifier (-all, ~all, or ?all) says what to do with everyone else.

Production details that bite

• Forwarding usually breaks SPF. The forwarder’s IP is not on your list, so SPF fails even when the original message was legitimate. That is why DKIM matters for mail that gets forwarded.
• You get one SPF record per domain. Multiple v=spf1 TXT records are invalid. Merge includes into a single record.
• There is a hard 10-lookup limit. Too many include: / a / mx / ptr / exists mechanisms and receivers treat the whole record as a permanent error. See SPF permerror: too many DNS lookups.
• SPF does not look at the visible From header. It evaluates the envelope domain. That is why an “SPF pass” can still fail DMARC.

When SPF alone is the wrong fix

If reports show failures from random consumer ISPs, adding another include: will not help. That pattern is usually spoofing. If failures come from a named ESP you just hired, SPF (and DKIM) for that ESP is the fix.

DKIM: a cryptographic signature on the message

DKIM (DomainKeys Identified Mail) attaches a signature to message headers (and usually selected body content). The receiving server fetches your public key from DNS (selector._domainkey.yourdomain) and verifies the signature with public-key cryptography.

You keep a private key in the sending system. DNS publishes the matching public key. If the bits still match at the receiver, the message was signed by someone who held that key, and the signed headers were not altered in transit in a way that breaks the signature.

Production details

• DKIM often survives forwarding because the signature travels with the message. When SPF fails after a forward, an aligned DKIM pass can still satisfy DMARC.
• The d= domain in the signature is what DMARC cares about for alignment, not merely “a valid signature exists somewhere.”
• Selector names matter. Many ESPs give you a DNS name like s1._domainkey.yourdomain pointing at their key. Publish exactly what they document.
• Proxying a DKIM CNAME (common when a DNS proxy is orange-clouded) can break lookups. Keep the DKIM hostname DNS-only unless your DNS host documents otherwise.
• Body length and encoding changes can invalidate signatures if a hop alters the message. That is rarer than missing selectors, but it shows up in broken marketing pipelines.

DMARC: alignment, policy, and reports

DMARC (Domain-based Message Authentication, Reporting, and Conformance) does not replace SPF or DKIM. It decides whether a pass counts for the identity the recipient sees, and what to do when nothing counts.

1. Alignment. An SPF or DKIM pass only helps DMARC if the authenticated domain matches the From domain (exact match, or organizational match under relaxed alignment). Details: DMARC alignment explained.
2. Policy. p=none monitors. p=quarantine asks receivers to treat failures as spam. p=reject asks them to refuse the message. Subdomain policy (sp=) can differ from the organizational domain.
3. Reporting. The rua= address receives aggregate XML reports so you can see who is sending as you, and whether those sends pass. Optional ruf= forensic reports are separate and often left off for privacy and volume reasons.

A starter monitor record looks like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Remember: pass ≠ aligned pass. That gap is why Gmail’s bulk-sender checks and many “authentication failed” bounces fire even when someone “has SPF set up.”

Policy progression that does not burn you

1. Publish SPF + DKIM for every real sender.
2. Publish DMARC at p=none with rua= and read reports for days or weeks.
3. Fix unaligned ESPs and unexpected sources.
4. Move to p=quarantine (sometimes with a percentage via pct= while you gain confidence).
5. Move to p=reject when legitimate mail is consistently aligned.

Jumping straight to p=reject without reports is how invoice mail disappears for a week.

How they work together on one message

A healthy path

1. Your ESP sends from an authorized IP (SPF pass) and signs with your domain’s key (DKIM pass).
2. Both results align with you@yourdomain.com in the From header.
3. DMARC sees at least one aligned pass, so the message is authenticated under your policy.
4. Aggregate reports later show that source as passing, so you can move from p=none toward enforcement with less guesswork.

Common failure paths

• New SaaS tool: sends as your domain, SPF never got an include:, DKIM never enabled for your domain. DMARC at p=none so mail still lands while reports show failures.
• Alignment-only failure: ESP SPF/DKIM pass on the ESP’s domain, From shows your brand, DMARC fails. Fix custom DKIM / aligned envelope, not more SPF includes at random.
• Forwarding: SPF fails, aligned DKIM passes, DMARC still passes. Without DKIM, forwarding looks like failure.
• Enforcement too early: policy already reject, a forgotten CRM starts sending, customers call because messages bounce.

How to check your domain today

1. Run the free DMARC checker on your domain.
2. Run the SPF checker and DKIM checker for pieces that look wrong.
3. Confirm every sending system is represented in SPF and signing DKIM for your domain.
4. Publish DMARC at p=none with reporting if you do not have it yet, then read reports before tightening. How to read DMARC reports covers what matters in the XML.

Email Watch ingests those aggregate reports and separates spoofing from your own broken senders in the UI so you are not reading raw XML by hand. It does not send or block mail for you; receivers apply your published DMARC policy.