DKIM Pass but DMARC Fails? Fix Alignment

Why DKIM passes while DMARC fails

A green DKIM result can still leave the message failing DMARC. The signature is valid, but it may belong to the wrong domain.

DKIM proves that a message was signed with a private key that matches a public key published in DNS. The signing domain appears in the DKIM header as d=example.com. DMARC then compares that d= domain with the visible From domain your reader sees.

If your From address is you@brand.com, but DKIM signs with d=mailvendor.net, DKIM can pass and DMARC can fail. The signature is real, but it is aligned to the vendor domain, not your brand domain.

DMARC passes when either DKIM or SPF passes and aligns with the visible From domain. For DKIM alignment, the signing domain must match the From domain, or share the same organizational domain in relaxed mode. In strict mode, it must be the exact same domain.

The usual causes

Most alignment failures come from sender setup, not from a broken DMARC record.

• Your email provider is signing with its own domain instead of your domain.
• You published the DKIM record for one selector, but the sender is using another selector.
• Your marketing platform sends From brand.com while signing as esp.example.
• You rotated DKIM keys, but the sending service is still using the old selector.
• You send from a subdomain, such as news.brand.com, while DMARC is set to strict alignment for brand.com.

Read the full headers from a fresh test email. Find Authentication-Results. Look for lines like dkim=pass header.d=... and dmarc=fail. The header.d value is the DKIM signing domain. Compare it with the visible From domain.

How to fix DKIM alignment

The fix usually lives in the sending service. Changing DMARC policy only changes what receivers do after the check fails.

• Turn on branded or custom DKIM signing for the sender.
• Publish the DNS record the sender gives you. Google Workspace uses DKIM TXT records. Microsoft 365 commonly uses DKIM CNAME records. ESPs may use TXT or CNAME records.
• Use the exact selector host, such as selector1._domainkey.brand.com. Selectors are names. They are not interchangeable.
• Wait for DNS to publish, then verify or activate DKIM inside the sender.
• Send a new test message. Old messages keep their old headers.
• Confirm that dkim=pass and header.d=brand.com, or an aligned subdomain, appear in the result.

Do not weaken DMARC just to hide the symptom. A common monitoring record is v=DMARC1; p=none; rua=mailto:dmarc@brand.com. Use p=none while you find real senders, then move to quarantine or reject after they pass. A free domain scorecard can show which record is failing before you touch DNS.

Check SPF too

Aligned DKIM is the cleaner fix, but aligned SPF can also make DMARC pass.

SPF checks whether the sending server is allowed to send for the envelope sender domain. DMARC then compares that SPF domain with the visible From domain. If SPF passes and aligns, SPF can satisfy DMARC even when DKIM does not.

SPF has sharp edges. Publish one SPF TXT record for a domain. Keep SPF within the RFC 7208 limit of 10 DNS-querying mechanisms and modifiers. Use your provider's includes, but avoid +all. Use ~all while testing, and use -all when you are sure only listed systems send mail for that domain.

Do not rely on SPF alone for forwarded mail. Forwarding often breaks SPF because the final server is not in your SPF record. DKIM survives forwarding more often, so aligned DKIM is the better long-term target.

Use DMARC reports to find every sender

One passing test is useful. DMARC aggregate reports show the full map.

Add a rua address to your DMARC record and read the XML reports that receivers send back. They show which sources sent mail for your domain, whether SPF and DKIM passed, and whether each result aligned. If the XML is hard to read, use the free DMARC report reader to turn it into a sender list.

Fix the services that should send for you. Remove or block the ones that should not. Then raise policy in stages: p=none, then p=quarantine, then p=reject. Gmail and Outlook can also weigh reputation, complaints, bounces, content, MX health, reverse DNS, TLS, and blocklists. Failed or unaligned authentication can still cause spam placement or rejection even when the message content looks fine.

Do not mix this up with AI search visibility

Email authentication and AI search crawling are separate checks. Both depend on public records being clear.

For AI answers, the crawlers that decide whether you can appear 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 use 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 remove you from live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. Robots.txt states your site policy. It is not proof of what any crawler did. Perplexity-User and Bytespider have been reported to ignore it, so use logs and vendor docs as your source of truth. Only Googlebot documents JavaScript rendering. Client-side-only content is an undocumented risk for other AI crawlers. Check crawl access with the free AI visibility checker.