A DKIM key record is a TXT record at <selector>._domainkey.<domain>. It is a short tag list, and three of its tags do something more than carry the key.
The shape of one
v=DKIM1;k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAtG/KAL73Y8YL0OaDHYuN2F1FMP6fUbCeQ5hO...
Every tag
| Tag | Meaning | In practice |
|---|---|---|
v= | Version | Always DKIM1. Optional, but if present it must come first. |
k= | Key type | rsa or ed25519. Defaults to rsa. |
p= | Public key | Base64 DER. Empty means revoked. |
t= | Flags | y = testing, s = strict i= matching. Colon-separated. |
h= | Permitted hashes | Restricts which algorithms may be used with this key. |
s= | Service type | email or *. Nobody sets it. |
n= | Notes | Free text, for humans. Verifiers ignore it. |
The two flags that matter
t=y marks the key as being tested. Receivers are told to treat a signature made with it as though it were unsigned — so the signature verifies, and then counts for nothing. A key left in testing mode after go-live is a domain with DKIM configured, working, and entirely without effect. It is a genuinely common and genuinely invisible failure.
t=s requires the i= identity in the signature to be the exact domain in d=, not a subdomain of it. SendGrid sets it on its customer keys:
s1.domainkey.u51742174.wl175.sendgrid.net. "k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyn3fMCVpb7ry..."
Two things are visible in that answer beyond the flag. The record is reached through a CNAME — the domain does not hold this key itself — and it has no v=DKIM1 at all. Omitting v= is legal and widespread; a verifier that rejected it would fail on a large slice of real mail.
Query the selector, not the domain
dig TXT example.com will never show you a DKIM key. The record lives at <selector>._domainkey.example.com, and you have to know the selector to ask for it — which is the subject of the selectors module.
Long records and TXT strings
A 2048-bit key exceeds the 255-octet limit on a single TXT character-string, so the record is published as several strings that the resolver concatenates with nothing between them. RFC 6376 §3.6.2.2 requires exactly that. The quoting is a DNS detail, not part of the key — a space accidentally introduced between the strings breaks the key, which is why hand-editing a long record in a provider UI is worth double-checking with a query afterwards.