DKIM Alignment Check: Verify and Fix It in 2026

Do not index

A campaign can show dkim=pass in Gmail and still fail DMARC, land in spam, or get rejected. That mismatch wastes leads, delays onboarding messages, and can damage the reputation of a domain that appears technically authenticated. The same ticket often includes an SPF warning, a blacklist concern, or a third-party sender that signs mail under the wrong domain.

The practical answer is a DKIM alignment check. It separates a valid cryptographic signature from a signature that aligns with the visible sender identity. This guide follows the header chain, DNS records, DMARC policy, and sender topology so teams can identify the failure instead of guessing.

Table of Contents

Why Your DKIM Pass Is Still Failing DMARC The two decisions in the header What DKIM Alignment Actually Means in 2026 Relaxed versus strict matching Reading the Headers for a DKIM Alignment Check A reliable inspection sequence Running DNS and Command Line Verification Check the policy separately Cross-check the live message Choosing Between Relaxed and Strict Alignment Decision matrix Common DKIM Alignment Failures and Their Causes Third-party signing domain Parent and child mismatch Forwarding and list rewriting Selector rotation Fixing DKIM Alignment Step by Step Verification checklist

Why Your DKIM Pass Is Still Failing DMARC

A marketing team sends a campaign with a visible From address at example.com. Gmail shows dkim=pass and arc=pass, yet the DMARC aggregate report marks DKIM as failing for alignment. The sending platform signed the message with a d= domain under a mail subdomain, while the message displayed the parent brand domain.

That result isn't contradictory. DKIM authentication validated the signature, meaning the signed content and headers matched the public key associated with the signing domain. DMARC then performed a separate identity check, comparing that signing domain with the domain in the visible From: header. A cryptographic pass doesn't automatically become a DMARC pass.

The two decisions in the header

The receiving server effectively answers two different questions:

Did the DKIM signature validate?The dkim=pass result answers this. It concerns the signature, selected headers, body hash, and public key.

Does the signing identity align with the visible sender?The DMARC result answers this. It compares the d= value in DKIM-Signature with the RFC5322.From domain under relaxed or strict alignment.

DMARC can pass when either SPF or DKIM produces an aligned identifier. That means a message with a non-aligned DKIM signature can still pass DMARC if SPF passes and the RFC5321.MailFrom domain aligns with the visible From domain, as described in RFC 9989. If neither path aligns, DMARC fails even when SPF or DKIM passes independently.

This matters for inbox placement because mailbox providers use authentication and alignment to evaluate whether a sender is authorized to use the brand shown to recipients. A failure can push legitimate campaigns, account notifications, and cold email into spam, especially when the domain already has reputation or complaint problems. Teams reviewing aggregate data should also learn how to read DMARC reports, rather than treating every DKIM failure as a broken key.

What DKIM Alignment Actually Means in 2026

DKIM alignment is the relationship between the domain in the d= tag of a valid DKIM signature and the domain in the visible From: header. DMARC evaluates that relationship using the adkim setting in the domain's DMARC record.

Relaxed alignment compares the organizational domains. A signature from mail.example.com can align with a visible From domain of example.com because both belong to the same organizational domain. Strict alignment requires the signing domain and visible From domain to be an exact match, including the full domain name.

A valid signature proves that the message was signed by a party controlling the private key and that the signed content wasn't altered in transit. It doesn't prove that the signing party is the same identity the recipient sees. A third-party provider can sign with its own domain, pass DKIM validation, and still fail DMARC alignment against the brand domain.

Relaxed versus strict matching

The distinction becomes important when a company separates marketing, transactional, and product mail into subdomains. Relaxed mode offers operational flexibility, while strict mode provides tighter control over which exact domain can authenticate visible mail.

Mode	Match Rule	Example d=	Example From	Result
Relaxed	Same organizational domain	`mail.example.com`	`example.com`	Passes
Relaxed	Different organizational domain	`provider.example`	`example.com`	Fails
Strict	Exact full-domain match	`example.com`	`example.com`	Passes
Strict	Parent and child domains differ	`mail.example.com`	`example.com`	Fails

If adkim is omitted, relaxed alignment is the default in common implementations. Setting adkim=s makes a subdomain-based signature fail when the visible From domain is the parent domain. That setting can improve brand isolation, but it also creates hidden failures when an ESP, CRM, or transactional system hasn't been configured for exact-domain signing.

