Email Authentication in Practice: When SPF, DKIM, and DMARC Pass and When They Fail

Most email authentication guides explain what SPF, DKIM, and DMARC are. This article explains when they fail — and why. Understanding failure scenarios is essential for troubleshooting deliverability problems and configuring your email infrastructure correctly.

If you need the basics first, start with The Complete Guide to Email Authentication.

SPF: passes and failures

When SPF passes

The sending server's IP address is listed in the sender domain's SPF record. Straightforward: authorized server, authorized to send.

When SPF fails: forwarding

This is the #1 cause of SPF failure for legitimate email. When an email is forwarded through an intermediary (mailing list, email alias, corporate forwarding rule), the forwarding server's IP is not in the original sender's SPF record.

Example flow:

1. Sender (gmail.com) sends to your alias (alias@cleanbox.me)
2. Cleanbox forwards to your mailbox (you@outlook.com)
3. Outlook checks SPF: "Is the Cleanbox server in gmail.com's SPF?" → No → SPF fail

This is why SRS (Sender Rewriting Scheme) exists — it rewrites the envelope sender so SPF checks against the forwarding service instead of the original sender.

When SPF fails: too many DNS lookups

SPF allows a maximum of 10 DNS lookups. Each include: in your SPF record counts as one lookup, and each included record may contain further includes. Exceeding 10 causes a permerror — permanent SPF failure for every email from your domain.

Common scenario: you use Google Workspace (include:_spf.google.com), Mailchimp (include:servers.mcsv.net), SendGrid (include:sendgrid.net), Cleanbox (include:_spf.cleanbox.to), and a CRM — five includes that may expand to 12+ lookups.

Fix: use SPF flattening tools that replace nested includes with direct IP ranges, or consolidate sending services.

When SPF fails: wrong "from" alignment

SPF checks the envelope sender (Return-Path), not the From header. If your ESP sends with an envelope sender on their domain (e.g., bounce.sendgrid.net) but the From header shows your domain, SPF passes for sendgrid.net but does not align with your domain for DMARC purposes.

DKIM: passes and failures

When DKIM passes

The DKIM signature in the email headers is cryptographically valid — the email content has not been modified since the sender signed it, and the public key in DNS matches.

When DKIM fails: content modification

Any change to the signed headers or body invalidates the signature:

• Mailing lists adding footers ("To unsubscribe from this list...")
• Email gateways adding disclaimers
• Virus scanners modifying attachments
• Forwarding services rewriting headers

When DKIM fails: key rotation

The sender rotated their DKIM key (published a new public key in DNS) but the email was signed with the old key. During the transition period, emails signed with the old key fail verification. Best practice: keep the old key active in DNS for 24-48 hours after rotation.

When DKIM fails: missing DNS record

The DKIM selector in the email header points to a DNS record that does not exist (typo, deleted, wrong domain). No key = no verification = DKIM fail.

DMARC: passes and failures

When DMARC passes

Either SPF or DKIM must pass and align with the From domain:

• SPF alignment: The envelope sender domain matches (or is a subdomain of) the From domain
• DKIM alignment: The DKIM signing domain (d=) matches (or is a subdomain of) the From domain

When DMARC fails: forwarding (the big one)

Forwarded email often fails both SPF (wrong server) and DKIM (modified content). If both fail alignment, DMARC fails. With p=reject, the email is bounced. Legitimate email, lost.

This is why strict DMARC rejection is not always right — it breaks email forwarding, mailing lists, and alias services.

When DMARC fails: third-party senders without alignment

You use a marketing platform that sends from their own domain (envelope sender = ESP domain) without DKIM-signing with your domain's key. SPF passes for their domain, not yours. DKIM signs with their domain, not yours. Neither aligns with your From domain. DMARC fails.

Fix: configure custom DKIM signing in your ESP (most support this) so the d= value matches your domain.

Real-world scenarios

Scenario	SPF	DKIM	DMARC	Outcome
Direct email, properly configured	Pass + aligned	Pass + aligned	Pass	Delivered
Email forwarded through alias	Fail (wrong server)	Pass (unmodified)	Pass (DKIM aligned)	Delivered (DKIM saves it)
Mailing list adds footer	Fail (wrong server)	Fail (content modified)	Fail	Rejected if p=reject
ESP without custom DKIM	Pass (ESP domain)	Pass (ESP domain)	Fail (no alignment)	May go to spam
Phishing from lookalike domain	Pass (own SPF)	Pass (own DKIM)	N/A (different domain)	Passes auth but caught by content analysis
SPF with 11+ lookups	Permerror	May pass	Depends on DKIM	Unreliable delivery

How to diagnose authentication failures

1. Check the Authentication-Results header — Every receiving server adds this. Look for spf=, dkim=, dmarc= verdicts. See How to read email headers.
2. Check the spam report in Cleanbox — Symbols like R_SPF_FAIL, R_DKIM_REJECT, DMARC_POLICY_REJECT tell you exactly what failed. See How to read a spam report.
3. Test with mail-tester.com — Send a test email and get a detailed authentication report.
4. Check DMARC reports — If you have rua= in your DMARC record, you receive daily reports showing which IPs sent email for your domain and whether they passed or failed.

For Cleanbox Relay users: Cleanbox handles SPF alignment via SRS and preserves DKIM signatures when forwarding. Authentication failures from the original sender are captured in the spam symbol rules, where you can choose to reject or accept them per domain.