Summary

  • DKIM pass validates selected canonicalized message material under the key named by s= and signing domain d=. It does not automatically authorize the visible From domain or identify a human author.
  • RFC 9989 DMARC alignment supplies a separate author-domain test. Even an aligned pass does not establish truth, harmlessness, freshness or permission for a business action.

A valid signature from the wrong authority

The verifier did its job. It found a DNS public key beneath the attacker's selector and domain, recomputed the required hashes and validated the signature. No cryptographic forgery occurred.

The policy engine did something else. It saw the word “pass,” ignored which domain passed, and attached the result to the identity most visible to the reader. That step moved authority from d=receipt-alert.example to the bank.example From domain without evidence.

DKIM was designed to let a domain claim responsibility for transmitting a message. It supplies a verified identifier for later assessment. RFC 5585 separates that act from deciding whether the identifier is trustworthy. A bad actor can own a domain, publish a valid key and sign bad mail perfectly.

What the signature actually covers

The DKIM-Signature field contains several linked claims. d= names the Signing Domain Identifier. s= selects the key namespace, normally retrieved through DNS TXT. h= lists signed header fields. bh= carries the hash of the canonicalized body portion. b= carries the signature over canonicalized signed headers, including the DKIM-Signature field with its own signature value treated as empty.

Verification is therefore not one opaque green event. The receiver chooses the specified canonicalization, calculates the body hash, compares it with bh=, retrieves the key for s= under d=, constructs the header input and validates b=. RFC 6376 is explicit: if the body hash differs, the whole signature fails even if header-signature computation would otherwise succeed.

The From header must be included in h=. That protects the literal signed From field against later alteration. It does not prove that the signing domain controls the domain written there. A signer can faithfully sign a false claim about another organization.

Canonicalization is a byte rule, not meaning

DKIM offers simple and relaxed canonicalization for headers and bodies. Relaxed processing tolerates defined whitespace and field-name changes that commonly occur in transit. Simple processing tolerates less.

Neither mode decides semantic equivalence. A whitespace change may be harmless to a reader and fatal to one canonical form. A malicious sentence may remain byte-perfect and pass. The trace must record the canonicalization pair and the exact object hashed; “message unchanged” is too broad.

The optional l= tag makes the boundary sharper. It limits body coverage to a number of canonicalized octets. Text appended after that prefix can remain outside the body hash. The feature accommodated intermediaries such as mailing lists that add footers, but RFC 6376 warns that it opens an avenue for unauthorized additions. With l=0, the body is wholly unsigned.

A user interface that displays the full body beneath one signed badge can therefore misstate the cryptographic scope. If l= does not cover the end, the unsigned suffix needs an explicit boundary or the signature should not be treated as protection for what the user sees.

Alignment answers the author-domain question

RFC 9989 is now the current DMARC standard, replacing RFC 7489. It explains why bare DKIM pass is insufficient for the displayed author identity: any domain, including one used by a bad actor, can produce a valid DKIM signature.

DMARC takes the RFC5322.From Author Domain and asks whether it aligns with an authenticated DKIM d= domain or an SPF authenticated identifier. Strict DKIM alignment requires identical domains. Relaxed alignment accepts the same Organizational Domain under the standard's discovery rules.

In the opening message, DKIM passes for receipt-alert.example; alignment with bank.example fails. A downstream rule must preserve both facts. Recording only “DKIM=pass” hides the failure that matters to the claimed author.

Even DMARC pass remains bounded. RFC 9989 says it validates authorized use of the Author Domain; it does not make a value assertion about the message or guarantee that inbox delivery is safe or desirable. A compromised account or authorized bulk platform can send harmful but aligned mail.

Identity fields stay separate

DKIM's optional i= Authenticated User Identifier can express a finer-grained identity beneath the signing domain. RFC 6376 does not require it to match a message header identity and warns against broad end-user reliance on that binding.

The SMTP envelope, SPF identifier, DKIM signing domain, RFC5322.From address and SMTP-authenticated account are different records. One message can legitimately contain several DKIM signatures from different domains. Each signature needs its own verification; DMARC looks for an authenticated identifier that aligns.

Authentication-Results can carry these outcomes to filters and user agents. But the header gains authority from its producer, not from its spelling. An ingress boundary must remove or segregate externally supplied copies and trust only results created by authorized validators in the receiving administrative domain.

Mutation and indirect paths

Mailing lists and gateways can add footers, rewrite subjects, re-encode bodies or change envelope information. Those actions can break an otherwise valid DKIM signature and therefore DMARC alignment. A failure after mediation does not prove the original signer never authenticated the earlier form; nor does it entitle a receiver to accept every broken message.

ARC can carry an ordered chain of authentication assessments across handlers. It adds evidence about prior observations. It does not make every intermediary trustworthy. The final receiver must evaluate the ARC signer, chain and local policy.

This is why “repairing” a DKIM failure by relaxing every transformation rule is dangerous. The system must distinguish expected modification, malicious modification and untrusted testimony about an earlier pass.

Time is not replay protection

The t= tag can record signature creation time. The optional x= can record expiration, but RFC 6376 expressly says expiration is not an anti-replay defense. A captured valid message can be sent to more recipients or processed again while its signature remains intact.

Email authentication and business idempotency therefore belong to separate ledgers. A signed payment instruction may be authentic mail from a domain and still be old, duplicated or outside the sender's present mandate. Transaction identifiers, workflow state, account controls and human confirmation govern the action.

Negative tests that preserve the nouns

Sign an attack message under a domain you control while displaying an unrelated From domain. Require dkim=pass and DMARC alignment failure in the same trace. Then sign malicious content under an aligned authorized domain; require authentication to pass while content and account-risk policy still decide disposition.

Alter a signed header and an unsigned header separately. Append a visible instruction beyond an l= boundary. Change whitespace under simple and relaxed canonicalization. Force bh= mismatch while preserving the header-signature path. Replay an intact message. Present multiple signatures whose pass and alignment outcomes differ.

Finally inject a forged Authentication-Results, rotate the selector through DNS cache states and pass the message through a footer-adding mediator. The goal is not to make every test pass. It is to ensure every result names the object, domain, scope, producer and policy that earned it.