How DKIM works
DKIM (DomainKeys Identified Mail) adds a digital signature to every message you send. Your email provider signs with a private key that never leaves its servers, and you publish the matching public key in DNS. The receiving server fetches the public key and checks the signature. If anyone changed the message on the way, or a server without the key tried to sign as you, the check fails.
The public key is a TXT record (or a CNAME pointing to one) like this:
selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"What the checker looks for
- A key at the selector. Without a selector, we try about 35 common names used by Google, Microsoft 365, Olvane, Amazon SES and other services.
- Key length. We estimate it from the published key: under 1024 bits fails, 1024 works but should be upgraded, 2048 or more passes.
- Revoked keys. A record with an empty
p=means the key has been withdrawn, and signatures made with it fail. - Test mode.
t=yasks receivers to treat failures leniently. Remove it once everything works.
Common DKIM problems
- The record was pasted with quotes or line breaks inside the key. The key must be one unbroken base64 string. Long records can be split into several quoted strings, but the key itself must not contain spaces.
- The record was created at the wrong name. Some DNS panels add your domain automatically, so
selector._domainkey.yourdomain.combecomesselector._domainkey.yourdomain.com.yourdomain.com. Enter onlyselector._domainkeyin those panels. - DKIM was never switched on at the provider. Publishing the key isn't enough with some services: you also have to enable signing in their admin panel.
Next steps
DKIM is what DMARC relies on most. Once your key checks out, confirm your policy with the DMARC checker, or follow our SPF, DKIM and DMARC setup guide.