A DKIM signature can verify successfully for a provider's domain without authenticating the domain a reader sees in From. Aggregate reports preserve both layers. Read the raw signature identity and result before interpreting the DKIM-related DMARC result.
Start with each reported signature
References: RFC 9990 §3.1.1.12, RFC 9990 §3.1.3.
Under auth_results/dkim, RFC 9990 identifies the signing domain, selector and verification result. The domain corresponds to d in DKIM-Signature and the selector to s. Neither a friendly display name nor the selector label substitutes for the signing domain in alignment.
Messages can carry multiple signatures. One can fail after content modification while another verifies, or both can verify under different domains. Inspect the individual results rather than selecting the first signature your interface displays. Reports can limit the signatures they include, so absence from an aggregate record is not always proof that a signature never existed.
Compare the signing domain with From
References: RFC 9989 §4.4.1, RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
DMARC uses the author domain from the visible From field and the domain of a successfully verified DKIM signature. Strict alignment requires an exact domain match. Relaxed alignment uses the relationship defined by organizational-domain discovery under the applicable rules. The i identity in a signature does not replace d for this comparison.
A signature whose domain aligns but whose cryptographic check fails does not provide a passing DKIM path. Conversely, a valid signature from an unrelated domain remains unaligned. The policy_evaluated/dkim field represents the DMARC-related evaluation, not merely whether any signature verified.
Reproduce the result in a synthetic example
References: RFC 9989 §5.3.5.
Assume an applicable valid policy, completed checks, unrelated brand.example/vendor.example organizational domains and header_from=brand.example. Signature one uses d=vendor.example and verifies. Signature two uses d=brand.example and fails its body-hash check. There is no successful aligned DKIM path in this example, so a DKIM-related policy failure is consistent with the raw pass on signature one.
Now change signature two's result to pass while keeping the identities the same. That signature provides exact alignment, so the DKIM path can satisfy DMARC regardless of the unrelated signature’s result. These are constructed cases, not real receiver measurements. Inspect SPF as well before determining the overall DMARC outcome in the first case.
Repair verification and alignment separately
References: RFC 6376 §6.1, RFC 9989 §5.4.
For a verification failure, investigate the reported signature's key, content coverage and actual message processing. A body-hash defect is not repaired merely by changing the From address. For a verified but unaligned provider signature, establish whether the service supports a custom signing domain or another aligned path.
Do not assume that adding an extra signature repairs an earlier one. It creates another independently evaluated path. The useful question is whether at least one supported, valid signature aligns, not whether every possible signature passes.
Preserve raw samples and trusted receiver results when resolving ambiguous aggregate evidence. Record the d domain, selector, verification result, alignment mode and author domain for each tested route. Keep disposition separate: authentication success does not guarantee delivery, and a receiver handling exception does not turn a failed signature into a valid one.
Retain the multiple-signature comparison
Two partial synthetic maps use header_from=brand.example, policy p=reject, relaxed alignment and epoch interval 1704067200–1704153600. Both have raw SPF pass for unrelated vendor.example, so neither has aligned SPF. The first has vendor.example/v1 DKIM pass plus brand.example/b1 DKIM fail. Its aligned DKIM result and overall DMARC result fail. The second has vendor.example/v1 fail plus brand.example/b1 pass. Its aligned DKIM and overall DMARC results pass.
The supplied local identity exercise reproduces these results and keeps selectors attached to each signature. The model assumes the supplied verification results; it does not recompute signatures or test DNS. Both maps represent 25 observations each, not a measured traffic sample. Their disposition field remains supplied reporting context rather than a calculated delivery guarantee. Use actual raw messages to validate this chain for a production route.
Keep the exercise within scope
The examples are partial field projections, not schema-valid reports or measured traffic. Local checks use explicitly supplied authentication results and organizational relationships; they do not perform DNS discovery, SPF evaluation, cryptographic verification, report ingestion or receiver delivery tests. Preserve the original report and trusted message evidence before making a production change.