DKIM failures are among the most confusing email authentication problems because they are invisible to the sender. Messages go out, the email service reports delivery, and the sender has no indication that anything is wrong. Meanwhile, receiving servers are marking every message as failed authentication.
This guide walks through a systematic process for diagnosing DKIM failures from first symptoms to root cause.
Step 1: Confirm That DKIM Is Actually Failing
The first step is to verify that DKIM is the actual problem, not SPF or DMARC or something else. The fastest way to do this is to send a test message to a service that shows the full authentication results.
Gmail's original message view (the "Show original" option from the three-dot menu on any message) includes the authentication results header. It shows each authentication method's result: PASS, FAIL, or NONE for DKIM, SPF, and DMARC. A result of dkim=fail or dkim=none confirms DKIM is the problem.
If you have DMARC aggregate reporting configured, the daily reports also break down authentication results by source. A sending source with 0% DKIM pass rate is failing DKIM on every message.
Step 2: Find the Selector in a Message Header
DKIM uses selectors to support multiple keys on the same domain simultaneously. The selector is chosen by the signing service and is embedded in every signed message in the DKIM-Signature header as the s= value.
Open any email from the affected sending service and view the full message headers. Look for a line starting with DKIM-Signature. Inside it, find s=value. That value is the selector. Write it down -- you will need it for the DNS lookup.
If there is no DKIM-Signature header at all, the sending service is not signing messages. Contact your email provider and verify that DKIM signing is enabled on their side.
Step 3: Look Up the DKIM Record in DNS
With the selector in hand, run a DNS lookup for the TXT record at:
selector._domainkey.yourdomain.com
Replace selector with the value from the header and yourdomain.com with your actual domain. Use the DNS Lookup tool for this query. You can also use the dig command directly if you are working on Linux or macOS:
dig TXT selector._domainkey.yourdomain.com
The result should be a TXT record that starts with v=DKIM1 and contains a p= field with a long Base64-encoded value. This is the public key.
Step 4: Interpret What You Find
There are four possible outcomes from the DNS lookup, each with a different diagnosis:
The record exists with a valid key. If the record is present and the p= field is non-empty, the DNS side is correct. The DKIM failure is happening for a different reason -- likely a mismatch between the key pair. The sending service may be signing with a private key that does not match the public key in DNS. This happens after key rotations where the new private key was deployed but the corresponding public key was not updated in DNS.
The record exists but the p= field is empty. An empty p= field is a deliberately revoked key. The signing service rotated keys and marked the old public key as revoked. If the sending service is still signing with the old key (which matches the revoked record), all signatures will fail. The sending service needs to be updated to use the new key pair.
The record does not exist at all. This is the most common cause of DKIM failures. The signing service is configured and generating DKIM signatures, but the corresponding DNS record was never published. The fix is to publish the public key that the signing service provides in its setup instructions.
The record exists but is malformed. Some DNS providers add quotes incorrectly, split the record in ways that prevent correct parsing, or truncate long key values. The DKIM specification in RFC 6376 defines the exact record format. A malformed record will produce a verification failure even if the key itself is correct.
Step 5: Verify the Public Key Matches the Signing Key
If the DNS record exists and appears correct but DKIM is still failing, the private key being used for signing may not match the public key in DNS. This is a less common problem but happens after provider migrations or manual key management.
Contact your email provider and ask them to confirm which private key is being used for signing with the failing selector. They should be able to show you the corresponding public key. Compare that public key to what is published in DNS. If they do not match, either the DNS record needs to be updated to the current public key, or the signing service needs to be pointed at the selector whose public key is already in DNS.
Step 6: Check for Multiple Conflicting DKIM Records
Some DNS providers allow multiple TXT records under the same hostname. If two DKIM records exist for the same selector, receiving servers may fetch either one, and only one will match the signing key. This produces intermittent DKIM failures that are very difficult to diagnose.
Run the DNS lookup for the selector hostname and verify that exactly one TXT record is returned. If you see two records, delete the one that does not match the current signing key.
Step 7: Test After Each Change
DNS changes take time to propagate. After updating or creating a DKIM record, wait for the TTL to expire before testing. If the TTL on the DKIM record is 3600 seconds (1 hour), wait at least that long before sending a test message and checking authentication results.
Run the DNS lookup again to verify the new record is visible before sending the test. What you see in the lookup should match what receiving servers see.
"DKIM failures almost always come down to one of two things: the public key was never published in DNS, or it was published once and then a key rotation on the provider side wasn't followed by a DNS update. Both are DNS problems, and both are visible in a single lookup of the selector hostname." - Dennis Traina, founder of 137Foundry
What the RFC 6376 Says About Verification
The receiving server's verification process is: extract the s= selector from the DKIM-Signature header, fetch selector._domainkey.domain as a TXT record, decode the public key from p=, and use it to verify the signature in the header. If any step fails -- the DNS record is missing, the key is empty, or the signature verification fails -- DKIM fails.
Understanding this process makes the debugging steps above logical rather than procedural. Each step in the diagnosis directly corresponds to a step in the verification.
Summary
DKIM failures are almost always caused by one of four things: missing DNS record, revoked key with empty p= value, mismatched key pair after a rotation, or a duplicate record conflict. The DNS Lookup on EvvyTools shows the TXT record content for any selector hostname, which resolves the first three causes in a single query.
The full guide to DNS lookups and email diagnostics covers DKIM alongside SPF, DMARC, and MX checks. The EvvyTools tools directory has additional developer tools for network and DNS diagnostics. For additional email-specific checks, MXToolbox provides blacklist status alongside DNS queries.
Photo by jihua shen on Pexels
Top comments (0)