DomainKeys Identified Mail adds a cryptographic signature to every email you send. Here's how it protects your domain — and how to make sure it's set up correctly.
SPF tells a receiver which servers can send as your domain. But SPF can't prove that an email wasn't modified after leaving your mail server. Emails can pass through multiple servers on the way to a recipient — any one of them could theoretically alter the message.
DKIM solves this by attaching a digital signature to every outgoing email. This signature is mathematically tied to the content of the message. If anything changes in transit — a single character added, a link swapped — the signature will fail verification.
DKIM uses asymmetric cryptography — a public/private key pair:
Private key — stored securely on your mail server. Used to sign outgoing emails. Never shared.
Public key — published in your DNS as a TXT record. Used by anyone to verify the signature.
When you send an email, your mail server creates a hash of the message headers and body, then encrypts it with your private key. This encrypted hash is the DKIM signature, added to the email as a header. When the email arrives, the receiving server fetches your public key from DNS and uses it to decrypt and verify the signature.
DKIM is stored in DNS as a TXT record at a special subdomain:
SELECTOR._domainkey.YOURDOMAIN.COM
For example, a Google Workspace setup might look like:
google._domainkey.yourcompany.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."
Breaking it down:
v=DKIM1 — version tag, always present.
k=rsa — the key type. RSA is most common; Ed25519 is newer and more compact.
p=... — the public key itself, base64-encoded. This is what receivers use to verify your signature.
A selector is the subdomain prefix used to look up your DKIM public key in DNS. It allows you to have multiple active DKIM keys simultaneously — for example, one for your main mail platform and another for a marketing tool like Mailchimp.
When checking DKIM, you need to know the selector used by your email provider. Common examples:
Google Workspace: google
Microsoft 365: selector1 and selector2 (rotated automatically)
Mailchimp: k1
SendGrid: s1 and s2
You can find your selector in the DKIM signature header of any email you've sent — look for the s= tag.
RSA (2048-bit) is the standard and most compatible key type. All major email providers support it. Use a minimum of 2048-bit length — 1024-bit RSA is considered weak by modern standards.
Ed25519 is a newer elliptic-curve algorithm. It offers equivalent or better security with a much shorter key. However, not all receiving servers support it yet.
DKIM keys should be rotated periodically — typically every 6–12 months. This limits exposure if a private key were ever compromised. Microsoft 365 does this automatically. Google Workspace requires manual rotation.
When rotating: publish the new key in DNS, wait for propagation, then switch your mail server to sign with the new key. Keep the old key in DNS for a few days to allow delayed emails signed with it to still verify correctly.
DKIM not enabled — the most common finding. Your email provider has the tools to generate and publish the key; they just need to be activated.
Using a 1024-bit key — upgrade to 2048-bit. Most providers make this straightforward.
Key published but signing not enabled — the DNS record exists but the mail server isn't actually signing emails. Always send a test email and check the headers.
Forgetting third-party senders — tools like Mailchimp, Salesforce, or HubSpot send email on your behalf. Check whether they offer DKIM signing and enable it.
Not checking after DNS changes — always verify with a tool after publishing or rotating keys.
Use our free DKIM checker to look up any selector and domain. You'll get an instant result with recommendations for any issues found.
🔍 Check Your DKIM Record