DKIM Record Checker

What is a DKIM record?

A DKIM record is a TXT record in your DNS holding the public half of the key your mail server signs with. It lives at a name built from a selector — something like mail._domainkey.example.com — and it is a list of tag=value pairs. The one that matters is p=, which carries the public key itself in base64.

A receiving server fetches that record, uses the key to check the signature on your message, and decides whether the message really came from your domain. If the record is missing, malformed or revoked, the check fails and your mail is treated as unsigned.

This DKIM checker reads a pasted record and tells you what is actually in it: the key type, the real key size in bits, and every rule from the specifications that the record touches — including the two that are easy to leave switched on by mistake.

How to use it

1. Look up your record and paste it in. It is the TXT record at selector._domainkey.yourdomain.com. Your DNS provider will show the value; a browser cannot resolve DNS, so this tool reads what you paste rather than fetching it. The four sample buttons cover a 1024-bit key, a 2048-bit one, a record left in testing mode, and a revoked key.
2. Read the key size. This is the real modulus size, decoded from the key itself rather than guessed from the length of the base64. A key that is smaller than it should be is the single commonest thing wrong with a working DKIM setup.
3. Work through the findings. Each one says whether it is an error, a warning or just a note, and which specification it comes from. Notes are things worth knowing that are not wrong — an unrecognised tag is a note precisely because the standard says verifiers must ignore tags they do not know.

1024 or 2048 bits, and why the answer is both

RFC 8301 says two different things about key size in the same short section, and the distinction is the most useful thing on this page. Signers MUST use RSA keys of at least 1024 bits. Signers SHOULD use RSA keys of at least 2048 bits. Those are different words in a standards document and they mean different things: a MUST is a requirement, a SHOULD is a strong recommendation you may have a good reason to ignore.

So a 1024-bit DKIM key is not broken and not invalid. It satisfies the requirement and misses the recommendation. That matters because it is extremely common: probing the largest domains by trying ten of the usual selector names, 25 of 30 published a record that could be found at all, and 14 of those 25 — a clear majority — were still 1024-bit. This tool reports that case as a warning rather than an error for exactly that reason.

The practical argument for moving to 2048 is not that somebody is factoring your key this afternoon. It is that DNS TXT records are awkward to change, rotation is a job nobody schedules, and the key you publish today will still be there in five years. The practical argument against rushing is that some very old verifiers had trouble with keys larger than 2048, which is why the standard recommends rather than requires.

The same RFC retires SHA-1 outright: it must not be used. If your h= tag lists sha1 alongside sha256 you gain nothing and offer a weaker option, and if it lists only sha1 the record is simply out of date.

The two flags that quietly cost you nothing and everything

An empty p= tag is not a broken record — it is how a key is revoked. Publishing p= with nothing after it is the documented way to say this key is no longer valid, and signatures made with it stop verifying. That is exactly what you want when retiring a key and exactly what you do not want when a copy-and-paste dropped the value.

t=y puts the key in testing mode, and its effect is stronger than the name suggests: a verifier must not treat a failed signature as a reason to do anything. It is there so you can publish a key and watch what happens without risking real mail, and it is very easy to leave on afterwards. A domain in testing mode gets almost none of the benefit of DKIM while looking, in every dashboard, as though it is fully set up.

Neither of these makes the record invalid, so a checker that only reports errors will tell you the record is fine. Both are reported here as warnings, because the record is well formed and the effect is not what most people intend.

Honest limitations

A browser cannot resolve DNS, so this tool cannot fetch your record for you and cannot tell you whether the record exists at the name you think it does. It checks what you paste. That is the same constraint the SPF checker on this site works under, and it is a real one rather than a design choice.

It also cannot tell you whether the key matches the private key your mail server is actually signing with. That is the other half of a working DKIM setup and it can only be tested by sending a message and reading the headers on the far side. A perfectly valid record can sit in front of a mismatched key.

Selectors are not discoverable. There is no way to ask a domain which selectors it publishes, which is why every DKIM lookup tool asks you for one and why the survey quoted above had to guess ten common names. If you do not know your selector, the header of any signed message you have sent carries it in the s= field.

The key size is read by walking the DER structure of the public key, which is a handful of nested length-prefixed blocks and needs no cryptography library. It is checked against the sizes Node's own crypto module reports for real generated keys, at 1024, 2048, 3072 and 4096 bits. Reading the size from the length of the base64 string instead — which is a reliable shortcut for standard RSA keys — is used only as a cross-check in the tests, never as the answer.

Why is it free?

The parsing and the key decoding both run in your browser. There is no server involved, so there is nothing to bill for and no account to create.

Nothing is uploaded and nothing is stored. Your record is a public DNS value in any case, but it never leaves the page — reload and it is gone.