Finds the published keys, reads the key size and says what is wrong.
DKIM signs each message with a private key your mail service holds, and publishes the matching public key in your DNS. A receiver that can verify the signature knows the message was not altered and really came from a service you authorized. DMARC needs SPF or DKIM to pass, and DKIM is the one that survives forwarding.
A DKIM key lives at a name only the sender knows, so there is no way to ask a domain for the list. This check looks for keys at the selectors the common mail providers use, and you can give it a selector of your own. Each key found is read: its type, its size, whether it is revoked and whether it is still in testing mode.
When your mail service sends a message it hashes the body and a chosen set of headers, signs the hash with a private key, and adds a DKIM-Signature header carrying the signature, the domain (d=) and the selector (s=). The receiver reads those two values, fetches the public key from DNS at selector._domainkey.domain, and verifies the signature. If it verifies, the signed parts arrived exactly as they were sent and the sender held the key.
That is why DKIM survives forwarding when SPF does not. SPF asks whether the server that delivered the message is allowed to send for the domain, and a forwarder is not. DKIM asks whether the message is intact, which stays true however many hops it takes.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=selector1;
h=from:to:subject:date:message-id;
bh=<body hash>; b=<signature>| Tag | Means | What it should say |
|---|---|---|
| v | The record version. | DKIM1, and it must come first. |
| k | The key type. | rsa on nearly every domain; ed25519 where both ends support it. |
| p | The public key. | A long base64 value. Empty means the key is revoked. |
| h | Hash algorithms the signer will use. | Leave it out, or sha256. Never sha1 alone. |
| t | Flags. | Leave it out. t=y means testing, and a receiver may ignore a failure. |
| s | Service type. | Leave it out, or email. |
| n | A note for whoever reads the record. | Anything, or nothing. It has no effect. |
| What you see | Cause | Fix |
|---|---|---|
| No key at any selector we try | The provider uses a selector nobody can guess, or signing was never switched on. | Read the s= value from a message you sent, then check that selector here. |
| The signature fails on some messages only | A mailing list or a scanner is rewriting the subject or the body after signing. | Sign with relaxed canonicalization, and do not let an appliance edit mail after it is signed. |
| The key verifies but DMARC still fails | The signing domain is the provider's, not yours, so it does not align with the From address. | Set up DKIM with your own domain as d=, which is what a provider's custom DKIM option does. |
| A 1024-bit key | It was created years ago, when that was the default. | Rotate to 2048 bits. Keys under 1024 bits are not acceptable at all. |
| Two keys at the same selector | Two TXT records were left at one name, which is ambiguous. | Keep one. Delete the other, or move it to its own selector. |
| The record was rejected by the DNS panel | The key is longer than the 255 characters one TXT string allows. | Split it into several quoted strings in one record; most panels do this for you. |
Messages already in flight were signed with the old key, and receivers may check them minutes or hours later. So a rotation overlaps rather than switches. Where the selector is a CNAME pointing at your provider, the provider does all of this for you and nothing here needs doing.
No. It means no key was published at the selectors we try. Your provider may use a selector we do not know. Send yourself a message, open the original, and read the s= value in the DKIM-Signature header: that is your selector. Then enter it here.
In the DKIM-Signature header of a message you sent (the s= value), or on the DNS setup page of the service that sends your mail.
Once or twice a year is common practice, and your provider may do it for you if the selector is a CNAME pointing at them. Rotation limits what a stolen private key is worth.
Yes, and most domains should. Each service that sends mail as your domain signs with its own selector, so they do not collide.