Why aren't my DKIM records validating even though they are accurate?
Updated on 21 Oct 2026: We clarified DKIM lookup errors and added checks for key rotation and message changes after signing.
A DKIM record can look correct in a control panel while failing validation because it is published in the wrong DNS zone, queried with the wrong selector, hidden behind a broken CNAME, or not used by the message being tested. The usual fix is not to regenerate DKIM immediately. First, check the exact selector in the email header, the exact signing domain in the header, and the DNS host that actually answers for that domain.
Multiple DKIM records for the same sending provider are not automatically a problem. Two platforms can both send through Amazon SES, for example, and still use separate selectors without conflict. DKIM validation breaks when a validator asks DNS for selector._domainkey.example.com and the public key or CNAME is not there, even if the record looks correct in a control panel.
The fastest way to debug this is to test the DNS that receivers see, not the DNS screen your customer is editing. Suped's DKIM checker checks the selector and domain pair directly, then shows whether the DKIM record can be resolved and parsed.
Common causes of DKIM validation errors
If DKIM records look accurate but do not validate, start with one of six causes: the records were added to a DNS zone that is not authoritative, the Name field was entered in the wrong format, the validator is checking the wrong selector, the signing domain does not match the domain being checked, the record is a CNAME that does not resolve to the expected target, or the sender has not started signing with that selector yet.
- Wrong DNS host: The record was added in Shopify, Route 53, GoDaddy, Squarespace, or another panel, but the domain's NS records point somewhere else.
- Wrong hostname: The control panel appended the domain twice, or expected only the left-hand side of the DKIM hostname.
- Wrong selector: The selector in the test does not match the s= value in the email's DKIM-Signature header.
- Wrong domain: The lookup uses the customer domain even though the message is signed with the provider's default domain. That signature can pass DKIM while lacking the From-domain match DMARC requires.
- Broken CNAME: The selector hostname exists, but its CNAME target is wrong, missing, or returning SERVFAIL.
- Inactive key: Some senders show several generated selectors, while only one is active for signing at a given time.
DKIM validation workflow using the email header selector and signing domain to check DNS and CNAME records.
How DKIM validation really finds the record
DKIM validation does not search every DKIM-looking record on a domain. It uses two values from the DKIM-Signature header on the actual email: s= for selector and d= for signing domain. The receiver combines those into one DNS lookup. If the header says s=mail and d=example.com, the lookup goes to mail._domainkey.example.com.
That detail matters because many setup screens show DKIM records before the sender starts using them. A branded sending domain can have three CNAMEs waiting in DNS, but a live message can still be signed by the platform's default domain until the branded domain is verified and enabled. In that state, the records can be accurate and still irrelevant to the email being tested.
DKIM lookup formulatext
DKIM-Signature: s=selector1; d=example.com; DNS lookup: selector1._domainkey.example.com
|
|
|
|---|---|---|
Selector | Header s= | Which key DNS must return |
Domain | Header d= | Where the key must live |
DNS host | NS query | Which zone is authoritative |
CNAME | DNS answer | Whether the provider target resolves |
DKIM validation inputs and what each one proves.
Check the authoritative DNS zone
A common cause is a DNS authority mismatch. Someone adds the DKIM record to a panel they believe manages DNS, but the public internet asks a different provider. That can happen after a domain transfer, a Shopify domain setup, a storefront migration, a CDN change, or a split between registrar, DNS host, and website host.
This explains the frustrating case where the record is visible in a screenshot but every external lookup returns NXDOMAIN or no TXT record. The panel can be showing an inactive DNS zone. Confirm that before touching DKIM keys, because changing keys does nothing if the wrong nameservers are answering.
Authoritative DNS checksbash
dig NS example.com +short dig +trace selector1._domainkey.example.com TXT dig @ns1.dns-host.example selector1._domainkey.example.com TXT +norecurse dig @ns1.dns-host.example selector1._domainkey.example.com CNAME +norecurse dig selector1._domainkey.example.com TXT
Replace ns1.dns-host.example with an authoritative nameserver identified by the trace, and repeat against each server. Follow any delegation for _domainkey or the selector hostname. An authoritative server returns its CNAME without retrieving an external target, so query that target through a recursive resolver. Compare authoritative and recursive answers to distinguish publication errors from cached results.
Do not judge DKIM by the DNS admin page alone. Judge it by the authoritative answer for the exact hostname. A missing authoritative record or unresolved CNAME target prevents receivers from retrieving the key, even when the UI shows the record.
- Check NS first: Find the nameservers before editing or reissuing DKIM records.
- Query exact names: Look up the full selector hostname, not only the root domain.
- Respect negative caching: After fixing the record, allow cached NXDOMAIN, empty answers, or old keys to expire according to their TTLs. DNS propagation has no universal waiting period.
Why multiple Amazon SES DKIM sets are usually fine
Two services using Amazon SES can both ask a customer to publish DKIM records. That alone does not create a conflict. DKIM selectors are namespaced under the signing domain, so each service can use different selectors and different CNAME targets. Conflicts occur when a selector has multiple TXT records or a CNAME shares its hostname with a TXT record. Publishing a key under a different domain than the sender uses is a separate lookup error.
Valid coexistence
- Unique selectors: Each sender uses its own selector names.
- Same domain: Several selectors can live under one domain.
- Separate signing: Each email header points to the correct selector.
Conflicts and lookup errors
- Duplicate name: Multiple TXT records, or both CNAME and TXT records, use the same selector hostname.
- Wrong zone: Records are created where public DNS never looks.
- Wrong header: The email signs with a different selector or domain.
Amazon SES Easy DKIM uses CNAME records that lead to public-key TXT records. A receiver's TXT query still has to follow the CNAME chain. Validation fails if the public hostname is missing, its target is wrong, or the DNS chain returns SERVFAIL. Copy the current records for the correct AWS Region and account. The Amazon SES documentation explains that the hosted-zone suffix varies by AWS Region and identity, so use the exact targets supplied for your identity.
Illustrative SES DKIM CNAMEs for one hosted zonedns
selector1._domainkey.example.com CNAME selector1.dkim.amazonses.com selector2._domainkey.example.com CNAME selector2.dkim.amazonses.com selector3._domainkey.example.com CNAME selector3.dkim.amazonses.com
A practical validation workflow
Use a narrow workflow because DKIM failures get messy fast when people jump between provider dashboards, DNS screenshots, and delivery reports. The question stays the same: can a receiver reconstruct the public key lookup from the message header and get the expected key?
- Pull a real header: Send a test email through the exact sending path and inspect its DKIM-Signature header. If it is absent, enable signing on that sending path.
- Copy selector: Use the s= value, not the selector you expected the sender to use.
- Copy domain: Use the d= value. DKIM uses it for the key lookup, while DMARC compares it with the visible From domain for alignment.
- Query DNS: Look up the full hostname built from selector, _domainkey, and signing domain.
- Trace authority: Confirm the public nameservers are the same place where the record was added.
- Retest signing: After DNS validates, send another email and confirm dkim=pass in the receiving service's Authentication-Results header for the expected signing domain and selector.
Example receiver result for a passing DKIM signaturetext
Authentication-Results: mx.recipient.example; dkim=pass header.d=example.com header.s=selector1
DKIM checker
Check selector records and public key configuration.
?/7tests passed
If DNS returns a usable key but the delivered message fails DKIM, check that the public key matches the sender's private key and that signed content was preserved. Also check for cached keys after rotation. Suped's domain health check reviews published SPF, DKIM, and DMARC DNS records together; it does not verify a delivered message's signature or its From-domain match. Use the receiver's headers for those checks.
Check the DKIM hostname and record type
Provider setup screens often compress several ideas into one row: the DNS record name, the selector, the target, and the validation state. That is convenient, but it can hide the detail that matters. A DNS Name field might expect only selector._domainkey, while another panel expects the full hostname. Some panels silently append the root domain, and some show records in a managed DNS view even when another zone answers public queries.
Amazon SES domain identity screen with DKIM CNAME records.
Write down the fully qualified record name you expect to exist, then query it directly. If the external lookup fails, stop comparing screenshots and trace the authoritative nameservers. If the lookup succeeds but the provider still says pending, check whether it expects a CNAME or TXT record and an exact region-specific target. Some DNS panels require a trailing dot to keep a CNAME target fully qualified; follow the panel's format and check that it has not appended your domain to the target.
A DKIM record can be accurate and still fail if the exact public hostname does not return it. The most useful evidence is not a cropped screenshot. It is the selector, signing domain, record type, target value, authoritative nameservers, and raw DNS response.
Interpret DKIM error messages
The error text usually points to the right layer. Treat DKIM validation as two separate questions: does DNS publish a usable key, and does the message verify against that key? A message can carry multiple DKIM signatures. Use the receiving service's trusted Authentication-Results header to identify which signature it evaluated and why it failed; one failed signature does not mean every signature failed.
|
|
|
|---|---|---|
NXDOMAIN | Wrong hostname, missing record, or cached negative answer | Exact selector hostname and authoritative DNS |
SERVFAIL or dkim=temperror | DNSSEC, delegation, or nameserver failure | Authoritative responses, registrar DS records, and CNAME target |
No key | Wrong selector, missing record, or removed old key | Header s= and d=; recent key rotation |
DKIM pass, DMARC fail | Neither passing DKIM nor SPF has the required From-domain match | Compare d= with the visible From domain and check the SPF identity |
Bad key or dkim=permerror | Malformed or unusable key, duplicate records, or invalid signature syntax | Complete p= value, record count, and signature syntax |
Body hash mismatch | Signed body changed after signing | Compare direct and routed copies; inspect bh= and c= |
dkim=none | No DKIM signature | Enable signing on the actual sending path |
Intermittent fail | Inconsistent DNS answers, cached old keys, or different delivery paths | Compare authoritative servers, selectors, and receiver results |
Common DKIM symptoms and what to check next.
If the failure says the record is published but the key is invalid, look at syntax. Missing key characters, literal quotes copied into the value, malformed tags, or truncation can make a key unusable. An empty p= revokes the key; permitted folding whitespace alone does not invalidate it. For RSA errors, inspect the key format and length. A focused breakdown is useful when the error says invalid RSA key rather than no record found.
If the key is usable and matches the sender's private key, investigate changes to signed content. Compare a direct delivery with the failed copy, then check for footers, link rewriting, forwarding systems, or mailing list software that changed signed content. That case is closer to a body hash failure than a DNS publishing failure.
Inspect c= for canonicalization and h= for signed headers. Relaxed canonicalization tolerates specified whitespace changes, but not rewritten links or added body text. Apply outbound edits before signing. RFC 6376 defines these rules; ordinary unsigned header additions do not automatically break DKIM.
Check long TXT keys for truncation
A 2048-bit RSA DKIM public key often exceeds the 255-octet limit for one character-string inside a DNS TXT record. DNS can store one TXT record as several adjacent quoted strings, and DKIM validators concatenate those strings without inserting spaces. A record can therefore look split in a DNS response and still be valid.
The failure occurs when a DNS panel truncates the key, changes its characters, or publishes the chunks as separate TXT records. Keep one TXT record at the selector hostname, split its value into adjacent strings only when the DNS host requires it, then compare the concatenated public answer with the complete generated key.
Illustrative TXT chunking with placeholder key materialdns
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; p=FIRST_BASE64_CHUNK" "SECOND_BASE64_CHUNK" )
Do not create two separate TXT records for one selector. DKIM expects the TXT record to be unique at that selector name, while multiple quoted strings inside the same TXT record are valid and are joined during verification.
Prevent DKIM failures during key rotation
Key rotation breaks validation when signing switches before the new key is public, or an old key disappears while signed mail is queued. RFC 6376 recommends retaining old public keys for a reasonable validation interval.
- Publish the new key under a new selector and verify authoritative and recursive DNS answers.
- Allow relevant DNS caches to expire before switching the sender to the new selector.
- Test every sending path and confirm dkim=pass for the new selector.
- Keep the old selector through your delivery and validation window before retiring it.
For managed CNAME setups, keep all provider-required selectors published so automatic rotation can use them.
Monitor DKIM results with Suped
Suped is our DMARC reporting and email authentication platform. It keeps DNS checks, authentication results, and DMARC reporting in one workflow, so teams can monitor policy, see DKIM and SPF results by source, and investigate setup changes without relying on provider status screens alone.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For teams managing several senders, the practical problem is not only whether one DKIM CNAME exists. It is whether every sender is signing with the expected domain, whether DKIM matches the From domain for DMARC, and whether new failures appear after a platform change. Suped's DMARC monitoring shows those patterns over time in aggregate reports. Use the receiver's message headers to investigate an individual failure.
- Issue detection: Suped flags DKIM, SPF, DMARC, and DNS issues with steps to fix them.
- Source visibility: Suped shows which services are passing, failing, or sending without a DMARC domain match.
Views from the trenches
Best practices
Confirm the authoritative nameservers before trusting any DNS control panel screenshot.
Use the live email header selector and signing domain before checking a DKIM record.
Share copyable hostnames and DNS answers when asking others to review DKIM failures.
Common pitfalls
Adding records to a registrar panel fails when another provider hosts authoritative DNS.
Treating generated DKIM rows as active selectors leads teams to test the wrong key.
Assuming multiple SES senders conflict hides the simpler issue of missing DNS records.
Expert tips
Query the full DKIM hostname publicly, then compare that answer with the sender UI.
Separate DNS publication failures from signature verification and body hash failures.
Keep a written sender inventory so each platform has owner, selector, and domain data.
Expert view
Expert from Email Geeks says the first check is whether public DNS has the DKIM key at the exact hostname built from the selector and signing domain.
2024-10-02 - Email Geeks
Expert view
Expert from Email Geeks says screenshots are not enough for DKIM troubleshooting because reviewers need copyable selectors, domains, and raw DNS answers.
2024-10-02 - Email Geeks
Frequently asked questions
Yes. Different selectors can coexist on one domain. Each selector must resolve to one DKIM TXT record, directly or through a CNAME. Do not publish multiple TXT records or both CNAME and TXT records at the same selector hostname.
The most common reasons are that the record is in the wrong authoritative zone, the selector is wrong, the domain was appended twice, or a cached negative answer has not expired.
Use the provider selector for DNS setup checks, but use the selector in the real email header when debugging a delivered message.
Yes. A usable DNS record does not prove the sender uses its matching private key. Cached keys after rotation or changes to signed content also cause failures. Confirm dkim=pass on a fresh message using the receiving service's Authentication-Results header.
Amazon SES Easy DKIM supplies three CNAME records so it can manage signing keys and rotation. Keep the required records published for the correct AWS Region and account, use their exact target values, and test the selector in a live message.
One DNS TXT record can contain adjacent quoted strings to stay within the character-string limit. DKIM joins them without spaces, so the split is valid if no key characters are missing or reordered.
