What is DKIM?
DKIM (DomainKeys Identified Mail) cryptographically signs outgoing email. The sending server adds a DKIM-Signature header computed with a private key over selected headers and the body. The matching public key is published as a TXT record in the DNS of the sender domain. Receivers fetch it, verify the signature and thereby know that the message was not altered in transit and really came from a server that holds the domain's key.
Unlike SPF, DKIM survives forwarding, because the signature travels with the message rather than depending on the sending IP. That makes DKIM the more robust of the two authentication methods and the reason DMARC still passes for forwarded mail. Google, Yahoo and Microsoft have explicitly required DKIM from bulk senders since 2024.
Selectors: why the checker needs one
A DKIM record does not live directly under the domain but under a selector: selector._domainkey.example.com. The selector appears in the header of every signed message (s=) and allows several keys per domain, for example one for Google Workspace and one for the newsletter tool. Without the selector nobody can find the record, because DNS offers no way to list all names under _domainkey.
If you do not know the selector, open a message from the domain and look for the s= tag in the DKIM-Signature header. Alternatively leave the field empty: the checker then tries the selectors of common providers such as google, selector1 and selector2 (Microsoft 365), k1 (Mailchimp), brevo, mailgun, pm (Postmark), zoho, ionos and strato. That finds most setups, but not all. A custom selector like mail2024 is only found when you enter it.
How to read the result
For every selector found, the checker shows the record, the key type, the key length and a status:
- valid: record present, syntax correct, RSA with at least 2048 bits or Ed25519.
- short: RSA with 1024 bits. Still works, but considered transitional. Move to 2048 bits at the next rotation.
- too short: RSA below 1024 bits. Many receivers ignore such signatures and treat the message as unsigned.
- revoked: the p= tag is empty. The key was deliberately withdrawn; mail signed with this selector fails.
- test mode: the t=y tag is set. Receivers are asked not to penalise failures. Remove it for production.
- invalid: the record has no p= tag or the key is not valid Base64.
Anatomy of a DKIM record
The record is a TXT record made of tags separated by semicolons. Only p= with the Base64 public key is mandatory. v=DKIM1 and k=rsa are the defaults and may be omitted, but they belong in for readability. A typical record for the selector google:
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0g5x...IDAQAB"Common mistakes
These are the DKIM problems we see most often:
- Record not found: wrong selector, typo in _domainkey, or the record was left behind during a hosting migration.
- Key split badly across strings: long keys must be split into DNS strings of at most 255 characters. Some DNS panels do not do this automatically and p= ends up truncated.
- CNAME to the provider points nowhere: Microsoft 365 and many newsletter services use CNAME delegation. If the provider removes the key, the record is gone even though your own DNS looks unchanged.
- Old key after rotation: the provider introduced a new selector, DNS still has the old one. Mail is no longer signed, or signed with a key that no longer exists.
- 1024 bits for years: setups from 2015 often still use short keys. Plan a rotation to 2048 bits.
Monitor DKIM continuously
DKIM records disappear quietly: a provider rotates its key, a zone is recreated, a CNAME points to nothing. Mail keeps going out, lands in spam more and more often, and nobody notices until a client asks. DomainWarn checks the configured selectors of all client domains regularly and reports when a record is missing, revoked or when the key changes.
Frequently asked questions
- How do I find my domain's DKIM selector?
- The DKIM-Signature header of a sent message contains s=selector. In Gmail use "Show original", in Outlook the message options. Or leave the field empty: the checker tries common selectors automatically.
- Are 1024 bits enough for DKIM?
- They still work, but RFC 8301 recommends at least 2048 bits and some receivers downgrade shorter keys. Switch to 2048 bits at the next key rotation.
- Can a domain have several DKIM records?
- Yes, as many as you like, each under its own selector. That is the normal case when several services send on behalf of the domain. Each service signs with its own selector.