Troubleshooting
Why DKIM verification fails (and how to fix each cause)
DKIM verification fails for four main reasons: the selector in the message header doesn't match a published DNS record, the public key was truncated when pasted, something modified the message body after signing, or the record was added with the wrong host. Query the selector directly with dig TXT selector._domainkey.yourdomain.com to tell which.
Why DKIM verification fails (and how to fix each cause)
The concrete reasons a DKIM check fails after you've published the key: selector mismatch, a truncated public key, DNS flattening, and message modification in transit.
DKIM signs your message with a private key and publishes the matching public key in DNS. Receivers verify the signature to confirm the message is authentic and unmodified. A failure means the signature didn't validate — which is worse than having no DKIM at all, because it looks like tampering.
Find the selector, then query it
The signature header names its own selector. Open a received message's raw source and find the DKIM-Signature header: the s= value is the selector and d= is the signing domain. Then query that exact record:
# From the DKIM-Signature header: s=selector1; d=yourdomain.com
dig TXT selector1._domainkey.yourdomain.com +shortIf that returns nothing, the record isn't published where the signature says it should be — that is cause 1 or 4 below.
Cause 1: selector mismatch
Each key pair has a selector, and a domain can host several. If you rotated keys, or copied a record from another provider's instructions, the message may be signed with a selector that has no published record. The fix is to publish the record for the selector actually in use, not to change the signature.
Cause 2: the public key was truncated
DKIM public keys are long — a 2048-bit key exceeds the 255-character limit of a single TXT string. Some DNS UIs silently truncate it; others require you to split it into multiple quoted strings that get concatenated. A truncated key produces a record that exists but never validates, which is the most confusing version of this failure.
Compare lengths
Compare the p= value in DNS against the one you were given, character for character. If DNS is shorter, it was truncated. Splitting into multiple quoted strings within one record is correct; splitting into multiple records is not.
Cause 3: wrong host field
The record belongs at selector._domainkey. Many DNS providers append the zone automatically, so entering the fully-qualified name yields selector._domainkey.yourdomain.com.yourdomain.com. Query the record to confirm rather than reading the UI.
Cause 4: the message changed after signing
DKIM signs a hash of specified headers and the body. Anything that rewrites the message after signing breaks the signature — most often a mailing list appending a footer, an email security appliance rewriting links, or a forwarding rule. If your own sends verify but forwarded copies fail, this is why, and it isn't something you can fix on the sending side.
Rotating a DKIM key without downtime
Rotation is where teams cause their own outage: publish the new key, switch signing, and remove the old record too early and in-flight mail fails verification. The safe order is make-before-break — publish the new selector, verify it resolves, switch signing to it, and only remove the old record once no mail is signed with it.
Frequently asked questions
Can I have multiple DKIM records?
Yes, and you should during rotation. Each lives at its own selector._domainkey host, so they don't conflict the way multiple SPF records do. Keeping the previous selector published until nothing signs with it is what makes a zero-downtime rotation possible.
Why does DKIM pass for direct mail but fail when forwarded?
Because forwarding often modifies the message. A mailing list adding a footer, or a security gateway rewriting URLs, changes the body after it was signed, so the hash no longer matches. This is a known limitation of DKIM and is the reason DMARC accepts an SPF pass as an alternative alignment path.
Is a 1024-bit DKIM key still acceptable?
It validates, but 2048-bit is the current recommendation and what major providers expect for bulk sending. The main reason 1024-bit persists is that 2048-bit keys exceed a single TXT string's 255-character limit, which some DNS interfaces handle badly.