By Ahmet Karaca · Updated · Checked against RFC 6376 (DKIM), RFC 8301 (DKIM key sizes), RFC 8463 (Ed25519 for DKIM), Google Workspace's DKIM setup guide, Microsoft's DKIM guide for Microsoft 365 and Amazon SES: creating a domain identity on
What DKIM proves
DKIM adds a cryptographic signature to every message. Receivers fetch your public key from DNS and verify that the message wasn't changed in transit and really came from a server holding your private key. Because the signature survives forwarding, DKIM is usually what carries DMARC for newsletters and help-desk tools. What is DKIM? walks through signing and verification end to end.
Where the key lives and how it is written
A DKIM public key is a TXT record at a name built from two parts of the signature: the selector (s=) and the signing domain (d=), joined by _domainkey. A signature with s=s1 and d=example.com is verified with the key at:
s1._domainkey.example.comMany services ask you to publish a CNAME at that name instead, pointing to a key they host and can rotate for you. Microsoft 365 does this with selector1 and selector2. A receiver asking for the TXT record follows the CNAME to the key. The record itself is a list of tags, defined in RFC 6376:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…| Tag | Meaning |
|---|---|
| v=DKIM1 | Version. Optional, but if present it must be the first tag and exactly DKIM1. |
| k= | Key type: rsa (the default) or ed25519. |
| p= | The public key, base64-encoded. Required. Empty means the key was revoked. |
| t= | Flags. y means the domain is testing DKIM; s forbids subdomains in the signature's i= tag. |
| h= | Hash algorithms this key may be used with. Optional; all are allowed by default. |
| s= | Service types. Optional; the default * covers email. |
| n= | Notes for humans. Programs ignore it. |
A 2048-bit RSA key is longer than the 255 characters one TXT string can hold, so it has to be split into several quoted strings in the same record. Some DNS hosts do that for you; with others you enter the strings yourself. Receivers join them back together. An Ed25519 key is only 256 bits and fits in one string. The matching signature in each message looks like this, with d= and s= pointing at the key:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date; bh=…; b=…What each part of the result means
- A card for each key we found. It names the record, such as
s1._domainkey.example.com, and shows the key type and length, for exampleRSA · 2048-bit. A key whose record hast=yalso says test mode, and a record with an emptyp=shows as Revoked key. - Findings. Problems first, then warnings, then notes, each naming the selector it is about. With no findings you see "No problems found".
- Selectors checked. Every selector we looked up, starting with the one you entered. If your selector isn't in this list and you didn't enter it, we didn't look for it.
Finding no key on these selectors doesn't prove a domain has no DKIM. It means none of the names we asked about holds one.
Common errors and how to fix them
These are the findings the checker can report, with the message you see in the result. Selectors, domains and numbers below are examples.
- Warning: "We didn't find a DKIM key on common selectors. Your provider may use a custom one; enter it to check." Find the selector in the
s=tag of a message you sent, or in your provider's DKIM settings, and enter it in the Selector field. How to find your DKIM selector covers three ways. - Problem: "The 's1' key isn't valid base64-encoded RSA key material." The
p=value is damaged, usually by a copy-paste that dropped characters, added quotes in the middle or cut the key where the DNS host splits long values. Copy the value again from your provider. - Problem: "The 's1' key is only 512 bits. Receivers may ignore it; rotate to 2048 bits." RFC 8301 tells verifiers not to accept signatures made with RSA keys under 1024 bits. Generate a new key, publish it under a new selector and switch signing to it.
- Warning: "The 's1' key is 1024 bits. 2048-bit keys are the current recommendation." It still verifies, but RFC 8301 says signers should use at least 2048 bits. Rotate when your provider offers it; the DKIM generator creates one if you sign mail yourself.
- Warning: "The 's1' key is in test mode (t=y); some receivers ignore DKIM failures from it." RFC 6376 tells verifiers to treat mail signed in test mode like unsigned mail. Remove
t=yonce signing works. - Note: "The 's1' key has been revoked (empty p=)." An empty
p=is how a domain withdraws a key on purpose. If the selector is still in use, publish its key again. - Problem: "We couldn't query DNS for 3 selector(s) on example.com. Try again in a minute." Some lookups failed and none found a key, so we can't tell whether DKIM is missing. We don't keep this result; check again shortly.
How we check
DNS can answer "what is at this name?" but not "which names exist under _domainkey?", so no tool can list a domain's selectors. We ask about specific ones instead. If you enter a selector, we look it up first. Then we try 36 selectors that common email services use:
google, selector1, selector2, k1, k2, k3, s1, s2, default, dkim, mail, smtp, key1, key2, mandrill, mxvault, zoho, zmail, resend, mailjet, cm, sig1, protonmail, protonmail2, protonmail3, fm1, fm2, fm3, brevo1, brevo2, everlytickey1, everlytickey2, mailo, pm, mta, dk.
For each one we request the TXT record at selector._domainkey.yourdomain. A CNAME is followed by DNS like it would be for a receiver. A TXT record without a p= tag isn't a DKIM key, so we skip it, which keeps an unrelated verification record at the same name from showing up as a broken key.
For every key we find:
- We read
k=to learn the key type. Without it the key is RSA, as RFC 6376 specifies. - For RSA we decode the key and measure its real length, rather than guessing from the length of the text. Under 1024 bits is a problem, from 1024 up to 2048 a warning, and 2048 bits or more passes. An Ed25519 key is always 256 bits and gets no length warning.
- We report an empty
p=as a revoked key and at=yflag as test mode.
If at least one lookup failed and no key turned up, we report a DNS problem instead of "no DKIM", because the selector that failed might be the one that holds your key.
What it doesn't check
- Selectors outside the list unless you enter them. Services such as Amazon SES generate random selector names, and those can only be found from a signed message or the provider's settings.
- Whether your mail is actually signed with the key. A published key proves nothing until a message carries a signature that uses it; the email header analyzer reads the DKIM result of a real message.
- The signature algorithm or the headers a sender signs, which are in each message, not in DNS.
A check has 10 seconds to finish, and we reuse a result for 5 minutes unless a lookup failed. Each selector you enter is cached on its own, so trying another one runs a fresh check.
Not sure how to set DKIM up for your provider? Pick it from the setup guides.