What a DKIM record is
DKIM signs a message: the sending system hashes the headers and the body and signs the hash with a private key. The receiver fetches the matching public key from the DNS, where it is stored in a TXT record (RFC 8301 §1), and verifies the signature. The record lives at <selector>._domainkey.<domain> (RFC 6376 §3.6.2.1). The domain and the selector are both named in the DKIM-Signature header of the message, in the tags d= and s=.
v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=
The sample Ed25519 key record of RFC 8463 Appendix A.2, published there under the selector brisbane.
How to read it
v=DKIM1 is the version. It is recommended, not required; when present it must be the first tag and must be exactly DKIM1 (RFC 6376 §3.6.1).
k= is the key type: rsa, which is also the default when the tag is missing, or ed25519 (RFC 8463 §4.2).
p= is the public key in base64, and the one required tag. An empty p= means the key has been revoked.
t=y says the domain is testing DKIM, and verifiers must not treat its mail differently from unsigned mail. t=s forbids signing for subdomains.
h= lists the accepted hash algorithms, s= the service types, and n= is a note for administrators.
Key length
The checker decodes the key and measures it. For RSA the rule is in RFC 8301 §3.2: signers must use keys of at least 1024 bits and should use at least 2048; verifiers must handle keys from 1024 to 4096 bits and must not accept a signature made with a key shorter than 1024. An Ed25519 key is always 256 bits, 44 characters of base64, short enough for a single string in a TXT record (RFC 8463 §3).
Why you have to name the selector
Selectors exist so that a domain can publish several keys at once: one per sending service, or an old and a new key during a rotation (RFC 6376 §3.1). Nothing in the DNS lists them. A lookup tool can only try names, and a name that finds nothing proves nothing about the names it did not try.
The chips above offer ten names. Two sources stand behind three of them. Google Workspace's help states that "the default prefix selector is google" (Set up DKIM, read 2026-09-28). Microsoft's instructions for Microsoft 365 have the domain owner create two CNAME records with the host names selector1._domainkey and selector2._domainkey (Microsoft Learn, read 2026-09-28). The other seven — default, dkim, mail, k1, k2, s1, s2 — are names we chose to offer; there is no registry of selector names. The sure way to find yours is to open a message the domain sent and read s= in its DKIM-Signature header.
The common mistakes
- A key cut short. A 2048-bit RSA key does not fit in one 255-octet string. It has to be published as several strings, which verifiers join with nothing between them (RFC 6376 §3.6.2.2). A key truncated by a DNS panel shows up here as key data that cannot be read.
- An alias to nothing. A selector delegated by CNAME to a provider finds no key if the provider has removed it, or never created it.
- Testing mode left on. With
t=y a valid signature counts for nothing.
- Two records at one selector. The result is undefined (RFC 6376 §3.6.2.2).
- A key of 512 or 768 bits. Verifiers must treat its signatures as failed.
What this lookup does not tell you
A published key shows that mail could be verified, not that mail is signed. Whether a message carries a valid signature, and whether that signature's domain matches the From address, which is what DMARC asks, can only be read from the message itself.