The deliverability implication is direct. A team can publish a correct DKIM key, see dkim=pass, and still lose inbox placement because the signing domain doesn't match the identity customers recognize. The check must therefore evaluate signature validity and identifier alignment as separate gates.

Reading the Headers for a DKIM Alignment Check

Header inspection should follow a fixed order. Start with the RFC5322.From domain, which is the visible sender identity DMARC protects. Don't substitute the envelope sender or Return-Path, because those belong to the SPF path.

Next, locate every DKIM-Signature header. Messages can carry multiple signatures, so extract the d= value from each valid signature and note the selector in the s= tag. One signature may be aligned while another isn't, and the receiving server's final result depends on the signatures it accepts.

A reliable inspection sequence

Find From:Record the domain after the final @. This is the domain DMARC compares against.

Find each DKIM-Signature:Record d= and s=. The d= value is the authenticated signing domain.

Read Authentication-Results:Check dkim=pass or dkim=fail, then read dmarc=pass or dmarc=fail.

Check the reasonAn alignment reason points to a domain relationship problem rather than a bad key or modified body.

A simplified header chain might look like this:

From: alerts@example.com
DKIM-Signature: ...; d=mail.example.com; s=selector1; ...
Authentication-Results: ... dkim=pass header.d=mail.example.com;
    dmarc=fail header.from=example.com

The signature passed, but the DMARC result failed because the receiver evaluated the signing domain against the policy's alignment mode. Under relaxed alignment, a parent-child relationship can pass. Under strict alignment, it won't.

For a deeper header workflow, teams can use this diagnose spam issues guide. The key shortcut remains simple: if Authentication-Results reports dmarc=fail with an alignment reason, the problem is structural. Reissuing the same DKIM key won't fix a domain mismatch.

Running DNS and Command Line Verification

Header values show what the sending system used. DNS verification shows whether the receiving system can retrieve the public key for that exact signing identity. The selector and signing domain must resolve consistently, or the message may fail DKIM before alignment is even evaluated.

A practical workflow starts with the selector from the header:

dig TXT selector._domainkey.example.com +short

The query must target the domain represented by the d= value. If the header says d=mail.example.com and s=selector, the relevant DNS name is under selector._domainkey.mail.example.com, not automatically under the parent domain.

Check the policy separately

Inspect the DMARC record in parallel:

dig TXT _dmarc.example.com

Look for adkim=r or adkim=s. If the tag is absent, relaxed alignment is generally applied. An adkim=s policy makes the lookup and header comparison unforgiving because the signing domain must exactly match the visible From domain.

On Windows, the equivalent check is:

nslookup -type=txt selector._domainkey.example.com
nslookup -type=txt _dmarc.example.com

The public key record doesn't itself prove alignment. It proves that the selector and signing domain can publish a key. The header still has to advertise that same signing domain, and the visible From domain still has to satisfy adkim.

Cross-check the live message

Capture the raw source of a test message in Gmail and copy the complete DKIM-Signature line. Compare:

the s= selector with the DNS selector;

the d= signing domain with the DNS domain queried;

the d= signing domain with the visible From domain;

the resulting dkim= and dmarc= values in Authentication-Results.

DNS changes can take time to appear consistently across resolvers. Teams troubleshooting cold outreach can also review SPF DKIM DMARC for cold email for broader authentication context, but the live header remains the final evidence for this specific alignment check.

Choosing Between Relaxed and Strict Alignment

Relaxed and strict alignment aren't just “less secure” and “more secure.” They're choices about how the sender architecture is organized. A company with separate subdomains and several sending systems may create avoidable delivery failures by applying strict alignment before every source is mapped.

A single ESP sending from one branded subdomain can work well with strict alignment if the visible From domain and DKIM d= value are deliberately configured to match. A broader stack with marketing, transactional, support, and product mail often needs relaxed alignment while teams standardize each stream.

Decision matrix

Sender Topology	Recommended Mode	DMARC `adkim` Value	Notes
One controlled sender, exact branded domain	Strict	`s`	Works when From and `d=` are identical
One sender using a branded subdomain	Relaxed during migration	`r`	Parent-child matching avoids unnecessary failures
Marketing, CRM, and transactional subdomains	Relaxed	`r`	Supports multiple aligned subdomains
Third party signs with its unrelated domain	Neither is sufficient	`r` or `s`	The sender needs custom domain signing
High-control environment with audited sources	Strict after validation	`s`	Tightens identity control once all sources are known

