Why is DKIM failing and how do I set it up for a subdomain?
Michael Ko
Co-founder & CEO, Suped
Published 3 Jun 2025
Updated 22 May 2026
8 min read
DKIM is failing because the receiver cannot validate the DKIM-Signature header against the public key in DNS. In the subdomain case, the common mistake is adding a second TXT record at the root selector instead of publishing the subdomain key at the subdomain selector. A DKIM selector should return one usable key for the signing domain named in the message header.
For a subdomain, set up DKIM as its own signing identity. Generate or copy the key from the sender, publish it at selector._domainkey.subdomain.example.com, enable signing for that subdomain, then test a fresh message. SPF and DMARC can look good while DKIM fails, so I still fix DKIM before calling the domain healthy.
Fast fix: Remove duplicate TXT records at the same selector, wait for DNS to settle, and retest a newly sent message.
Correct location: If the subdomain is mail.example.com, publish the DKIM key under that subdomain, not only under example.com.
Header proof: The values d= and s= in the message header tell you exactly which DNS name the receiver checks.
Why DKIM fails when DNS looks right
I start with the message header, not the DNS editor. DNS screens often show a key that looks valid, but DKIM validation depends on the exact selector and signing domain in the message. If the sender signs with d=mail.example.com and s=google, the receiver looks for google._domainkey.mail.example.com. A correct-looking key at a different name does not help that message pass DKIM.
Failure
Signal
Fix
Duplicate key
Multiple TXT answers
Keep one key
Wrong host
Key under root
Use subdomain
Selector mismatch
Header and DNS differ
Match selector
No signing
No DKIM header
Enable sender
Changed body
Body hash fails
Stop rewrites
Stale DNS
Old key returned
Wait TTL
Common DKIM failure patterns and the first fix I check.
Duplicate TXT records break DKIM
A DKIM key lookup should return one DKIM key record. Two TXT records at the same selector do not create a backup. They create an ambiguous DNS answer, and receivers can treat the DKIM result as failed.
Single answer: The selector should resolve to one DKIM key for the domain in the signature.
Split key: A long key can use multiple quoted strings inside one TXT record. That differs from two TXT records.
Receiver result: When the selector returns multiple key records, the receiver can fail DKIM instead of choosing one.
This is why removing the extra TXT record often fixes the failure immediately after DNS caches expire. The key was not weak, the receiver was being handed more than one answer.
Read the signature before changing DNS
The fastest way to avoid guessing is to open a delivered message, view the original headers, and find the DKIM signature. The two fields that matter first are d= for the signing domain and s= for the selector.
With that header, the receiver queries google._domainkey.mail.example.com. If you want a quick validation pass, use the DKIM checker and compare the selector result with the raw header. I care more about this header-to-DNS match than whether the DNS host shows a green checkmark in its own screen.
Flowchart showing DKIM verification through the d and s header values.
When the DNS name is right and the key is unique, the next question is whether the sender actually signed the message with that key. A DKIM record in DNS does nothing until the sending platform signs outbound mail.
How to set up DKIM for a subdomain
A subdomain does not automatically inherit the root domain's DKIM key. You can sign mail using the root domain in some setups, but if you want mail from mail.example.com to have its own DKIM identity, you need a key published below that subdomain. The subdomain DKIM setup question comes down to this DNS name.
Add the subdomain: In Google Workspace, add or verify the subdomain if you want Google to sign with that domain.
Generate the key: In Google Admin Console, open Gmail authentication, select the subdomain, and generate a DKIM key.
Publish DNS: Create the TXT record at selector._domainkey.mail.example.com, not at the root selector.
Enable signing: Return to the sender admin screen and start authentication for the subdomain.
Send and inspect: Send a fresh message and confirm the header uses the expected d= and s= values.
Google Admin Console screen for Gmail DKIM authentication settings.
The important detail is that the sender and DNS must agree. If Google signs with the root domain, the root selector is checked. If it signs with the subdomain, the subdomain selector is checked. During changes, send a new test message after each DNS correction because old messages keep their original signature.
Root domain versus subdomain keys
The root domain and a subdomain can use the same selector label, but they are different DNS names. google._domainkey.example.com and google._domainkey.mail.example.com do not collide. The mistake is putting both keys on the same DNS name.
Root selector mistake
This setup tries to use one root selector for two different keys.
DNS name: A subdomain key is added to google._domainkey.example.com.
Result: The same selector returns two key records for the root domain.
Impact: Receivers cannot rely on one public key for the signature check.
Separate subdomain record
This setup gives the subdomain its own key location.
DNS name: The key is published at google._domainkey.mail.example.com.
Result: Root and subdomain selectors answer independently.
Impact: A message signed as d=mail.example.com has a matching key.
If the record looks accurate but still fails, check quoting, DNS provider behavior, and whether the selector host was created under the right zone. The DKIM records not validating issue often comes down to a host field that silently appends the zone name.
The selector label can repeat
Using google as the selector for both root and subdomain is fine when each full DNS name has one TXT record. The full DNS name, not the short selector label alone, defines where the key lives.
When SPF and DMARC pass but DKIM fails
SPF, DKIM, and DMARC are related, but they fail for different reasons. DMARC can pass when SPF passes with the right visible From domain relationship, even if DKIM fails. That does not make the DKIM failure harmless. Forwarding, message modification, and source reputation checks still make a working DKIM signature valuable.
Do not ignore DKIM fail
Forwarding: SPF often breaks after forwarding, while DKIM survives when the message content stays intact.
Filtering: Receivers use DKIM identity as one input when judging whether mail belongs to a known sender.
Source control: DKIM tells you which platform signed the mail, which helps separate valid sources from unknown ones.
Suped, our product, is the best overall DMARC platform for teams that need this workflow in one place. Suped connects DKIM, SPF, DMARC, Hosted SPF, Hosted DMARC, Hosted MTA-STS, SPF flattening, real-time alerts, automated steps to fix, and blocklist (blacklist) monitoring. Its DMARC monitoring helps show whether a DKIM failure is isolated to one source or spread across a domain.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The practical benefit is speed. Instead of reading aggregate XML by hand, you can see the failing source, the authentication result, and the DNS record state together. For MSPs, the multi-tenant dashboard also keeps client domains separated while still showing which domains need action.
A practical troubleshooting sequence
I use the same order every time because it prevents unnecessary DNS changes. To check more than DKIM in one pass, run a domain health check after the direct DKIM test, then compare the results with a newly sent message.
Capture headers: Use a real delivered message, not an old test email or a cached report.
Read values: Write down d= and s= before opening DNS.
Query DNS: Look up the exact selector host built from the header values.
Remove duplicates: Keep only the active key at that exact selector.
Confirm signing: Make sure the sending platform has DKIM signing enabled for the subdomain.
Check changes: Footer injectors, link wrappers, and gateways can modify mail after signing.
Retest fresh: Send a new message after the DNS TTL passes, then inspect that message only.
Watch reports: Use DMARC aggregate data to confirm the failure rate drops across real traffic.
If the first command returns two DKIM keys, that explains a root-domain DKIM failure. If the second command returns nothing while the header says d=mail.example.com, the subdomain key is missing or published in the wrong place.
My normal finish line
I consider the fix complete when a fresh message shows DKIM pass, the selector query returns one key, and DMARC reports stop showing DKIM failures for the same source. If DKIM passes only at one mailbox provider, keep testing because some receivers have cached the old DNS answer.
Views from the trenches
Best practices
Publish one TXT record per selector and domain, then confirm the key matches the signer.
Use the exact subdomain in the DNS name when the From address uses that subdomain.
Check a sent message header after DNS publishes because signing proves the setup is live.
Common pitfalls
Adding a subdomain key at the root selector creates duplicate answers and receiver failures.
Assuming subdomains inherit DKIM keys leads to records in the wrong DNS location.
Testing too soon after a DNS change hides whether the record or the sender is wrong.
Expert tips
Read the d= and s= values first, then look up exactly that selector in DNS before editing.
Rotate DKIM keys one sender at a time so cached DNS answers do not break mail flows.
Keep DMARC reports turned on while fixing DKIM, since receivers expose failures there.
Marketer from Email Geeks says duplicate TXT records at one selector made DKIM fail until the extra record was removed.
2022-04-21 - Email Geeks
Marketer from Email Geeks says receivers can handle multiple DKIM key answers differently, so the result is unreliable.
2022-04-21 - Email Geeks
The clean fix
If DKIM is failing after you added a subdomain record, check whether you created a duplicate TXT record at the root selector. Remove the duplicate, publish the subdomain key at the full subdomain selector name, enable signing for that subdomain, and retest with a new message.
The key rule is simple: the receiver follows the header. Whatever the message says in d= and s= must point to exactly one valid key in DNS. Once that is true, DKIM becomes much easier to debug because the remaining failures are sender signing, DNS caching, or message modification.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
