Tools
DKIM record checker
Find the key, read its strength.
Look up the DKIM key receivers use to verify a domain’s mail. Enter the selector if you know it, or leave it empty to try the common ones, and see the key length, testing and revocation flags, and every tag explained.
How to check a DKIM record
- 01
Enter the domain
Use the domain in the From address, or the d= value of a DKIM signature.
- 02
Add the selector if you have it
It is the s= value of the DKIM-Signature header, or the name your provider gave you. Leave it empty to try the common ones.
- 03
Read the key
See the key type and length, the flags and every tag, with a note on anything receivers would reject.
How to find your DKIM selector
Every DKIM signature names its selector. Open the full headers of a message the domain sent, find the DKIM-Signature header and read two tags: d= is the signing domain and s= is the selector. Together they give the DNS name of the key, so s=selector1 and d=example.com mean selector1._domainkey.example.com.
The email header analyzer reads every DKIM-Signature in a pasted header and links each one straight back to this checker.
Your mail provider also shows the selector on the page where you set up DKIM. If you have neither, leave the selector empty and the checker tries the selectors the common providers use.
What is DKIM?
DKIM, short for DomainKeys Identified Mail, lets a domain sign the mail it sends. The sending server adds a DKIM-Signature header: a cryptographic signature over the body and a chosen set of headers, made with a private key only the sender holds.
The matching public key is published in DNS as a TXT record, at a name built from the selector and the domain. A receiving server reads both from the signature, fetches the key and checks that nothing it covers changed after signing.
A valid signature proves the d= domain took responsibility for the message. On its own it says nothing about the From address. DMARC links the two: it passes when SPF or DKIM passes for a domain that matches the From domain.
Because the signature travels inside the message, DKIM usually survives forwarding, where SPF breaks. It fails when something on the way changes what was signed, such as a mailing list adding a footer or a tag to the subject.
1024 or 2048 bits, and rotating a key
RSA keys are measured in bits. Verifiers ignore signatures from keys shorter than 1024 bits, 1024-bit keys still verify but are considered weak, and 2048 bits is the length providers now generate by default. Keys longer than 4096 bits go past what verifiers are required to handle.
A 2048-bit key is about 400 characters of base64, longer than the 255 characters one DNS string can hold, so it is published as two or more quoted strings that receivers join back together.
Ed25519 keys are much shorter, but not every receiver verifies them yet, so a domain that uses one signs with an RSA key as well.
Rotating a key without losing mail
- 01Publish the new key at a new selector, and leave the old one in place.
- 02Wait until the new record shows up here and its TTL has passed.
- 03Switch the sender to sign with the new selector.
- 04Keep the old key published for a week or so, because mail signed before the switch can still be in transit or queued.
- 05Retire the old selector by emptying p=, or delete the record.
Common DKIM problems and how to fix them
No record at the selector
Receivers fetch the key at selector._domainkey and the domain. When nothing is published there, every signature with that s= fails because there is no key to check it against.
How to fixConfirm the selector from the s= tag of a signed message, publish the record exactly as your provider shows it, then check again once DNS has updated.
The domain is doubled in the name
Many DNS hosts add the domain to every name you type, so entering selector._domainkey.example.com creates selector._domainkey.example.com.example.com, where no receiver looks.
How to fixEnter only selector._domainkey as the name, or end the full name with a dot if your DNS host accepts that.
The key is shorter than 2048 bits
1024-bit keys still verify but are considered weak, and keys under 1024 bits are ignored outright.
How to fixGenerate a 2048-bit key at a new selector, then rotate to it as described above.
The key is revoked
An empty p= withdraws the key. That is right for a retired selector, but a sender still signing with it produces signatures that fail.
How to fixPoint the sender at a live selector, or publish its current public key at this one.
Testing mode left on
t=y tells receivers the domain is still testing DKIM, so they treat its mail like unsigned mail and the signature earns no trust.
How to fixRemove t=y from the record once signatures verify.
A CNAME that points nowhere
Providers that manage keys for you ask for a CNAME. If the target has no key yet, or the CNAME has a typo, the lookup finds nothing.
How to fixCopy the target exactly from your provider, and finish verifying the domain in its dashboard so it publishes the key.
A key broken when it was split
One DNS string holds at most 255 characters, so long keys are stored as several quoted strings. A character lost or added where they meet breaks the key.
How to fixPaste the whole value and let your DNS host split it, or split it into quoted strings without losing anything. This checker joins them the way receivers do.
Two records at one selector
With more than one DKIM record at the same name, verifiers cannot tell which key to use, and signatures may fail.
How to fixKeep one record per selector. Put a new key at a new selector instead.
The key only allows SHA-1
h=sha1 limits the key to SHA-1, and signatures made with SHA-1 are no longer accepted.
How to fixRemove the h= tag, or set it to h=sha256, and sign with rsa-sha256.
DKIM selectors by provider
Where the key lives depends on who sends your mail. These are the selectors the common providers use, and how they ask you to publish them.
- Provider
- Google Workspace
- Selectors
- How it is published
- A TXT record you copy from the Admin console. google is the default prefix and can be changed.
- Provider
- Microsoft 365
- Selectors
- selector1, selector2
- How it is published
- Two CNAMEs pointing at Microsoft. The targets are shown in the Microsoft Defender portal.
- Provider
- Amazon SES
- Selectors
- three random tokens
- How it is published
- Three CNAMEs pointing at token.dkim.amazonses.com.
- Provider
- SendGrid
- Selectors
- s1, s2
- How it is published
- Two CNAMEs pointing at SendGrid, created during domain authentication.
- Provider
- Mailchimp
- Selectors
- k2, k3
- How it is published
- Two CNAMEs pointing at dkim2.mcsv.net and dkim3.mcsv.net. Older setups used k1.
- Provider
- Fastmail
- Selectors
- fm1, fm2, fm3
- How it is published
- Three CNAMEs pointing at Fastmail.
- Provider
- Proton Mail
- Selectors
- protonmail, protonmail2, protonmail3
- How it is published
- Three CNAMEs pointing at Proton.
- Provider
- Zendesk
- Selectors
- zendesk1, zendesk2
- How it is published
- Two CNAMEs pointing at Zendesk.
- Provider
- iCloud Mail with a custom domain
- Selectors
- sig1
- How it is published
- One CNAME pointing at iCloud.
- Provider
- HubSpot
- Selectors
- hs1-account, hs2-account
- How it is published
- Two CNAMEs that include your account number, pointing at HubSpot.
- Provider
- Mailgun, Postmark and Zoho Mail
- Selectors
- set by the provider
- How it is published
- Chosen when you add the domain, and shown in the provider’s dashboard.
Questions this raises
Let Nextmail publish your DKIM
Connect a domain and Nextmail writes its DKIM records with MX and SPF, so there is no key to copy and no selector to look up.
Google Workspace