What is a selector DNS record and how long should keys stay cached?

A selector DNS record is the TXT record where your DKIM public key lives. Every DKIM-signed email carries a selector name in the signature header (the s= field). When a receiving server wants to verify the signature, it looks up that selector at:

selector._domainkey.yourdomain.com

And That's where your public key is published. Match the selector name in the signature to the selector name in DNS, and verification works. Mismatch them and you get "key not found."

One domain can have multiple selector records, one per sending service. Google Workspace uses its own selector, your ESP uses its own, and they coexist without conflict.

How long should keys stay cached?

Like all DNS records, selector records have a TTL (time-to-live) that controls how long resolvers cache them before re-querying. Common values range from 300 seconds (5 minutes) to 86400 seconds (24 hours). Most registrars default to 3600 seconds (1 hour).

For a stable record that isn't changing, a higher TTL is fine. It reduces DNS query load and speeds up lookups for frequent senders. For key rotation, TTL matters a lot.

Before rotating: lower the TTL first

And if you're about to rotate DKIM keys, lower the TTL on your existing selector record to something short (300 to 600 seconds) a few hours before you make the switch. This way, when you publish the new key, receivers pick it up quickly instead of holding the old key for hours from their cache.

Skip this step and some receivers will verify signatures against a cached copy of your old public key for up to 24 hours after you've switched to a new private key. That means dkim=fail for those recipients until their cache expires.

After rotation is complete and stable, you can raise the TTL back up.

Our DKIM checker shows your current TTL alongside the selector record. If you're planning a rotation and want to walk through the timing, the SOS hotline is free.