A frequent mistake is assuming relaxed mode makes any third-party signature acceptable. It doesn't. A signature with d=espvendor.net doesn't align with example.com just because the policy uses relaxed mode. The two domains must still share the same organizational domain.

A sensible migration keeps adkim=r while teams inventory sources and review aggregate reports. Tightening to adkim=s should happen only after reports confirm that legitimate mail uses the exact From domain. Otherwise, strict mode can convert a hidden configuration difference into a visible stream of spam placement or rejection.

The right question is not “Which mode is safest?” It's “Which mode accurately reflects the domains the organization controls and the senders it has authorized?”

Common DKIM Alignment Failures and Their Causes

A real header can show dkim=pass and still fail DMARC. Start by placing the visible From domain, header.d, and DMARC result together. That separates a cryptographically valid signature from one that authenticates the domain used by the message.

Third-party signing domain

A sending provider may sign with its own domain while the brand appears in From:

From: billing@example.com
Authentication-Results: dkim=pass header.d=provider.example.net;
    dmarc=fail header.from=example.com

The diagnostic signal is dkim=pass paired with a header.d from an unrelated organizational domain. The sender needs custom DKIM signing under the brand domain or an aligned branded subdomain. Relaxed alignment does not make unrelated domains match.

Parent and child mismatch

A sender may use d=mail.example.com while the visible From domain is example.com. Relaxed alignment can accept that parent-child relationship, while strict alignment rejects it. Check the result against the published adkim setting rather than judging the two domain names in isolation.

Forwarding and list rewriting

Forwarders and mailing lists can remove the original signature or alter signed content. The final receiver may then report dkim=none or dkim=fail, even if an earlier hop recorded a passing signature. Review the complete Authentication-Results chain and any available aggregate report details to identify where the result changed.

Selector rotation

A sender can switch to a new selector before DNS publishes its public key. The selector record can also be placed under the wrong signing domain. In both cases, the header shows the new s= and d=, while the DNS lookup returns no usable key. Aggregate reports may show DKIM and SPF failures for the same From domain.

These failures affect delivery, not just authentication dashboards. A message quarantined or rejected under the published DMARC policy can lose replies and create support work for transactional systems. Messages that are merely filtered can also weaken domain trust when the same failures recur.

Fixing DKIM Alignment Step by Step

Remediation should begin with evidence from a real message, not with a new DNS record chosen from memory.

Identify every signing identity.Extract each DKIM-Signature header and record its d= domain and s= selector. Compare each value with the RFC5322.From domain.

Confirm the intended topology.Decide whether the sender should sign with the root domain, a branded subdomain, or a dedicated stream domain. The choice must match the visible From address and the adkim policy.

Republish the correct DKIM record.Publish the public key at the selector and signing domain the sender uses. A record under the parent domain won't help a signature using a child signing domain.

Update the sending platform.Enable custom domain authentication and set the visible From domain consistently. If the platform supports separate selectors for different streams, document each one.

Retest the live path.Send a test message, inspect the raw headers, and verify dkim=pass, an aligned header.d, and dmarc=pass.

Verification checklist

DNS key: The selector lookup returns the intended public key.

Header identity: The d= value matches the configured signing domain.

From identity: The signing domain aligns with the visible From domain under adkim.

Policy result: Aggregate reports show aligned DKIM authentication for legitimate sources.

Delivery test: Test messages reach expected mailboxes without authentication warnings.

Teams can use the Free DKIM Check to validate the published selector and identify record problems before investigating inbox placement. If an ESP controls the signing configuration for a branded subdomain, its support team may need to provision the selector and confirm the exact d= value.

Changing from relaxed to strict should wait until aggregate reporting confirms that every legitimate sending stream uses an exact match. The transition is a policy change, not a key repair, so it should be tested against live traffic rather than assumed safe.

mailX runs live checks across DKIM, DMARC alignment, DNS, blacklist status, SMTP and IMAP connectivity, and related infrastructure, then returns plain-English explanations and remediation steps. Visit mailX to run a free deliverability audit before a domain mismatch turns into another spam or rejection ticket.