What is DKIM?
DomainKeys Identified Mail (DKIM) is an email authentication protocol that uses cryptographic signatures to verify that an email was sent by an authorized server and hasn't been tampered with in transit.
What is DKIM?
DKIM (DomainKeys Identified Mail) adds a digital signature to every outgoing email, proving two things: the email was sent by a server authorized by the domain owner, and the message content hasn't been altered since it was sent.
It works using public-key cryptography. The sending server signs outgoing emails with a private key, and publishes the corresponding public key in a DNS TXT record. Receiving servers use this public key to verify the signature.
DKIM is defined in RFC 6376 and is one of three pillars of email authentication, alongside SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting and Conformance).
Why DKIM matters
Proves email authenticity
DKIM cryptographically proves that an email was actually sent by the claimed domain, not by an impersonator. Unlike SPF, this verification survives email forwarding.
Detects tampering
If anyone modifies the email body or signed headers in transit, the DKIM signature becomes invalid. Receivers know the message was altered.
Improves deliverability
Major email providers like Google and Microsoft treat DKIM-signed emails more favorably. Unsigned emails are more likely to land in spam.
Foundation for DMARC
DKIM is one of two authentication mechanisms DMARC relies on. DMARC checks that the DKIM signing domain aligns with the visible "From:" domain.
How DKIM works
Here's what happens when a DKIM-signed email is sent and received:
Domain publishes a public key
The domain owner generates a key pair and publishes the public key as a DNS TXT record at selector._domainkey.example.com.
Sending server signs the email
When an email is sent, the server uses the private key to create a cryptographic hash of the message headers and body. This signature is added as a DKIM-Signature header.
Receiving server looks up the public key
The receiver reads the d= (domain) and s= (selector) tags from the DKIM-Signature header, then queries DNS for the public key at selector._domainkey.domain.com.
Signature is verified
The receiving server uses the public key to verify the signature. If the signature matches, the email passes DKIM. If not, the email fails DKIM verification.
Selectors explained
A DKIM selector is a label that identifies which public key to use for verification. It allows a domain to have multiple DKIM keys active at the same time, each used for different purposes or during key rotation.
The selector is specified in the DKIM-Signature header (s= tag) and is used to
construct the DNS lookup: selector._domainkey.example.com.
Why multiple selectors?
Domains commonly use multiple selectors for several reasons:
Different services
Google Workspace, Microsoft 365, and third-party services each get their own selector and key pair.
Key rotation
When rotating keys, the new key gets a new selector. The old selector stays active briefly for emails still in transit.
Common selector names by provider
| Provider | Selector(s) | DNS record type |
|---|---|---|
| Google Workspace | google |
TXT |
| Microsoft 365 | selector1, selector2 |
CNAME |
| Amazon SES | Three unique selectors (auto-generated) | CNAME |
| Mimecast | mimecast20190104 (varies) |
TXT |
| SendGrid | s1, s2 |
CNAME |
| Mailchimp | k1 |
CNAME |
| Custom (OpenDKIM) | mail, default, or any label |
TXT |
DKIM DNS record format
A DKIM DNS record is a TXT record published at selector._domainkey.example.com.
It contains the public key and metadata about the key.
Example DKIM DNS record
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
| Tag | Required? | What it means | Example |
|---|---|---|---|
v |
Recommended | Version (must be DKIM1) |
v=DKIM1 |
p |
Required | Public key data (base64-encoded). An empty value means the key has been revoked. | p=MIGfMA0G... |
k |
Optional | Key type. Defaults to rsa if omitted. ed25519 is also supported. |
k=rsa |
t |
Optional | Flags. y = testing mode, s = strict domain alignment. |
t=y |
n |
Optional | Notes for humans. Not interpreted by software. | n=DKIM key for marketing |
"v=DKIM1; k=rsa; p=MIGfMA0GCS..." "qGSIb3DQEBAQUAA4GN...".
Most DNS providers handle this automatically.
DKIM-Signature header
When a sending server signs an email, it adds a DKIM-Signature header containing
the signature and metadata needed for verification.
Example DKIM-Signature header
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...| Tag | What it means |
|---|---|
v |
Signature version (always 1) |
a |
Algorithm used (typically rsa-sha256) |
d |
Signing domain (must align with "From:" for DMARC) |
s |
Selector — used to look up the public key in DNS |
h |
List of headers included in the signature |
bh |
Hash of the email body |
b |
The actual cryptographic signature (base64) |
c |
Canonicalization method (e.g., relaxed/relaxed). Controls how whitespace and header formatting are normalized before signing. |
Setup for common providers
Each email service uses its own DKIM selectors and key format. Unlike SPF, you can have multiple DKIM records (one per selector) without conflict.
Google Workspace
Google Workspace uses a TXT record with selector google.
1. In the Google Admin console, go to Apps → Google Workspace → Gmail → Authenticate email.
2. Select your domain and click "Generate new record." Choose 2048-bit if your DNS provider supports it.
3. Add the TXT record to your DNS:
Host: google._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...4. Return to the Admin console and click "Start authentication."
Microsoft 365
Microsoft 365 uses two CNAME records that point to Microsoft's infrastructure for automatic key rotation.
Add these CNAME records to your DNS:
Host: selector1._domainkey
Type: CNAME
Value: selector1-yourdomain-com._domainkey.yourtenantname.onmicrosoft.com
Host: selector2._domainkey
Type: CNAME
Value: selector2-yourdomain-com._domainkey.yourtenantname.onmicrosoft.comThen enable DKIM signing in the Microsoft 365 Defender portal under Email authentication → DKIM.
Mimecast
Mimecast provides a DKIM key through the Administration console.
1. In Mimecast Admin, go to Administration → Gateway → Policies → DNS Authentication → DKIM.
2. Generate a DKIM key. Mimecast will provide the selector name and TXT record value.
Host: mimecast20190104._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSq...Custom mail servers (OpenDKIM)
For self-hosted mail servers running Postfix or similar, use OpenDKIM:
1. Install OpenDKIM and generate a key pair:
opendkim-genkey -s mail -d example.com -b 20482. This creates mail.private (private key) and mail.txt (DNS record). Add the contents of mail.txt to your DNS as a TXT record.
3. Configure OpenDKIM to sign outgoing mail and integrate it with Postfix as a milter (mail filter).
Common mistakes
Using weak keys (512 or 1024-bit)
512-bit RSA keys can be cracked in hours. 1024-bit keys are considered deprecated and vulnerable to well-funded attackers. Many providers now reject DKIM signatures made with keys shorter than 1024 bits.
Fix: Use 2048-bit RSA keys. If your DNS provider has a record length limit, split the key into multiple strings.
DNS record too long for a single TXT entry
2048-bit RSA keys produce base64 strings longer than the 255-character DNS TXT string limit. If your DNS provider doesn't automatically split the record, DKIM verification will fail.
Fix: Split the value into multiple quoted strings, each under 255 characters: "v=DKIM1; k=rsa; p=first-part..." "second-part...". Most DNS providers handle this for you.
Forgetting to enable DKIM signing
Publishing the DNS record is only half the job. If DKIM signing isn't enabled on the
sending server, no DKIM-Signature header is added to outgoing emails, and
the DNS record sits unused.
Fix: After adding DNS records, enable DKIM signing in your email provider's admin console or mail server configuration.
Leaving testing mode enabled
The t=y flag in the DNS record signals that DKIM is in testing mode. While this
won't cause failures, it tells receivers not to treat DKIM results differently — essentially
making DKIM informational only.
Fix: Remove the t=y flag from your DKIM DNS record once you've confirmed signing works correctly.
Never rotating keys
Using the same DKIM key indefinitely increases the risk of compromise. If a private key is leaked or an employee with access leaves, old keys remain valid forever unless revoked.
Fix: Rotate DKIM keys at least every 6–12 months. Use a new selector for the new key, then revoke the old one by setting p= (empty) in the old DNS record.
Best practices
Use 2048-bit RSA keys
2048-bit keys provide strong security and are supported by all modern email providers and DNS hosts. Avoid 1024-bit keys for new deployments.
Rotate keys regularly
Rotate DKIM keys every 6–12 months. Create the new key with a new selector, update signing, then revoke the old key by emptying its p= value.
Sign all outbound email
Ensure every service that sends email on behalf of your domain (marketing platforms, CRM, helpdesk, transactional email) has DKIM signing configured with its own selector.
Use relaxed canonicalization
Set canonicalization to relaxed/relaxed to handle minor whitespace changes that mail servers may introduce, reducing false failures.
Combine with SPF and DMARC
DKIM alone isn't enough. Use all three protocols together. DMARC ties them together by requiring alignment between the "From:" domain and the authenticated domain.
Keep private keys secure
Store private keys with restricted file permissions on your mail servers. Never share private keys via email, chat, or version control. If a key is compromised, revoke it immediately.
Check your domain's DKIM configuration
Domain Guarddog monitors your SPF, DKIM, and DMARC configuration and alerts you to issues.
Get Started Free