A message with several DKIM signatures needs a per-signature assessment. Counting the signatures or selecting the first passing result can misidentify the domain that authenticated the visible author. Under RFC 9989 §4.4.1, any passing DKIM-authenticated identifier that aligns with the Author Domain can supply the DKIM path to DMARC pass.
Preserve the identity of each result
Export the raw message through an approved process. Record the visible From domain and, for each signature, its d= signing domain, s= selector, a= algorithm and relevant canonicalization settings. Associate the trusted receiving system's result with that signature. Two signatures can use the same domain but different selectors or algorithms, so the domain alone may not distinguish them.
Do not trust an arbitrary Authentication-Results field merely because it appears in the message. RFC 8601 §1.2 explains the trust boundary for those fields. Use results attributable to the receiving system whose assessment you are investigating, and preserve that source when exporting evidence. A sender can insert misleading header text; a copied status label is not an independent verification.
Keep verification and alignment as separate decisions
Verification establishes whether a signature validates for its signing domain. Alignment compares that authenticated domain with the Author Domain under the applicable DMARC rule. An unrelated provider's signature can be perfectly valid without authenticating the author's visible domain for DMARC.
For strict DKIM alignment, the domains must match exactly, with domain-name case comparison following RFC 1035 §2.3.3. Relaxed alignment uses their organizational-domain relationship as determined by the applicable DMARC process. RFC 9989 §4.10.2 defines DNS Tree Walks for this determination. Do not decide alignment from a common word in two domain names, and do not silently assume every recipient has adopted the newest discovery implementation.
Work through a synthetic message
Assume a valid applicable DMARC policy, an Author Domain of example.com and no aligned SPF pass. Signature A uses d=example.net, verifies successfully and does not align. Signature B uses d=example.com but fails verification after a downstream content change. Neither supplies an aligned passing DKIM identity, so this combination does not produce DMARC pass.
Now add signature C with d=example.com that verifies successfully. It aligns exactly, so it supplies the DKIM path to DMARC pass. The unrelated pass and failed signature do not automatically cancel C. This is an illustrative evaluation, not a claim about a captured customer message or guaranteed mailbox placement.
Write the example into separate columns in your investigation record: signature identifier, verification result, alignment result and contribution to DMARC. Never combine signature A's pass with signature B's aligned domain to manufacture a result no individual signature achieved.
Explain why there are multiple signatures
Parallel algorithms, a provider's operational signature and an intermediary's later signature can all create multiple results. These are hypotheses until the route and signer configuration establish the reason. RFC 8463 §6 describes distinct selectors for RSA and Ed25519 transition signatures; their results should be tracked individually.
If a gateway re-signs modified mail, inspect its new domain. A passing gateway signature does not automatically repair the original author's authentication. Where the organisation controls the final signing stage, verify that it signs the intended post-processing content under an approved identity. Do not remove an apparently redundant signature without checking its operational purpose.
Close with the message-level conclusion
After assessing all relevant DKIM signatures, evaluate SPF's authenticated identifier and alignment separately. If no applicable DMARC policy is discovered, do not relabel the situation as a normal DMARC failure. Distinguish authentication results from the receiver's final disposition, which can reflect additional policy or filtering.
Retain the original message, trusted result source, per-signature analysis and the reason for the final conclusion. If reporting tools aggregate signatures differently, compare their raw evidence before treating differing summaries as a protocol contradiction. The useful outcome is an explainable identity path, not simply a larger number of green indicators.
Record the example without mixing identities
For the synthetic message above, keep one row per signature:
- A: example.net; verification pass; alignment no; DKIM contribution to DMARC no.
- B: example.com; verification fail; domain would match but is not authenticated; DKIM contribution no.
- C: example.com; verification pass; alignment yes; DKIM contribution yes.
Before C is present, the stated absence of aligned SPF leaves no passing path. With C present, DMARC passes under the assumed applicable policy. No actual receiver outcomes or inbox-placement result are claimed.
Related reading
DKIM alignment: compare d= with the visible From domain · RSA and Ed25519 DKIM signatures: deployment questions and interoperability.