DKIM vs DMARC: Assign the Failure to the Right Owner

The practical difference between DKIM and DMARC is not definitional. It is that they fail for different reasons, and each reason routes to a different person. DKIM failures usually belong to whoever operates the signing system or the DNS record behind its selector. DMARC failures frequently belong to nobody in that chain, because every underlying check passed and only the alignment between the signing domain and the visible From domain broke. Reading the difference off a message header decides who you escalate to.

What each mechanism actually claims

RFC 6376 is explicit that DKIM "separates the question of the identity of the Signer of the message from the purported author of the message". The output of a DKIM verification is a domain name, carried in the signature's d= tag, and the spec notes that it "does not require the value of the SDID or AUID to match an identifier in any other message header field".

That last clause is the whole reason DMARC exists. DKIM alone lets any domain sign any message. A spoofed message claiming to come from your company can carry a perfectly valid signature from the attacker's own domain.

The spec is also careful about what a valid signature proves: "Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about protecting the end-to-end integrity of the message."

RFC 7489 adds the missing constraint. A message passes DMARC when at least one supported mechanism "produces a pass result" and "produces that result based on an identifier that is in alignment". Relaxed alignment requires the organizational domains to match. Strict alignment demands an exact match of the fully qualified names.

So DKIM answers who signed. DMARC answers whether the signer has any relationship to the name in the From line.

The failure combinations and who owns each

Most authentication triage goes wrong because someone reads a single word and acts. The combination is what carries the routing information.

The third row is the one worth reading carefully, because the word pass appears in it. Somebody sees dkim=pass, concludes authentication is healthy, and starts rewriting subject lines. What the result actually says is that the vendor signed with its own domain, and that your DMARC policy is correctly refusing to accept that signature as evidence about your From address.

The fix in that case is not in your DNS zone at all until the vendor supports a domain-aligned signature. Then it becomes a DNS task: publish the selector they give you.

Find the selector before blaming DNS

RFC 6376 places DKIM public keys in a predictable location: "All DKIM keys are stored in a subdomain named _domainkey. Given a DKIM-Signature field with a d= tag of example.com and an s= tag of foo.bar, the DNS query will be for foo.bar._domainkey.example.com."

Read the d= and s= values off the failing message rather than off your vendor's setup documentation. Those two values tell you exactly which DNS name a receiver queried. A large share of "DKIM is broken" reports resolve into a selector published under a different name than the one the signing system is using.

The other common cause is transit modification. RFC 6376 acknowledges that "some mail systems modify email in transit, potentially invalidating a signature", which is why the spec offers relaxed canonicalization to tolerate common changes such as whitespace replacement. A message that verifies when sent directly and fails after passing through a mailing list or a forwarding rule has not got a DNS problem. It has a path problem, and the owner is whoever operates that hop.

Read the header from a system you trust

RFC 8601 defines the Authentication-Results field for exactly this purpose: "to indicate the results of message authentication efforts". The structure is an authentication service identifier, then one or more method=result pairs, optionally followed by ptype.property=value details. SPF results carry properties such as mailfrom or helo. DKIM results carry the signing domain as header.d.

That header.d value is what you compare against the visible From domain to explain a DMARC result by hand.

The spec also sets a trust rule worth respecting. Organisations must "delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary but that did not come directly from another trusted MTA". The warning behind it is concrete: an attacker can forge the header using the receiving domain's own identifier and claim the message authenticated cleanly.

In practice this means you diagnose from a header your own receiving infrastructure wrote, or from your DMARC aggregate reports. A header on a message someone forwarded to you from an outside account is evidence about their hop, not yours.

RFC 8601 states the limit of the whole exercise plainly: "this header field indicating a pass does not render the message trustworthy." Authentication is an identity check. Spam passes it routinely.

Running the triage

Start from a specific failing message rather than a scanner score. Pull the Authentication-Results header your system wrote, and note the visible From domain, the header.d signing domain, the SPF envelope domain, and each method result.

Compare the signing domain with the From domain first. If they share an organizational domain, alignment is not your problem and you should look at why the signature or the SPF check failed. If they differ, you have found the DMARC cause, and the work is a vendor configuration request rather than a DNS edit.

When the selector does not resolve, check the exact name from the s= and d= values before assuming the record is missing. When the selector resolves but verification fails, establish whether the message reached you through a forwarding hop before treating it as a signing defect.

LeadHaste practice: for client campaigns we require an aligned signature on the sending domain before a sequence goes live, rather than accepting a vendor's own signing domain and relying on SPF alone. That is a standard we hold to for portability reasons, since a client who leaves keeps a domain that authenticates on its own terms. It is not a spec requirement.

Where this stops being useful

Authentication triage answers one question: is this message eligible to be accepted as coming from this domain. It does not explain placement. Once a message shows aligned pass results and still lands in spam, the investigation moves to reputation, complaint rates, list quality and content, and the owner changes accordingly.

Our SPF, DKIM and DMARC guide covers the setup layer, and how to fix DKIM failure covers repair of a confirmed signing defect. This piece is only about deciding which of those two doors to walk through, and who should be on the other side of it.

Ready to get authentication owned before your next send?

We can review your signing domains, alignment coverage and vendor configuration as part of an ICP and campaign-fit discovery call. Book your free discovery call →