DKIM DNS records and selectors explained

A DKIM public key is published as a DNS TXT record at a name built from two parts: a selector chosen by the signer, and the fixed label _domainkey under the signing domain. When a receiver verifies a signature declaring d=example.com and s=s2026a, it queries s2026a._domainkey.example.com and expects to find the key there. The selector scheme is what lets one domain operate many keys at once, which turns out to be the feature everything else depends on.

The record itself

Two optional tags appear occasionally: t=y marks the domain as in testing mode (receivers verify but treat failures leniently; remove it in production), and h= restricts acceptable hash algorithms. Everything else in the record is the key material. A 2048-bit RSA key produces a p= value longer than the 255-character limit of a single TXT string, so the value must be split into multiple quoted strings that resolvers concatenate, which is where DNS consoles most often mangle DKIM records.

Why selectors exist

Selectors decouple keys from the domain, and three practices depend on that. Rotation: a new key publishes under a new selector while the old one keeps verifying in-flight mail, the zero-downtime pattern detailed in the key management entry. Multi-vendor sending: the ESP signs under selector esp1, the transactional provider under tx1, corporate mail under google, all for the same d= domain, each vendor holding only its own private key. And incident containment: revoking one selector cuts off one signer without touching the others.

Selector names are arbitrary and visible to anyone reading headers, so a light convention helps operations: a vendor hint plus a date (esp-2026a, tx-2026a) tells the on-call engineer what a selector belongs to and roughly how old the key is, at the cost of nothing.

CNAME delegation to vendors

Most ESP setups do not publish the TXT record directly. Instead the vendor asks for CNAME records: s1._domainkey.example.com pointing at s1.dkim.espplatform.com, where the vendor hosts the actual key. The trade is real on both sides. The vendor can rotate keys without ever asking you for DNS changes again, which in practice means rotation actually happens. In exchange, your authentication resolves through infrastructure you do not operate, and a delegation left pointing at a cancelled vendor account is a dangling reference with your domain's trust attached.

The operating rule: delegation to actively used vendors is normal and fine, and every email-related CNAME gets audited quarterly, resolved end to end, with delegations for cancelled services deleted the day the contract ends. Remember two protocol constraints while auditing: no other record may coexist at a name carrying a CNAME, and the selector name must match exactly what the vendor signs with.

Checking a published key

1# Resolve the key as receivers do (follows CNAMEs)
2dig TXT s2026a._domainkey.example.com +short
3
4# Confirm the record parses and the key is well-formed
5# (any DKIM checker: MxToolbox, dmarcian, easydmarc)
6
7# Find which selectors a message used: read the s= tag
8# in its DKIM-Signature headers

There is no public index of a domain's selectors; verifiers only ever query the ones named in signatures. That means auditing your own selector inventory requires your own records: the DNS zone, vendor dashboards, and the s= tags visible in your delivered mail. Full verification workflow and failure diagnosis live in the testing and troubleshooting entry.