DKIM passes but DMARC fails: the alignment gap between your ESP and your From domain

DKIM can verify successfully and still fail DMARC. DKIM only proves the signature is valid for the domain in its `d=` tag. DMARC requires that signing domain to align with your visible `From:` domain (RFC 7489 §3.1). When your ESP signs with its own `d=` domain instead of yours, the signature passes but does not align, and DMARC fails on the DKIM path. The fix is to make the signing domain align, not to weaken your DMARC policy.

Quick answer

DKIM can verify successfully and still fail DMARC. The two checks ask different questions. DKIM verification asks whether the signature is cryptographically valid for the domain named in its d= tag, the SDID or signing domain (RFC 6376 §3.5). DMARC asks a second question on top: does that signing domain align with the domain in the visible From: header? RFC 7489 §3.1 requires the From domain to match an authenticated identifier. When your ESP signs with its own d= domain instead of yours, the signature passes but does not align, and DMARC fails on the DKIM path. The fix is to make the signing domain align, not to weaken your DMARC policy.

What identifier alignment actually checks

A valid DKIM signature proves one thing: the domain in the d= tag took responsibility for the message and the signed content was not altered in transit. That domain is the SDID (RFC 6376 §3.5). Nothing in DKIM alone requires d= to have any relationship to the address your recipient sees in the From: line.

DMARC adds that requirement. Per RFC 7489 §3.1.1, DKIM alignment can be relaxed or strict, and the default is relaxed. In relaxed mode the Organizational Domains of the d= signing domain and the From domain must be equal, so a signature with d=example.com aligns with a From of alerts@news.example.com, because both share the organizational domain example.com. In strict mode (adkim=s) only an exact match between the two fully qualified domain names counts, so d=example.com would not align with news.example.com. The default for the adkim tag is r, relaxed (RFC 7489 §6.3).

This is where a third-party platform trips the check. Suppose your marketing email goes out through an ESP and the Authentication-Results header reads dkim=pass header.d=esp-mail.com, while your From: is you@yourbrand.com. The cryptography is fine, so the receiver records a DKIM pass. But esp-mail.com and yourbrand.com do not share an organizational domain, so there is no DKIM alignment. The DKIM path contributes nothing to DMARC.

One important nuance: DMARC does not need both paths to align. A message passes DMARC if at least one supported mechanism produces a pass on an aligned identifier (RFC 7489 §3.1). So an unaligned DKIM signature is harmless on its own, provided SPF is aligned and passing. The DKIM alignment gap becomes a real DMARC failure when SPF is also unaligned, or on forwarded mail where the forwarding hop breaks the SPF path and leaves the unaligned DKIM signature as the only thing standing. That is exactly when this surfaces: a message that delivered fine for months suddenly fails after a forward, because the unaligned DKIM signature was never carrying DMARC in the first place. The SPF side of this same alignment story is the return-path / envelope-from misalignment case.

How to diagnose a DKIM alignment failure

Read the Authentication-Results header of a real message. The DKIM result and the signing domain are both reported there: dkim=pass header.d=<domain> (RFC 8601). The header.d value is the content of the d= tag from the signature.

Compare two things:

The header.d value, which is the domain that signed.
The domain in the From: header, which is the domain the recipient sees.

If header.d is your ESP's domain (or any domain whose organizational domain differs from your From domain), DKIM passed but did not align. Your DMARC aggregate (rua) reports show the same per source: each sending IP lists its DKIM result and whether that result was in alignment, so you can confirm the gap exists across every stream, not just one test message.

If you run adkim=s, repeat the comparison with exact-match rules. A d= of your organizational domain that does not exactly equal a subdomain From will read as unaligned even though it would align under the default relaxed mode.

How to fix DKIM alignment without weakening DMARC

Identify the sending platform behind the unaligned signature from header.d and your aggregate reports.
Configure that platform to sign as your domain. On most providers this means publishing the DKIM CNAME records they generate, which delegate the selector lookups to the provider so the published d= becomes your domain or a subdomain of it. Microsoft documents this directly: a message must be DKIM signed by the domain in the From address, and DKIM passes DMARC validation only when the signing domain and the From domain align (Microsoft 365 DKIM for custom domains).
If you deliberately run strict alignment (adkim=s), make sure the signing domain matches the From domain exactly, not just at the organizational level. A relaxed-mode CNAME that signs the apex will not satisfy a subdomain From under strict rules.
Re-send a test message and re-read Authentication-Results. You want dkim=pass with header.d now matching (relaxed) or exactly equal to (strict) your From domain. Confirm the change holds across every sending platform in your aggregate reports before treating it as resolved.

Do not change p= or relax adkim to make the failure disappear. Switching adkim=s to adkim=r only helps if your signing domain already shares your organizational domain; it never rescues a d= that belongs to your ESP.

What this does not prove

A public check reads the DMARC policy your domain publishes and the DKIM records you have delegated. It cannot read the Authentication-Results header of a specific message you sent, because that header is written by the receiving server and lives in the delivered message, not in DNS. So a public tool cannot tell you what header.d a given platform actually signed with, whether a past delivery failed for alignment or for a different reason, or whether every one of your sending streams is aligned.

For those answers you need real message headers from each platform and your DMARC aggregate report feed. Fixing one platform's signing domain closes one alignment gap; it does not guarantee DMARC passes everywhere, because a different stream may still sign with a non-aligned d=, and SPF alignment is a separate question handled on the return-path side.

Frequently asked questions

How can DKIM pass but DMARC still fail?

DKIM verification only proves the signature is valid for the domain in its `d=` tag. DMARC adds a second requirement: that signing domain must align with the domain in your `From:` header. If your ESP signs with its own `d=` domain rather than yours, the signature passes but does not align, so DMARC fails on the DKIM path per [RFC 7489 §3.1](https://datatracker.ietf.org/doc/html/rfc7489#section-3.1).

What is the difference between relaxed and strict DKIM alignment?

In relaxed mode — the default `adkim=r` — the `d=` signing domain and the `From` domain only need to share the same Organizational Domain, so `d=example.com` aligns with a `From` of `news.example.com`. In strict mode (`adkim=s`) the two fully qualified domain names must match exactly. RFC 7489 §3.1.1 and §6.3 define both modes.

My ESP says DKIM is set up. Why does alignment still fail?

Many platforms sign with their own domain (`d=esp-mail.com`) unless you complete a domain-authentication step. That signature verifies, but `esp-mail.com` does not share an organizational domain with `yourbrand.com`, so it does not align. You need to publish the DKIM CNAME records the provider generates so the published `d=` becomes your own domain.

If DKIM is not aligned, why does some of my mail still pass DMARC?

DMARC needs only one aligned, passing mechanism. If SPF is aligned and passing, the message passes DMARC even with an unaligned DKIM signature. The gap surfaces when SPF is also unaligned, or on forwarded mail where the forward breaks SPF and leaves the unaligned DKIM signature as the only path.

Should I switch adkim from strict to relaxed to fix this?

Only if your signing domain already shares your organizational domain. Relaxing `adkim` from `s` to `r` never rescues a `d=` that belongs to your ESP, because a third-party domain does not share your organizational domain under either mode. The correct fix is to make the platform sign as your domain, not to weaken the policy.

References

Browse all guides →