Check DKIM records clearly.

What this check means

DKIM (DomainKeys Identified Mail) lets a domain put a cryptographic signature on the email it sends. The receiving server fetches the domain’s public key from DNS and uses it to confirm two things: the message genuinely came from that domain, and it was not altered on the way. The public key lives in a TXT record at a name built from a selector — for example selector1._domainkey.example.com.

This tool reads that record for you. Give it a domain and a selector and it fetches the exact record, decodes the public key, and measures the key length. Leave the selector blank and it sweeps 30 selectors commonly used by mail providers and reports every key it finds. Everything runs in your browser over DNS-over-HTTPS — we never see the domains you check.

The verdicts follow one simple rule set: a valid record with a 2048-bit or stronger key is Passed; a working but weaker key — typically 1024-bit — is a Warning; a record that cannot verify mail (bad key data, or a key below the minimum receivers accept) is Failed; and if nothing is published at the name, the result is Not found.

Common DKIM issues

• Key weaker than recommended. Old setups often still sign with 1024-bit RSA. It works, but it is below the current recommendation and receivers trust it less every year. See our key length guide.
• Wrong or unknown selector. The DNS record must sit at exactly the selector your mail server signs with. A typo in either place breaks verification. The selector finder helps you locate what is actually published.
• Multiple records at one name. Two TXT records at the same selector make verification unpredictable — receivers may pick either one. Keep exactly one.
• Revoked key still in use. An empty p= tag revokes a key. If the mail server still signs with that selector, every message fails DKIM.
• Copy-paste damage. Line breaks, stray quotes or missing characters in the long p= value corrupt the key. Verifiers then return permerror — our troubleshooting guide covers this.

How to fix them

Most fixes follow the same path: generate a fresh key, publish it under a new selector, point your mail server or sending service at it, and confirm with a check. Our record generator creates the key pair in your browser and gives you the exact TXT record to paste into your DNS host. If you use a provider such as Google Workspace or Microsoft 365, the provider generates the key and tells you which records to publish — the checker here confirms you published them correctly.

When replacing a key, do not delete the old record straight away. Mail signed minutes before the switch still needs the old key to verify. The safe sequence is covered step by step in how to rotate DKIM keys.

Technical reference

A DKIM key record is a TXT record of tag=value pairs separated by semicolons (RFC 6376 §3.6.1). The tags this tool parses:

Key length is measured by base64-decoding the p= value and walking the DER structure to the RSA modulus, whose exact bit length is reported. If the key data does not parse as standard DER, the tool falls back to an estimate based on the data’s size and labels it as estimated. Ed25519 keys are always 256-bit by construction.

Related tools

DKIM is one of three signals receivers combine to authenticate mail. Check your SPF and DMARC records with the email DNS validator on dns.studio, and run a combined deliverability check — including BIMI logo records — at bimi.studio. For how the three standards fit together, read DKIM vs SPF vs DMARC.