DKIM
DKIM (DomainKeys Identified Mail) is the second pillar of email authentication, alongside SPF and DMARC. The sending mail server signs outgoing messages with a private key; the corresponding public key is published in DNS. Receivers verify the signature against the published key.
Where the key lives
DKIM keys are published as TXT records at <selector>._domainkey.example.com. Each mail provider has its own selector, so a domain can publish multiple DKIM keys for different senders (e.g., google._domainkey for Google Workspace, k1._domainkey for Mailchimp, s1._domainkey for SendGrid).
How to look it up
You need the selector. Most providers tell you what it is when you set up DKIM. To verify Google's DKIM for a domain that uses Google Workspace, look up the TXT record at google._domainkey.example.com. To check what selectors a domain uses without knowing in advance, you have to inspect a piece of mail you've received from them: the DKIM-Signature header in any mail tells you the s= selector.
Worked example: rotating a leaked key
Your dev team accidentally committed the DKIM private key to a public GitHub repo. You need to rotate without breaking mail. Process:
- Generate a new key pair at the provider (often this means creating a new selector — e.g.,
k2._domainkeyalongsidek1._domainkey). - Publish the new public key as a TXT record at the new selector.
- Switch the provider's signing config to use the new selector.
- Wait at least 24 hours so any in-flight messages signed with the old key still validate.
- Remove the old TXT record only after the wait window.
Removing the old record too soon means messages signed with the old key — which may still be sitting in receiver queues — fail DKIM and possibly DMARC. The 24-hour cushion costs nothing and saves you from second-order incidents.
Selector naming conventions
There's no standard. Common patterns: k1, s1, selector1, the date (202605), or the provider name. Microsoft 365 uses selector1 and selector2; Google uses google; Mailchimp uses k1 and k2; SendGrid uses s1 and s2. Pick something descriptive so you remember which provider it belongs to a year later.
Why DKIM is robust
Unlike SPF, DKIM survives mail forwarding. The signature is on the message body and headers, so as long as the forwarder doesn't modify those, the signature still validates. This is why DMARC requires DKIM or SPF to align: DKIM tends to be the one that holds up.
Verify on WhereIsDNS
Run the DKIM check with your selector. WhereIsDNS queries <selector>._domainkey.<domain> across 14 resolvers. If the v=DKIM1 record returns consistently with the same p= (public key) value, DKIM is published correctly.
Related: SPF · DMARC · TXT lookup.