Why DMARC Fails When SPF and DKIM Pass

The short answer: one pass must align

A sender can show two green checks for SPF and DKIM, then still fail DMARC. The missing piece is domain alignment.

DMARC checks the domain in the visible From address, the one a person sees in the message. Then it looks for at least one passing authentication result that lines up with that From domain.

SPF authenticates the envelope sender domain, often shown as Return-Path, MAIL FROM, or smtp.mailfrom. DKIM authenticates the signing domain in the signature's d= tag. DMARC passes when SPF or DKIM passes and that passing domain aligns with the visible From domain.

Example: the message says From: hello@example.com. SPF passes for bounces.mailer.example.net, and DKIM passes for mailer.example.net. Both checks passed, but neither domain aligns with example.com. DMARC fails.

Relaxed alignment is the DMARC default. A subdomain can align with its parent organizational domain, such as mail.example.com with example.com. Strict alignment, set with aspf=s or adkim=s, requires the domains to match exactly.

Read the headers first

Do not start by changing DNS. Start with one real failed message and read the authentication results.

• Find the visible From domain. This is the domain after the @ in the sender address people see.
• Find the SPF result and the domain SPF authenticated. Look for Return-Path, MAIL FROM, or smtp.mailfrom.
• Find the DKIM result and signing domain. Look for dkim=pass and header.d or d=.
• Compare those domains with the visible From domain. If neither passing domain aligns, DMARC fails.
• Check the DMARC record for strict mode. aspf=s and adkim=s make alignment tighter.

For the exact rules, use the published specs as the source of truth: RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. For mailbox placement, check the current Google and Microsoft sender guidelines because providers can add their own requirements.

If you want a quick outside check before digging through headers, run the domain through the free scorecard. It can catch common record problems, but the headers tell you which domain actually passed.

Fix the cause you see

Most of these failures happen because a mail platform authenticates with its own domain instead of yours.

If SPF passes for the wrong domain, set up a custom bounce domain in your email platform. Providers may call this custom MAIL FROM, custom envelope sender, or custom Return-Path. Use a subdomain you own, such as bounce.example.com, and publish the DNS records the provider gives you.

If DKIM passes for the wrong domain, add the provider's DKIM selector records under your domain and enable signing for your domain. The DKIM signature should use a d= domain that aligns with the visible From domain.

If alignment looks right in your sending tool but the header still shows DMARC failure, check forwarding and mailing lists. Forwarding often breaks SPF because the forwarder is the server that connects to the final mailbox. DKIM can survive forwarding when the signed headers and body are not changed. List footers, subject tags, and body edits can break the signature.

If SPF returns a permanent error, simplify the record. SPF has a 10 DNS-lookup limit across lookup mechanisms such as include, a, mx, ptr, and exists. Too many nested includes can break SPF. Keep one SPF record, use ~all while you are still finding senders, and move toward -all after every real sender is covered.

Pick a DMARC policy after alignment works

DMARC policy does not make mail align. It tells receivers what you ask them to do when DMARC fails.

A p=none policy is for watching. Mail can still flow, and aggregate reports show which sources are sending as your domain. A p=quarantine policy asks receivers to treat failing mail as suspicious. A p=reject policy asks them to reject failing mail.

Start with p=none and a rua=mailto: address so you can review aggregate reports. Move to quarantine or reject after normal senders pass DMARC. If the XML reports are hard to read, use the free DMARC report reader.

MX records do not make DMARC pass. They matter because a domain that can receive replies, bounces, and reports is easier to operate cleanly. For deliverability, Gmail, Outlook, and other mailbox providers also look at complaints, engagement, sending patterns, IP and domain reputation, blocklists, content, and whether recipients asked for the mail.

When DMARC passes but spam continues

A DMARC pass helps prove the message is allowed to use your domain. It does not guarantee inbox placement.

• Keep exactly one SPF record for the domain.
• Keep old DKIM selectors live long enough for messages already sent to finish delivery.
• Watch DMARC aggregate reports for unknown sources and sudden drift.
• Check major blocklists when a drop is sudden and broad.
• Use a working site, clear sender identity, and a real unsubscribe path for bulk mail.

For a broader spam checklist, see the related guides at InboxRadar guides.

If AI answers need to read the page

If you publish a help page about the fix, make sure the answer engines can reach the text.

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 AI Overviews, and Applebot for Apple Intelligence. Google AI Overviews ride the normal Search index, with no separate opt-out crawler. Disallowing these 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 site's stated policy, not proof of crawler behavior. Perplexity-User and Bytespider have been reported to ignore it, so do not claim a bot obeyed or ignored the file from policy alone. Only Googlebot documents JavaScript rendering. If the main content is client-side-only, treat visibility in other AI answer engines as an undocumented risk and render the key text in plain HTML. You can test crawl access with the AI visibility checker.

For crawler policy details, check the vendor docs from OpenAI, Anthropic, Perplexity, Google, Apple, and Common Crawl. Those docs are the right source when user-agent names or robots controls change.