How DKIM uses selectors
A signing server adds a DKIM-Signature header to each message: d= names the signing domain, s= the selector, and b= holds the signature over the chosen headers and the body hash. The receiver builds the name s._domainkey.d, fetches its TXT record, takes the public key from p= and verifies the signature. If the body or a signed header changed in transit, verification fails.
Selectors exist so a domain can publish several keys at once: one per sending service, or an old and a new key during rotation. No DNS query lists them, which is why the checker either needs the selector from a real message or probes names providers are known to use, such as google, selector1, selector2, k1 and s1.
What the checker looks up
With a selector, it queries one name: selector._domainkey.yourdomain. If you paste the full name, the ._domainkey part and everything after it is stripped. A selector may contain letters, digits, dots, hyphens and the _ character. Without a selector, the 49 common names are queried twelve at a time and every name that returns a record containing v=DKIM1, k= or p= is listed.
Keys delegated by CNAME, which is how many providers hand you a record to publish, resolve the same way because the resolver follows the CNAME to the provider's TXT. The raw record is printed under each card so you can compare it with what the provider gave you. Results are cached for about a minute, so re-check after a short wait if you have just changed DNS.
Reading the key card
Key type comes from k= and defaults to RSA when absent. ed25519 keys are recognized and measured as 256 bits when the raw key is 32 bytes long. Key length is the RSA modulus size decoded from the SPKI structure in p=, with a fallback for the older bare RSAPublicKey form. Testing mode reflects t=y, and Hash algorithms shows h= or any (sha256) when the tag is absent.
The findings explain the pill. A version tag that is not DKIM1 is a warning. A record with no p= at all is a failure, because there is nothing to verify against. An Ed25519 key passes with a note to publish an RSA key alongside it, since not every receiver verifies Ed25519 yet.
Fixing what it finds
No key for a common selector: your provider uses a custom name. Send yourself a message, open the raw headers and read s= from DKIM-Signature, then check that one selector. No key at a specific selector: the record is at the wrong name (a common slip is adding ._domainkey twice), the DNS change has not propagated, or the provider's CNAME target is wrong.
Weak or short key: generate a 2048-bit key in the provider's console, or with the DKIM Generator for a server you run, publish it under a new selector, switch signing to it, and empty the old p= after a few days. Unreadable key: re-copy p= from the source. Long keys split across TXT strings sometimes lose characters in a DNS editor.
- Selector not found: read s= from a real DKIM-Signature header.
- 1024-bit key: rotate to 2048 under a new selector.
- t=y still set: remove it once mail verifies.
- p= empty: expected after rotation. Stop signing with that selector.
What a DNS check cannot verify
The checker proves a key is published and well formed. It cannot prove your mail is signed with it, that the signature survives your mail flow, or that it aligns with the From domain for DMARC. For one message, paste its headers into the Email Header Analyzer to read the Authentication-Results. For all your senders, read the DKIM column in the DMARC Report Analyzer.
Probing uses public resolvers with a short timeout, and the query names are mirrored into the page URL as ?domain= and ?selector= so a result can be shared. Nothing is stored.