SPF Fails but DKIM Passes in DMARC Reports

Why DMARC can pass anyway

The row looks wrong at first: SPF failed, DKIM passed, and DMARC may still say the message passed.

That can be correct. DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. It does not require both checks to pass.

Read the DMARC result first, then read the raw SPF and DKIM results below it. In RUA aggregate reports, the policy result tells you what DMARC decided. The authentication results tell you what the receiver saw for SPF and DKIM. Those are related, but they answer different questions.

SPF checks whether the connecting IP is allowed to send for the envelope sender domain, also called the Return-Path or MAIL FROM domain. DKIM checks a signed header on the message. DMARC then checks whether a passing SPF domain or a passing DKIM d= domain lines up with the From domain the reader sees.

• If DKIM passes with d=example.com and your visible From domain is example.com, DMARC can pass even when SPF fails.
• If SPF passes for a vendor bounce domain, but that domain does not align with your From domain, DMARC can treat SPF as failed.
• If both aligned SPF and aligned DKIM fail, DMARC fails. Your p=none, p=quarantine, or p=reject policy tells receivers what action you are asking for.

The usual causes

Most SPF fail plus DKIM pass rows come from bounce-domain alignment, forwarding, or an SPF record that is missing a real sender.

The most common cause is an unaligned Return-Path. Your newsletter may send From example.com, while the bounce address is under mail.vendor.net. SPF may pass for the vendor domain, but it does not help DMARC unless that domain aligns with your visible From domain. DKIM can still pass if the vendor signs with your domain or with a subdomain that aligns under relaxed DMARC alignment.

Forwarding is another common cause. SPF is tied to the IP that connects to the final receiver. When a message is forwarded, the forwarder's IP may be the one the final receiver checks, and that IP may not be in your SPF record. DKIM often survives forwarding because the original signature can stay valid when the signed headers and body are not changed.

Real SPF failures happen too. Your SPF record may be missing a sender, have more than one SPF TXT record, exceed the 10 DNS-lookup limit in RFC 7208, include a typo, or still name old vendors. ~all is softfail. -all is hardfail. Neither one fixes alignment by itself. The sender still has to be included and the SPF domain still has to align for DMARC.

DKIM passes when the message has a valid signature, the selector points to the right public key in DNS, and the signed content still matches. For DMARC, the DKIM d= domain must align with the From domain. Under relaxed alignment, the domains can share the same Organizational Domain. Under strict alignment, they must match exactly.

What to fix first

Fix alignment before changing policy. Then clean up the record behind the raw SPF failure.

• Find the source IP and sending service in the DMARC row. If you do not recognize it, treat it as suspicious until a real sender owner confirms it.
• Check the visible From domain. DMARC protects that domain.
• Check the DKIM d= domain. If it aligns with the From domain, DKIM can carry DMARC.
• Check the SPF domain. If it is a vendor bounce domain, ask the vendor how to set a custom Return-Path or bounce domain under your domain.
• Review your SPF record for missing includes, duplicate SPF records, DNS lookup count, typos, and old vendors.
• Keep DMARC at p=none while you map real senders. Move toward p=quarantine or p=reject only after normal mail passes with aligned SPF or DKIM.

If you want a plain read on the current DNS state, run the free domain scorecard. If you already have a RUA XML file, use the free DMARC report reader to turn rows into source names and fixes.

Will this send mail to spam?

A lone SPF failure does not automatically mean spam. A DMARC failure is a stronger warning.

Gmail, Outlook, and other mailbox providers look at authentication, alignment, domain reputation, complaint rate, sending patterns, content, and infrastructure reputation. Passing DKIM with aligned DMARC is a good sign, but it will not erase a poor sender reputation or a blocklist problem.

MX records matter for receiving mail and replies. They are not part of an SPF or DKIM pass. Still, broken mail routing, missing abuse handling, and messy DNS can make diagnosis harder when placement problems start.

Blocklists are separate from DMARC. A listed sending IP can land mail in spam even when SPF, DKIM, and DMARC pass. Fix authentication first because it is measurable. Then check reputation and list status if mail still lands in spam.

For the base rules, use RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC, plus the current Google and Microsoft sender guidelines. Receiver-side filtering changes over time, so those official sources beat copied checklist advice.

The SEO and AI crawler angle

DMARC reports are about mail. Search and AI answer visibility depend on crawl access and readable pages.

If you are checking deliverability because your site depends on search traffic, keep crawler rules separate. The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google, and Applebot for Apple Intelligence. Google AI Overviews use the normal Google Search index. There is no separate Google AI Overviews opt-out crawler.

Disallowing these live search crawlers in robots.txt removes you from that engine. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

Robots.txt is a stated site policy, not proof of what a crawler did. Perplexity-User and Bytespider have been reported to ignore it, so do not use robots.txt alone as evidence of behavior. Only Googlebot documents JavaScript rendering. Client-side-only content may be an undocumented risk for other AI crawlers, so put key content in readable HTML when visibility matters. The free AI visibility checker can help you review that setup.