What this checks
DKIM (DomainKeys Identified Mail) lets a sending server sign each message with a private key. The matching public key is published in DNS as a TXT record at <selector>._domainkey.yourdomain.com, and the receiving server fetches it to verify the signature. A valid signature proves the message was not changed on the way and that whoever signed it controls the DNS of the signing domain. Together with SPF, DKIM is what a DMARC policy is built on.
The selector is the part that makes DKIM different from SPF and DMARC: there is no fixed name to look up. Every sending service picks its own selector, and a domain can have as many as it has services. Google Workspace uses google, Microsoft 365 selector1 and selector2, Fastmail fm1 and fm2; many others use default, k1, s1 or mail. Amazon SES, and therefore Ackuna, generate a random token per domain that cannot be guessed.
This checker looks up <selector>._domainkey.<domain> for the selector you give it. If you leave the selector empty, it tries the same list of 33 common selectors our Chrome extension uses, one query each, and tells you which ones it tried. It follows a CNAME when the record is an alias at the provider (Amazon SES and Microsoft 365 work this way; Google Workspace publishes a plain TXT record), reads the key record (v=, k=, p=, t=, h=, s=), decodes the public key to tell you its size, and reports what is wrong.
How to read the result
Pass means a usable key was found and nothing needs attention. Warning means the key works but something should be fixed, for example the testing flag. Fail means receivers cannot verify signatures made with this key, for example because it is too short. Not verified means no active key was found under the selectors tried; that is not a failure, it only means the checker could not confirm DKIM from outside. Could not check means our resolvers did not get an answer; try again in a minute.
Below the status you see the record as published, each key with its size and flags, the alias it points at if any, and, after a sweep, the list of selectors that were tried. Each finding links to its explanation here.
No key under the common selectors
None of the common selectors has a DKIM record for this domain. This proves nothing about the domain: Amazon SES and Ackuna use random selector names, and many providers let you choose your own. Enter your selector in the field above to check it directly. You find it next to the DKIM record your sending service asked you to publish; it is the part before ._domainkey. In the Ackuna console it is shown on the sending domain page.
No key at the selector you gave
There is no DKIM record at <selector>._domainkey.<domain>. Either the selector is misspelled, or the record was never published, or DNS has not caught up yet. Compare the selector with what your provider shows, and remember that a DNS change can take up to an hour to spread. If the name is right and the record is missing, mail signed with it fails DKIM at every receiver.
Key revoked (empty p=)
The record exists but its p= tag is empty. That is how a key is retired after a rotation (RFC 6376 allows it on purpose): receivers see the record, learn that the key is no longer valid, and fail any old signature that still uses it. It is normal, and not a problem as long as your mail is now signed with a different selector. If this is the only selector your provider gave you, something is wrong at the provider.
Key shorter than 1024 bits
The public key has fewer than 1024 bits. Keys that short can be broken with modest effort, so Google, Microsoft and most other receivers refuse to verify them. Signatures made with this key are treated as if there were none. Generate a new key of at least 1024 bits, better 2048, at your sending service and publish the new record.
1024-bit key
A 1024-bit RSA key still verifies everywhere and is still allowed by the standard. The current recommendation is 2048 bits, which every major provider now offers. Rotate when your provider gives you the option; there is no urgency.
Testing flag (t=y)
The record carries t=y, which asks receivers to treat a failed signature as if there were no signature at all. It is meant for the first days of a rollout. Left in place, it quietly weakens DMARC: a spoofed message with a bad signature gets the same treatment as an unsigned one. Remove the flag once your real mail verifies.
Alias with no record (dangling CNAME)
<selector>._domainkey.<domain> is a CNAME that points at a name with no DKIM record. The alias was set up correctly at some point, and the key was removed on the other end, usually because the sending service was cancelled, the domain was removed from it, or the provider rotated its keys to new names. Mail still signed with this selector fails verification. Remove the record if the service is gone, or re-create the domain at the provider and publish the new values.
Public key could not be decoded
The p= value is not a public key the checker can read. Most often a part of the record was lost when it was copied into DNS, or quotes were added inside the key. Copy the record again from your provider, whole, and publish it as one TXT value.
No p= tag
A DKIM record must carry the public key in a p= tag. Without it there is nothing to verify against. Publish the complete record your provider gave you.
Wrong version tag
The v= tag, when present, must be exactly DKIM1. Any other value makes receivers ignore the record.
Syntax error
A part of the record is not tag=value. This usually comes from a stray semicolon or line break in the middle of the key. Copy the record again as one line.
Duplicate tag
A tag appears twice in the record. Receivers may read either value, so the result is unpredictable. Keep one.
Record too long
The record is longer than 4096 characters, far more than any real key needs. Only the start was analysed. Check what was published.
More than one record at a selector
Two or more TXT records at the same selector name look like DKIM keys. Receivers may pick either, so verification is unreliable. Keep one record per selector.
Some selector lookups got no answer
For a few selectors our resolvers did not get an answer. Those selectors are unknown, not absent. A re-check in a minute usually clears this.
The sweep stopped early
Each run has a budget of DNS lookups, and a sweep of common selectors can use it up, especially inside the full email DNS check. The result lists which selectors were tried. If yours is not among them, enter it directly.
The domain does not exist
Public DNS has no entry for the domain at all. Nothing can be published under a name that does not exist; check the spelling.
How to fix it
- Find your selector and record at the service that sends your mail. It shows a host like
selector1._domainkeyand either a long TXT value starting withv=DKIM1or a CNAME target. - Publish exactly that record at your DNS provider: the host is
<selector>._domainkey(some providers want the full name, some only the part before your domain), the type is TXT or CNAME as instructed, the value is copied whole. A key split over several lines must still be one TXT value. - Wait for DNS, then check the selector here. Pass means receivers can verify your signatures.
- Turn signing on at the provider if it has a separate switch, and send yourself a test message. In Gmail, "Show original" shows
DKIM: PASSwith the signing domain. - Remove
t=yonce real mail verifies, and rotate to a 2048-bit key when your provider offers it.
If you send with Ackuna: add your domain in the console and Ackuna creates the DKIM keys for you, hands you three CNAME records to publish, verifies them, and signs every message, whether it is a newsletter or a transactional email through the SMTP relay. The selectors are random tokens generated by Amazon SES; the console shows them, which is why the sweep on this page cannot find them.