DKIM adds a cryptographic signature to every message you send, and the receiver verifies it against a public key published in your DNS. It is the strongest of the three authentication records because it survives forwarding, and it is the one people most often assume is working when it is not.
The reason is a small piece of trivia: you cannot look up a DKIM record without knowing its selector.
Selectors, which is the whole difficulty
DKIM keys live at <selector>._domainkey.yourdomain.com. The selector is chosen by whoever generated the key, so there is no single place to look. Common ones: google for Workspace, selector1 and selector2 for Microsoft 365, and a provider-specific string for everyone else.
If a checker says “no DKIM record found”, the usual cause is the wrong selector rather than a missing key. Get the correct one from your sending platform’s DNS instructions, or read it out of the DKIM-Signature header of an email you have already sent, the s= value is the selector.
What to verify
| Check | What good looks like |
|---|---|
| Record found at the selector | A TXT record containing v=DKIM1 and p= followed by a long key |
| Key length | 2048-bit where the provider supports it. 1024 is acceptable, shorter is not |
| Key not truncated | Some DNS hosts split long TXT values. The reassembled value must be complete |
| No revoked key | An empty p= means the key is revoked and signing will fail |
| One selector per sender | Each platform that sends as your domain needs its own key and selector |
The failures worth knowing
Truncated keys. A 2048-bit key exceeds the 255-character limit of a single TXT string, so it must be published as multiple quoted strings that resolvers join. Some DNS interfaces handle this and some mangle it, and the result is a record that looks present and does not verify. If DKIM fails on a key you are sure is correct, this is the first thing to check.
Copy-paste damage. Line breaks and stray spaces inside the key value break it. Paste as one continuous string.
Rotation without republishing. If a provider rotates keys and the new public key is not published, signing fails from the moment of rotation with no other symptom.
A new domain nobody finished. On an estate of a dozen lookalike sending domains, one domain missing its DKIM record is easy to miss and produces exactly the sort of partial deliverability problem that is blamed on copy. Check per domain. Bulk DNS management exists for this.
Why DKIM matters more than SPF for cold email
SPF breaks on forwarding, because the forwarding server becomes the envelope sender. DKIM’s signature travels with the message, so it survives, which makes it the mechanism DMARC can rely on, and the one that carries your domain’s identity through mailing lists and auto-forwards. DMARC alignment depends on it.
Next: checking DMARC, checking SPF, or how the three fit together.
Frequently asked questions
How do I check my DKIM record?
Look up the TXT record at selector._domainkey.yourdomain.com. You need the selector, which is set by whoever generated the key, google for Workspace, selector1 and selector2 for Microsoft 365, or a provider-specific string.
How do I find my DKIM selector?
Take it from your sending platform’s DNS instructions, or read the s= value in the DKIM-Signature header of an email you have already sent.
Why does my DKIM record say not found?
Usually the wrong selector rather than a missing key. The second most common cause is a truncated record: a 2048-bit key exceeds the 255-character TXT string limit and some DNS interfaces mangle the split.
What key length should DKIM use?
2048-bit wherever the provider supports it. 1024-bit still verifies but is weaker, and anything shorter should be replaced.
Is DKIM more important than SPF?
For cold email, arguably yes. SPF breaks when a message is forwarded, while DKIM’s signature travels with the message, which is why DMARC alignment usually rests on DKIM.