DKIM Alignment Explained: Why DMARC Still Fails

Why DKIM can pass while DMARC fails

Your DKIM check can be green while Gmail or Outlook still says DMARC failed. That usually means the signature is valid, but it belongs to the wrong domain.

DKIM verifies a cryptographic signature on the message. That signature has a signing domain in the d= tag. DMARC checks the domain people see in the visible From header, called the RFC5322.From domain in the standard.

Say the message shows From: you@example.com, but the DKIM signature says d=mail.vendor.com. DKIM can pass because the vendor signature is valid. DMARC can still fail because mail.vendor.com is not aligned with example.com.

DMARC passes when at least one authentication result passes and aligns with the visible From domain. For DKIM, an aligned DKIM signature must verify. For SPF, the domain checked from MAIL FROM, often seen as Return-Path or the envelope sender, must pass SPF and align with the visible From domain.

Relaxed alignment allows the same organizational domain, such as mail.example.com aligning with example.com. Strict alignment requires an exact domain match. Most teams use relaxed alignment unless they have a clear reason to require exact matches.

The records that affect alignment

Alignment comes from DNS records, message headers, and the domains your mail platform uses when it sends.

• DKIM: Your sender signs each message with a private key. The matching public key lives in DNS under _domainkey, such as selector1._domainkey.example.com. The s= tag names the selector. The d= tag names the signing domain.
• SPF: SPF is a DNS TXT record that lists the sources allowed to send for a domain. Publish one SPF record per domain. SPF has a 10 DNS-lookup limit across mechanisms such as include, a, mx, ptr, exists, and redirect. Many teams use ~all during rollout and move to -all after every real sender is covered.
• DMARC: The DMARC record lives at _dmarc.example.com. It sets p=none, p=quarantine, or p=reject. A rua=mailto: address asks receivers to send aggregate reports, which show who is sending and whether DKIM or SPF aligned.
• MX: MX records tell other mail servers where to deliver mail to you. They do not authorize outbound mail. Missing or broken MX can hurt replies and bounces, and many domain health checks flag it.
• Blocklists: A listed sending IP or domain can still land in spam after DMARC is fixed. Treat that as a reputation issue, then fix the sender, list source, or traffic pattern that caused it.

A free InboxRadar domain check can read the live SPF, DKIM, DMARC, and MX setup and show which part is failing first.

How to fix a DKIM alignment mismatch

The usual fix is to make your email platform sign with your domain instead of its shared vendor domain.

• Open the DKIM, domain authentication, or sender authentication screen in your mail platform, such as Google Workspace, Microsoft 365, SendGrid, Mailchimp, HubSpot, or your CRM.
• Add the CNAME or TXT records the platform gives you. These records normally create selectors below _domainkey for your domain.
• Wait for DNS to update, then send a real test message. Check the headers. DKIM should pass, and the d= value should be your domain or an aligned subdomain.
• Check SPF alignment too. If Return-Path uses a vendor domain, set up a custom bounce or return-path domain if your provider supports it.
• Start DMARC with p=none and rua=mailto: reporting. Read the aggregate reports before moving to quarantine or reject. The free DMARC report reader turns RUA XML into plain rows.

Do not copy one sender's DKIM key into another sender. Each sender should have its own selector and public key. That makes key rotation safer and failures easier to trace.

Why Gmail and Outlook may still choose spam

A DMARC pass proves the mail is tied to your domain. It does not guarantee inbox placement.

Mailbox providers look at authentication, alignment, complaint rates, bounce rates, sending volume, links, content, past engagement, and reputation signals. Google and Microsoft both tell senders to keep SPF, DKIM, and DMARC healthy, but they also judge whether recipients want the mail.

Fix authentication first because it is the base layer. Make sure every real sender is covered, then review list quality, sudden volume jumps, spam complaints, invalid addresses, and any IP or domain listings. If authentication is broken, the later checks are harder to trust.

For the standards, use RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. For provider rules, check the current Google and Microsoft sender guidelines.

AI answer visibility needs crawler access

If you want a help page to show up in AI answers, the right crawlers need to reach and read the page.

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 use the normal Google Search index. There is no separate opt-out crawler. Disallowing any of these 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 policy, not proof of behavior. Perplexity-User and Bytespider are reported to ignore it, so do not use robots.txt alone as proof of what a bot did. Only Googlebot documents JavaScript rendering. Client-side-only content may be invisible to other AI crawlers, but that is an undocumented risk, not a proven rule for every bot. Use the vendor docs from OpenAI, Anthropic, Perplexity, Google, Apple, and Common Crawl as the source of truth. You can test access with the free AI visibility checker.