DKIMDomainKeys Identified Mail
DKIM attaches a digital signature to outgoing email, generated with a private key only your mail platform holds. The receiving server looks up the matching public key in your DNS and checks the signature — proof the message really came from an authorized sender and wasn't altered in transit.
Unlike SPF, which authorizes servers by IP address, DKIM travels with the message itself, so it survives being forwarded through systems that would break an IP-based check. It's also invisible until you know exactly where to look: there's no single place in DNS that lists all of a domain's DKIM keys.
Selectors: DKIM's addressing scheme
A DKIM public key is published as a TXT record at <selector>._domainkey.yourdomain.com, defined by RFC 6376. The selector is an arbitrary label chosen by whoever signs the mail — Microsoft 365 typically uses selector1 and selector2, Google Workspace defaults to google, and most marketing and helpdesk platforms use their own vendor-specific selector. Because the selector name isn't standardized or discoverable from DNS alone, you can't enumerate a domain's DKIM keys without already knowing what to look for.
What the record contains
A DKIM TXT record looks like v=DKIM1; k=rsa; p=<base64 public key>. v is the version, k is the key type (almost always rsa), and p is the actual public key material. An empty p= value means the key has been revoked — mail signed with it should no longer verify, which is the correct way to retire a compromised or unused key.
Key strength and rotation
1024-bit RSA keys are now considered weak; 2048-bit is the current floor most guidance recommends. RFC 6376 describes safe rotation as publish-then-switch: add the new selector's key to DNS, start signing with it, confirm mail verifies cleanly, then revoke the old selector — never rotate a key in place, since in-flight mail signed with the old key would suddenly fail to verify.
How Trustliant handles this
Trustliant probes the well-known selectors used by Microsoft 365, Google Workspace, Mailchimp, SendGrid, HubSpot, Zendesk, and other major platforms today, mapping each discovered selector to the vendor that conventionally uses it. It flags 1024-bit keys and revoked-but-still-published records automatically. Discovering the long tail of selectors from DMARC aggregate report data — catching the ones nobody documented — and tracking key rotation age are next on the roadmap.
Questions we get about DKIM
- Can I have more than one DKIM selector active at once?
- Yes — this is normal and often necessary. Every platform that sends mail on your behalf (your email provider, CRM, help desk, marketing tool) typically signs with its own selector, so a healthy domain usually has several active DKIM records at once, one per sending service.
- Does DKIM alone stop spoofing?
- No. DKIM proves a message wasn't altered and was signed by whoever holds the private key — but without DMARC checking that the signing domain aligns with the visible From: address, a receiver has no instruction to reject mail that's signed by someone else entirely.
- How do I find my DKIM selector if I didn't set it up?
- Check your mail platform's admin console (Microsoft 365's Defender portal, Google Workspace's Admin console under Gmail > Authenticate email) — it will show the exact selector and record it expects you to publish. Guessing selector names is unreliable since they're not standardized.