DKIM alignment is an identity comparison after successful signature verification. The question is whether the domain taking responsibility through DKIM corresponds to the domain shown in the message's From field. A valid signature from an unrelated service can leave that question unanswered.
Extract the right pair of domains
Use the Author Domain from the RFC5322.From field and the d= domain from a successfully verified DKIM signature. Do not substitute Reply-To, Return-Path, the selector or the optional i= identity for the signing domain in this comparison. Preserve the raw message and use a trusted receiver’s verification result, rather than assuming a signature is valid because it is present.
For example, a message displayed as Billing <billing@example.com> has example.com as its Author Domain in this simple single-author case. A passing signature with d=example.net authenticates the signer example.net; the word Billing, a familiar logo or an identical mailbox local part does not make it aligned with example.com.
Apply the configured alignment rule
RFC 9989 section 4.4 defines strict alignment as identical domains. Its relaxed rule compares organizational domains determined by the applicable discovery procedure. The DKIM alignment mode is selected through adkim; relaxed is the default when that tag is absent from an otherwise applicable policy.
An exact d=example.com match with Author Domain example.com satisfies strict alignment and also avoids ambiguity about their relationship. A signature from mail.example.com is not a strict match to example.com. Its relaxed status requires the organizational-domain determination; do not treat every parent-subdomain relationship as automatically sufficient under every possible policy configuration.
RFC 9989 section 4.10 replaces RFC 7489’s discovery model with DNS Tree Walks for organizational-domain discovery. Older implementations can still use the earlier public-suffix-based process. Record which specification and receiver behaviour your diagnosis addresses. A transition-era discrepancy needs evidence about discovery and policy, not a blanket assertion that one DNS screenshot describes every receiver.
Work through an explicit relaxed example
Assume the applicable rule is relaxed and the receiver determines the organizational domain of both mail.example.com and example.com to be example.com. A passing signature with d=mail.example.com then aligns with an Author Domain of example.com. Under strict mode the same pair would not align.
Change only the signature result to fail. The domain relationship has not changed, but it no longer supplies a DKIM-authenticated identifier. The message therefore has no DKIM pass contribution from that signature. A separate aligned SPF pass could still provide a DMARC path, so do not conclude the entire message fails without evaluating it.
These are synthetic cases with stated assumptions. In a live investigation, record the discovered policy, alignment mode, relevant DNS evidence and receiver result. This makes the conclusion reproducible instead of reducing alignment to a suffix-matching shortcut.
Correct the sender configuration at its source
If the service signs only with its own unrelated domain, determine whether its current product supports an appropriate customer signing identity. Obtain the generated records and activate signing through the supported process. Publishing a DMARC record does not change the service's d= value, and adding a provider to SPF does not alter a DKIM signature.
When strict mode is intended, verify exact-domain signing for every relevant route before changing the policy. Do not weaken alignment merely to conceal an unmanaged sending service. Equally, do not assume strict mode is cost-free: document which legitimate subdomain-signing routes it excludes and the operational decision behind that restriction.
Verify the corrected route
Send through the actual application, then capture the passing signature, its domain and the trusted receiver's DMARC assessment. Review all signatures if there is more than one; RFC 9989 section 4.4.1 accepts any passing aligned DKIM identifier. A test from a different mailbox or tenant may use a different identity and cannot close the affected application's issue.
Keep alignment and delivery outcomes distinct. The correction is proven when the intended sender produces a valid aligned identity under the applicable policy. Inbox placement still depends on the receiver's wider decisions.
Compare three synthetic outcomes
Assume Author Domain example.com and an applicable policy. A passing signature with d=example.com aligns in both modes. A passing signature with d=mail.example.com fails strict alignment; it aligns in relaxed mode only under the stated assumption that both organizational domains are example.com. A passing signature with d=vendor.example.net does not align in either mode when its organizational domain is example.net. In each case, evaluate other signatures and SPF before deciding the overall DMARC result. These are domain-comparison examples, not captured receiver results.
Keep a compact investigation record
Use this suggested worksheet for the route under review. It is a planning aid, not evidence of an executed test.
- Message: application route, raw-message reference and trusted verifying receiver.
- Identity: Author Domain and each passing DKIM d domain.
- Policy: discovered DMARC policy, adkim and the receiver’s discovery model.
- Conclusion: strict or relaxed match, other DKIM/SPF paths, and separately recorded delivery outcome.
Related reading
Multiple DKIM signatures: find the aligned passing signature · DKIM TXT and CNAME publishing: follow the provider's key-management model.