A label that lets one domain publish several keys. The record lives at selector._domainkey.yourdomain.com, so a selector of "google" means the key is at google._domainkey.yourdomain.com. Providers choose their own — Google uses google, Microsoft uses selector1 and selector2, Mailchimp uses k1.

Two common causes. Either the record was published on the wrong host — a very frequent mistake is adding the full selector._domainkey.example.com string in a DNS panel that already appends the domain, producing a doubled name — or you use a custom selector. Enter your selector in the custom field above and check again.

It still validates, but 2048-bit has been the recommended standard for years and some receivers now treat shorter keys with less trust. If your provider offers a rotation to 2048-bit, take it. Google Workspace defaults to 2048-bit on new keys.

Yes, without exception. Each sending domain is a separate identity and needs its own key published in its own DNS. This is the single most common gap I find when auditing large sending fleets, and it is invisible until you look for it.

Three ways. Use the box above, which reads your MX records, works out who hosts your mail and tries that provider's selectors first. Open a message you have sent, view the raw source and read the s= value in the DKIM-Signature header. Or check the provider's admin console, where the selector is shown alongside the DNS entries it asks you to publish. There is no way to enumerate selectors from DNS alone — they have to be guessed or read from a signed message.

Query selector._domainkey.yourdomain.com as a TXT record — for example dig +short TXT google._domainkey.example.com on macOS and Linux, or nslookup -type=TXT google._domainkey.example.com on Windows. Microsoft 365 publishes CNAMEs rather than TXT records, so the query follows the CNAME to the tenant before returning the key.

A long TXT record along the lines of v=DKIM1; k=rsa; p=MIIBIjANBgkqh…, where p= holds the base64 public key and makes up nearly all of the length. On Microsoft 365 you will see a CNAME pointing into onmicrosoft.com instead, with the actual key held inside the tenant.

If the record resolves, the usual causes are signing never being switched on at the provider, the message body being modified in transit by a disclaimer appender or mailing list, an empty p= tag revoking the key, a key truncated by the DNS panel, or t=y testing mode left in place. If DKIM itself passes but DMARC does not, the issue is alignment — the signing domain in d= is not your From domain.

Yes, and unlike SPF this is normal and correct. Each selector is a separate record, so every provider that signs for you publishes its own without conflict — Google Workspace and a marketing platform can sign the same domain quite happily. Duplicates only cause a problem when two records share one selector.

2048-bit where the provider offers it. 1024 still verifies everywhere and is not currently treated as a failure, but it is the weaker option and there is no cost to the stronger one beyond the DNS record being split across strings. Google Workspace defaults to 1024 and has to be switched to 2048 manually, which is why so many domains sit on the shorter key.

Annually is a reasonable cadence for most senders, and some providers rotate automatically. The mechanism is to publish a new selector, switch signing to it, then remove the old record once no mail in flight is still signed with it — rotation is additive, so nothing breaks mid-change. For a cold email fleet this is low priority next to making sure every domain is signing at all.

Yes. DKIM keys are published per domain and are not inherited, so each sending domain in a fleet needs its own selector and key published in its own zone. This is the check most often skipped at scale, because mail flows perfectly without it and nothing bounces — the failure only surfaces when a message is forwarded and SPF breaks with no DKIM signature to fall back on.