Why is DKIM alignment with the 5322.from domain important for email authentication?
Published 20 Jun 2025
Updated 20 Oct 2026
13 min read
Summarize with
Updated on 20 Oct 2026: We clarified DKIM domain matching under RFC 9989 and added practical fixes for alignment failures.
DKIM alignment with the RFC5322.From domain is important because DMARC only treats DKIM as an aligned pass when a verified signing domain is identical to the visible sender domain, or has the same Organizational Domain under relaxed mode. A message can have DKIM pass and still fail DMARC if the d= domain on every passing signature belongs to an email service provider (ESP) or another unrelated domain, and SPF does not provide an aligned pass for the address the recipient sees in the From header.
Mailbox providers use alignment to assess whether the visible sender domain has authenticated the mail. If the DKIM signature validates for an unrelated provider domain, the receiver knows that the provider domain signed the message, but that signature does not authenticate the visible brand domain for DMARC.
- DMARC pass: DKIM satisfies DMARC when at least one valid signature has domain alignment with the RFC5322.From domain.
- Visible trust: Alignment connects domain authentication to the sender identity shown to the recipient.
- Forwarding resilience: DKIM survives many forwarding paths where SPF breaks, provided the forwarder does not alter signed content.
- ESP accountability: The sender can verify that its ESP signs with an aligned customer domain instead of only an ESP domain.
What RFC5322.From means
The RFC5322.From domain is the domain in the message header From field. DMARC calls it the Author Domain. It is part of the sender address shown in email clients. It differs from the envelope sender, also called RFC5321.MailFrom, Return-Path, or bounce domain. SPF checks the envelope sender. DKIM verifies a cryptographic signature placed in the message header. DMARC then asks whether either SPF or DKIM authenticated a domain aligned with the Author Domain. DMARC compares domain names, not the mailbox name before @. The display name and Reply-To address are not the identifiers used for this comparison.
DKIM alignment flowchart comparing the visible From domain with the verified d= signing domain for DMARC.
This is where many ESP setups go wrong. A platform signs with a valid DKIM key for its own domain, the signature passes, and the sender assumes the message is authenticated for DMARC. DMARC sees a different result. It checks whether a passing DKIM domain has alignment with the RFC5322.From domain. If it does not, that signature does not help DMARC pass.
Microsoft describes this broader receiver-side evaluation in its Microsoft authentication guidance. The practical point is simple: receivers judge the visible sender, not only whether any unrelated domain produced a valid cryptographic signature.
DKIM authentication versus DKIM alignment
These are separate checks, and mixing them causes bad ESP requirements. DKIM authentication asks whether the signature is valid. DKIM alignment asks whether the domain in that valid signature has the required relationship to the visible From domain.
DKIM authentication
A DKIM signature authenticates the signing domain in the d= tag. The public key is found in DNS under that domain.
- Signature: The receiver verifies the cryptographic signature over the covered message content, allowing the formatting changes permitted by DKIM canonicalization.
- Key lookup: The selector and signing domain point the receiver to the DNS public key.
- Result: A verified signature returns pass. A failure or verification error cannot satisfy DMARC through that signature.
- Gap: A pass for an ESP domain does not prove the visible From domain authorized the mail.
DKIM alignment
DMARC checks whether a passing DKIM d= domain has alignment with the RFC5322.From domain.
- Relaxed mode: mail.example.com and example.com pass when they have the same Organizational Domain.
- Strict mode: The DKIM signing domain must match the RFC5322.From domain exactly.
- DMARC value: An aligned DKIM pass lets DMARC pass even when SPF is broken by forwarding.
- Policy impact: A domain can move toward quarantine or reject with less risk after legitimate streams pass alignment.
The From header itself also needs to be signed in DKIM. RFC 6376 requires the From header field to be included in the signed header list. That is related, but it is not the same as DKIM alignment. A message can include From in the DKIM header hash and still use an unrelated d= domain.
For DMARC, compare the DKIM d= domain, not the optional i= identity or the s= selector. The selector identifies the key lookup at <selector>._domainkey.<d-domain>; it is not a sender domain.
DKIM canonicalization and DMARC alignment are also separate settings. c=relaxed/relaxed controls how formatting is normalized for signature verification. It does not enable relaxed domain matching; adkim=r in the DMARC record controls that. RFC 6376 defines DKIM signing and canonicalization.
For senders using several brands or subdomains, the implementation detail is usually selector design and domain delegation. The same ESP can sign mail for different From domains as long as each stream uses an aligned signing domain and a valid DNS record.
Relaxed versus strict DKIM alignment under RFC 9989
RFC 9989 replaced RFC 7489's Public Suffix List method with a DNS Tree Walk for finding the Organizational Domain used in relaxed alignment. For different domains, a receiver implementing RFC 9989 checks DMARC records up the DNS hierarchy for the Author Domain and passing DKIM signing domain, then compares the resulting Organizational Domains. An exact match already satisfies either mode.
- Default behavior: If the DMARC record omits adkim, DKIM alignment defaults to relaxed mode.
- Relaxed comparison: A setting of adkim=r accepts a verified signature when the DKIM and Author Domains have the same Organizational Domain.
- Strict comparison: A setting of adkim=s requires an exact domain match and does not need an Organizational Domain comparison.
- Multiple signatures: If any valid DKIM signature has alignment, DKIM can satisfy DMARC even when another signature fails or uses an unrelated domain.
For example, From: billing@example.com and a valid signature with d=mail.example.com satisfy relaxed alignment when both have example.com as their Organizational Domain. That same pair fails strict alignment. The adkim setting controls DKIM only; aspf independently controls SPF alignment.
The practical configuration goal has not changed: the active signing domain must pass alignment with the Author Domain. The discovery method matters most for subdomain boundaries and public suffix operators. Publish appropriate DMARC records for the domains in use and verify receiver results instead of assuming that a shared suffix is enough. Publishing a DMARC record on a subdomain does not by itself make that subdomain a separate Organizational Domain.
Where ESP-domain signing fails
A common ESP pattern is to sign only with the provider's domain and leave the customer brand domain out of DKIM. SPF can still pass DMARC if the RFC5321.MailFrom domain has alignment with the visible From domain, but many outsourced mail streams use an ESP-controlled Return-Path. In that setup, SPF and DKIM both fail alignment even when the raw DKIM signature passes.
These illustrative header excerpts assume that example.com has a published DMARC policy. SPF passes for an unrelated bounce domain in both examples. Only the second example has DKIM domain alignment.
Illustrative headers: SPF and DKIM pass but DMARC failstext
From: billing@example.com Return-Path: <bounce@esp-mail.example.net> Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=esp-mail.example.net; dkim=pass header.d=esp-mail.example.net header.s=s1; dmarc=fail header.from=example.com
Illustrative headers: aligned DKIM satisfies DMARCtext
From: billing@example.com Return-Path: <bounce@esp-mail.example.net> Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=esp-mail.example.net; dkim=pass header.d=example.com header.s=s1; dmarc=pass header.from=example.com
The common mistake
A valid DKIM signature for an ESP domain authenticates that domain, but it does not authenticate an unrelated visible sender for DMARC.
- Verified identity: The receiver verifies that esp-mail.example.net signed the message.
- Missing relationship: The signature does not connect esp-mail.example.net to example.com under DMARC alignment.
- DMARC result: DKIM does not satisfy DMARC unless a valid signing domain has alignment with From.
- Inbox effect: The DMARC failure becomes one input to the receiver's filtering and policy decision.
This is why custom DKIM should not be treated as optional for an ESP sending as a customer's domain. The sender does not need to hold the private key, but the ESP needs a way to sign with the customer domain or an aligned customer subdomain. CNAME-based selector delegation is a common operational model.
How DKIM alignment affects DMARC and delivery
DMARC does not treat every DKIM pass as proof for the visible sender. A passing DKIM signature with an aligned domain lets DMARC authenticate the Author Domain. A passing signature for an unrelated platform domain does not. Once legitimate sources have aligned authentication in place, the domain owner can move beyond monitoring and enforce quarantine or reject with lower risk.
DKIM alignment outcomes
How DMARC evaluates DKIM results against the RFC5322.From domain.
Exact domain match
Aligned
The DKIM signing domain and RFC5322.From domain are identical.
Organizational Domain match
Aligned
The domains have the same Organizational Domain under relaxed mode.
Unrelated signing domain
Not aligned
DKIM passes, but the signing domain does not have alignment with RFC5322.From.
Invalid signature
Fail
The DKIM signature fails verification and cannot satisfy DMARC.
DKIM alignment is not a delivery guarantee. Reputation and receiver filtering still affect inbox placement. Unaligned DKIM causes a DMARC failure only when no other signature or SPF result provides an aligned pass. DMARC protects the use of the Author Domain; it does not authenticate a display name or establish that a message is safe. Microsoft explains how additional signals affect message handling in its email authentication guidance.
Forwarding does not always preserve DKIM. A mailing-list footer or a change to a signed Subject header can invalidate the signature. A receiver that trusts an ARC chain can use earlier authentication results when deciding whether to override a DMARC failure. ARC does not repair the DKIM signature or change its signing domain.
For a quick DNS and selector check, use a DKIM check against the selector your ESP provided. That confirms whether the public key exists, but it does not replace a real message test because alignment depends on the signing domain used in the sent email.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
After the record passes, send a real message and inspect the Authentication-Results header. Look for a DKIM pass where header.d has alignment with the RFC5322.From domain under the configured DMARC mode. If the only passing DKIM result belongs to the ESP domain, the stream still needs customer-domain signing unless aligned SPF is providing the DMARC pass.
What ESPs need to support
An ESP does not need a complicated customer-facing setup to do this correctly. It needs an aligned per-customer signing domain, selector records, a key rotation process, and a signature that includes the From header field. Shared infrastructure is fine. An unrelated shared signing identity is the problem.
|
|
|
|---|---|---|
Signing domain | Aligned customer domain | ESP domain only |
Selector DNS | Published key or delegated CNAME | Missing customer record |
Header signing | From included | Noncompliant signature |
Rotation | Planned selector rollover | Stale or exposed key |
Compact checklist for ESP DKIM support.
A practical rotation pattern keeps two DKIM selectors available per customer domain. The customer publishes CNAME records. The ESP keeps the private keys, rotates them, and signs outgoing mail with the aligned customer domain in the d= tag. This gives the sender DMARC alignment without forcing the customer to manage private key material. Keep the previous public key available while queued messages and messages still in transit need verification.
Good implementation pattern
This DNS delegation pattern gives the customer domain an aligned signing identity while the ESP operates the keys.
Selector delegation exampledns
s1._domainkey.example.com CNAME s1.example.esp.net s2._domainkey.example.com CNAME s2.example.esp.net
The CNAME target can be on the ESP's domain without affecting alignment. In this example, the message still needs d=example.com. DMARC compares that signing domain with From, not the domain hosting the delegated public key.
- Customer control: The visible sender domain has DNS records that authorize the signing setup.
- ESP control: The ESP manages signing and key rotation without sharing private keys with the customer.
- DMARC readiness: The sent mail can pass DMARC through DKIM even when SPF does not survive forwarding.
- Scale: Brands and subdomains can use separate selectors and reporting views.
How to fix DKIM alignment failures
Inspect the original message headers and use the Authentication-Results added by the receiving mail system. RFC 8601 defines this header and its trust boundary. Check each signature's result and signing domain separately before choosing a fix.
|
|
|
|---|---|---|
DKIM passes for an unrelated ESP domain | The signature verifies, but its d= domain has no alignment with From. | Enable custom DKIM for the actual From domain and publish the selector records supplied by the ESP. |
DKIM passes for mail.example.com; From uses example.com; adkim=s | Strict mode rejects the subdomain match. | Sign with d=example.com, or use adkim=r if the intended domain boundary permits relaxed alignment. |
The d= domain matches, but DKIM fails or returns an error | The receiver cannot verify the signature; matching domains alone are insufficient. | Check the active selector and public key. Investigate message changes when the receiver reports a body-hash or signature mismatch. |
Direct delivery passes; forwarded mail fails | Forwarding breaks SPF and message changes can invalidate DKIM. | Identify the intermediary changing signed content. Check whether the receiver uses trusted ARC results for a policy override. |
Match the observed DKIM result to the required fix.
Changing p=reject to p=none does not fix alignment. The p tag expresses the requested handling of DMARC failures; adkim sets DKIM domain matching. After a fix, test each affected sending domain and confirm its results in subsequent aggregate reports.
How to validate and monitor the setup
Validate the setup in two layers. First, check DNS records for obvious DKIM, SPF, and DMARC problems. A broad domain health review is useful before testing individual mail streams. Then watch real DMARC aggregate data to identify unaligned signing domains and authentication failures that need a message-header or DNS check.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Our DMARC reporting product, Suped, supports that workflow. The DMARC monitoring view maps each source to authentication and DMARC outcomes, then raises issues with concrete fix steps. ESP-domain signing becomes visible when the report shows a raw DKIM pass for the ESP domain alongside a failed DKIM alignment result for the visible From domain.
Use Suped to group mail by source and signing domain, identify streams where DKIM passes without alignment, record the required DNS or ESP change, and confirm an aligned DKIM pass after remediation. That sequence supports a controlled move toward DMARC enforcement without requiring teams to inspect raw aggregate XML.
In raw aggregate reports, RFC 9990 distinguishes auth_results/dkim, which contains the signing domain and verification result, from row/policy_evaluated/dkim, which records the DKIM result for DMARC, including alignment. A raw DKIM pass alongside a DMARC DKIM fail points to a domain mismatch. Aggregate data identifies affected streams; it does not always explain a cryptographic failure.
- Source grouping: Group traffic by source and DKIM signing domain to isolate the ESP that needs a change.
- Alignment checks: Separate a raw DKIM pass from a DKIM pass that satisfies DMARC.
- Fix steps: Use the issue guidance to publish selector DNS or request customer-domain signing.
- Verification: Confirm the repaired stream reports aligned DKIM before tightening DMARC policy.
Checks before enforcing DMARC
Best practices
Check that the DKIM d= domain satisfies the published DMARC mode before enforcing policy.
Ask every ESP for customer-domain DKIM signing, even when the ESP manages the private keys.
Test real sent mail because DNS checks alone do not prove the active signing domain.
Use relaxed domain matching deliberately, and document when strict matching is required.
Common pitfalls
Treating a raw DKIM pass for an unrelated ESP domain as enough for DMARC misses alignment.
Confusing From header signing with DMARC domain matching leads to bad fixes in reviews.
Assuming SPF will save every legitimate stream fails when forwarding changes the mail path.
Enforcing reject before all legitimate ESP streams pass DMARC risks blocking wanted mail.
Expert tips
Retain the previous selector key during rotation so messages in transit remain verifiable.
Review receiver-added Authentication-Results for header.d, not only the DKIM pass label.
Check aggregate reports by sending source to find ESPs still signing only provider domains.
Use subdomain signing for separate streams, and verify it against the configured DMARC mode.
Frequently asked questions
Not always. Relaxed DMARC alignment allows the DKIM signing domain and RFC5322.From domain to have the same Organizational Domain. Strict mode requires an exact domain match. For example, d=mail.example.com and From: billing@example.com satisfy relaxed alignment when both have example.com as their Organizational Domain, but fail strict alignment.
No. DKIM must sign the From header as part of the message integrity check. DKIM alignment is the separate DMARC check that compares the DKIM d= domain with the visible From domain.
Yes. DMARC passes when either SPF or DKIM passes with alignment. DKIM is still important because SPF often breaks during forwarding and many ESPs use their own Return-Path domains.
DMARC can pass through DKIM when any one valid signature has alignment with RFC5322.From. Another signature can fail or use an unrelated provider domain without cancelling the aligned pass.
Ask for aligned customer-domain DKIM signing, selector DNS records, a key rotation process, and confirmation that the From header is included in the signed header list.
Our DMARC reporting product, Suped, shows which sources pass DKIM, whether the signing domain has DMARC alignment, and what DNS or ESP changes are needed to fix failures.
