The counter-intuitive part is this: a passing DKIM signature is necessary but not sufficient for DMARC. DKIM verification proves the message wasn’t altered and that someone holding a private key signed it. DMARC adds a second requirement — the signing domain has to be yours. If your email service provider signs every message with its own domain in the d= tag, the signature is perfectly valid and dkim=pass, yet DMARC still returns fail because that signing domain doesn’t line up with the From address your subscribers actually see.

The d= tag is the whole story

Every DKIM signature (RFC 6376) carries a d= tag naming the signing domain — the domain whose public key in DNS will be used to verify the signature. The receiver fetches the key from <selector>._domainkey.<d-domain>, verifies the cryptography, and records a pass or fail. Crucially, d= is chosen by whoever signs the message. When a shared ESP signs on your behalf, it very often uses its own domain there — something like d=acme-esp.net — because that’s where its keys live by default. The signature is genuine. It just belongs to the ESP’s identity, not yours.

What DMARC alignment checks for DKIM

DMARC (RFC 7489) considers DKIM “aligned” only when the d= domain matches the header From: domain:

Relaxed alignment (adkim=r, the default): the organizational domains must match. d=mail.acme.com aligns with From: news@acme.com because both share the registered domain acme.com.
Strict alignment (adkim=s): the domains must be exactly equal. d=acme.com aligns with acme.com; a subdomain would not.

DMARC passes if either aligned DKIM or aligned SPF succeeds. So a message can survive on aligned DKIM alone even when SPF isn’t aligned — but if neither identifier aligns, DMARC fails regardless of how many valid-but-unaligned signatures the message carries.

A valid ESP signature that isn’t aligned

Here is the exact failure. The signature verifies, SPF even passes for the ESP’s bounce domain, and DMARC still fails — because neither d= nor smtp.mailfrom aligns with acme.com:

From: "Acme Marketing" <news@acme.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=acme-esp.net; s=s1; t=1737460000;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWN2eR...;
  b=Xk9pQ2v...
Authentication-Results: mx.google.com;
  dkim=pass header.i=@acme-esp.net;
  spf=pass smtp.mailfrom=bounce.acme-esp.net;
  dmarc=fail (p=REJECT dis=REJECT) header.from=acme.com

Trace it: the DKIM-Signature says d=acme-esp.net. The Authentication-Results confirms dkim=pass header.i=@acme-esp.net — a real, valid signature. But header.from=acme.com, and acme.com is a different registered domain from acme-esp.net, so DKIM does not align. SPF passed for bounce.acme-esp.net, which also doesn’t align. With no aligned identifier, dmarc=fail, and under p=reject the message is refused. To decode each field here in detail, see how to read the Authentication-Results header.

The fix: sign as your own domain

The goal is to move the d= value onto your domain. You don’t hand the ESP your private key — instead the ESP hosts the key material and you delegate a selector under your domain to it with CNAME records. The ESP gives you one or two CNAMEs; you publish them; the ESP then signs with d=acme.com using a selector that resolves — through your CNAME — back to the ESP’s key. Typical records look like this:

esp1._domainkey.acme.com   CNAME  esp1.dkim.acme-esp.net.
esp2._domainkey.acme.com   CNAME  esp2.dkim.acme-esp.net.

This is what nearly every provider calls domain authentication, authenticated domain, sending domain, or CNAME setup. Two providers commonly use two selectors so they can rotate keys without downtime. Once the CNAMEs resolve and the ESP is signing as your domain, the same message now reads:

From: "Acme Marketing" <news@acme.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=acme.com; s=esp1._domainkey; ...
Authentication-Results: mx.google.com;
  dkim=pass header.i=@acme.com;
  dmarc=pass (p=REJECT dis=NONE) header.from=acme.com

Now d=acme.com matches header.from=acme.com — DKIM is aligned, so dmarc=pass even though the policy is p=reject.

Why aligned DKIM is the more robust target

You can pass DMARC via aligned SPF instead (a custom Return-Path), but aligned DKIM is sturdier for one reason: it survives forwarding. When a message is auto-forwarded or relayed by a mailing list, SPF fails on the new hop because that server’s IP isn’t in your record — but the DKIM signature travels inside the message and still verifies. So the belt-and-suspenders setup is aligned DKIM and aligned SPF; the reverse case (SPF passing but not aligned) is covered in why SPF passes but DMARC fails.

Common reasons DKIM alignment silently breaks

You only did SPF at the ESP. Publishing the SPF include but skipping the DKIM CNAMEs leaves the ESP signing with its own d=. Complete the domain-authentication step, not just SPF.
The CNAMEs are proxied or flattened. If your DNS host proxies the record (Cloudflare’s orange cloud) or a registrar rewrites the CNAME to an A record, the selector won’t resolve to the ESP’s key. Keep DKIM CNAMEs DNS-only.
Strict alignment plus a signing subdomain. If you set adkim=s but the ESP signs with a subdomain, it won’t align. Use relaxed unless you have a specific reason not to.
Multiple senders, only one authenticated. Every platform that sends as your domain needs its own DKIM delegation. One aligned sender doesn’t cover the others.

Verify

Confirm the published selector and the d= your mail actually signs with using the DKIM Checker, then confirm end-to-end alignment with the DMARC Checker and inspect the raw header with the Email Header Analyzer. Check that your SPF side is also healthy with the SPF Checker. For the full model of how the three records work together, see the complete SPF, DKIM & DMARC guide, and when every sender is aligned, follow how to move DMARC to p=reject safely. Authoritative references: RFC 6376 (DKIM), RFC 7489 (DMARC), and Microsoft’s DKIM configuration docs.

Why DKIM passes but DMARC fails