DKIM (DomainKeys Identified Mail) uses public-key cryptography to sign outgoing emails so that receiving servers can verify two things: the message was not altered in transit, and the email was authorized by the domain owner. Every major mailbox provider, including Google, Yahoo, and Microsoft, checks DKIM signatures when deciding whether to deliver, spam-folder, or reject incoming mail.
This guide covers the full DKIM setup process: how the cryptographic signing works, what DNS records you need, how to configure DKIM for your specific email provider, and how to avoid the mistakes that cause DKIM verification failures.
Key Takeaway
- DKIM uses a private/public key pair. Your mail server signs messages with the private key; the public key is published in DNS for receivers to verify
- 2048-bit RSA keys are the standard. All major providers default to 2048-bit (NIST recommendation since 2013)
- Survives forwarding. Unlike SPF (which checks the sending server's IP), DKIM signatures travel with the message and remain valid after forwarding
- Selectors let you publish multiple DKIM keys for the same domain, enabling key rotation and multi-provider setups
- Verify your record now: DKIM Record Checker
What DKIM does
DKIM (DomainKeys Identified Mail)
RFC 6376 · Cryptographic signature · Verifies message integrity and sender authorizationWhen your mail server sends an email, it generates a hash of the message body and selected headers, then signs that hash with a private RSA key. The resulting signature is attached as a DKIM-Signature header. The receiving server extracts the signing domain (d=) and selector (s=) from that header, queries DNS for the public key at selector._domainkey.domain, and uses it to verify the signature. If the computed hash matches, DKIM passes.
DKIM answers two questions: "Was this email actually sent by the claimed domain?" and "Has the message content been modified since it was signed?" SPF only answers the first question (and only for the envelope sender, not the visible From: header). DKIM covers both, and it signs the From: header directly, making it the foundation for DMARC alignment.
For a broader overview of how SPF, DKIM, and DMARC work together as a system, see our email authentication explained guide.
How DKIM signing and verification works
The DKIM process involves five steps, split between the sending server (signing) and the receiving server (verification).
Signing (sender side)
- Hash the body. The sending mail transfer agent (MTA) computes a SHA-256 hash of the canonicalized message body. The result is stored in the
bh=(body hash) tag of the DKIM-Signature header. - Canonicalize and combine headers. The MTA selects specific headers to sign (listed in the
h=tag), applies canonicalization rules to normalize whitespace and casing, and combines them with the body hash into a single data block. - Sign with the private key. The MTA signs the combined data block using the domain's private RSA (or Ed25519) key. The result is a Base64-encoded signature stored in the
b=tag. - Attach the DKIM-Signature header. The complete signature, including all metadata tags (
v=,a=,d=,s=,c=,h=,bh=,b=), is prepended to the message as a new header before transmission.
Verification (receiver side)
- Query DNS for the public key. The receiving server reads the
d=(domain) ands=(selector) tags from the DKIM-Signature header. It performs a TXT lookup ons=._domainkey.d=(for example,google._domainkey.example.com) and retrieves the public key from thep=tag in the DNS record. - Recompute and compare. The receiver independently hashes the message body, canonicalizes the signed headers, and uses the public key to decrypt the signature. If the decrypted hash matches the recomputed hash, DKIM passes. If anything was modified in transit, the hashes will not match.
DKIM DNS record syntax
A DKIM public key is published as a DNS TXT record at a specific location determined by the selector and domain:
selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
The record name follows the pattern selector._domainkey.yourdomain.com. The _domainkey label is fixed by the DKIM specification. The selector is chosen by you (or your email provider) and can be any alphanumeric string.
DKIM record tags
| Tag | Required | Description | Example Value |
|---|---|---|---|
v= |
Yes | Version. Must be DKIM1. |
v=DKIM1 |
k= |
Optional | Key type. Defaults to rsa if omitted. Can also be ed25519. |
k=rsa |
p= |
Yes | Public key data (Base64 encoded). An empty p= value means the key has been revoked. |
p=MIIBIjANBgkq... |
t= |
Optional | Flags. t=y indicates testing mode (receivers should treat DKIM failures leniently). t=s requires exact domain match (no subdomains). |
t=y |
Example full record:
google._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2a..."
DKIM-Signature header fields
When your mail server signs a message, it attaches a DKIM-Signature header containing all the metadata a receiving server needs to verify the signature. Here is what each field means:
| Tag | Name | Description |
|---|---|---|
v= |
Version | Always 1 for the current DKIM specification. |
a= |
Algorithm | Signing algorithm. Typically rsa-sha256. Some newer implementations use ed25519-sha256. |
d= |
Domain | The signing domain. Must align with the From: domain for DMARC to pass. |
s= |
Selector | Identifies which public key to retrieve from DNS. Combined with d= to form the lookup: s=._domainkey.d=. |
c= |
Canonicalization | Format: header/body. Values are simple or relaxed. Example: c=relaxed/relaxed. |
h= |
Signed headers | Colon-separated list of headers included in the signature. Typically includes from:to:subject:date:message-id. |
bh= |
Body hash | Base64-encoded SHA-256 hash of the canonicalized message body. |
b= |
Signature | Base64-encoded cryptographic signature of the headers and body hash. |
Example DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; c=relaxed/relaxed; h=from:to:subject:date:message-id; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
You can inspect the DKIM-Signature header of any email using our Email Header Analyzer. For a broader introduction to reading email headers, see our guide to email headers.
DKIM selectors
A selector is the label that tells the receiving server which public key to look up in DNS. It appears in the s= tag of the DKIM-Signature header. The DNS lookup combines the selector with the fixed _domainkey label and the signing domain: selector._domainkey.example.com.
You can have multiple selectors on the same domain. This is common and necessary in several scenarios: using different email providers (each with its own key pair), rotating keys (old and new selectors active simultaneously during the transition), or separating marketing email from transactional email.
Common selectors by provider
| Provider | Default Selector(s) | Example DNS Lookup |
|---|---|---|
| Google Workspace | google |
google._domainkey.example.com |
| Microsoft 365 | selector1, selector2 |
selector1._domainkey.example.com |
| AWS SES | Auto-generated (3 selectors) | abcdef._domainkey.example.com |
| SendGrid | s1, s2 |
s1._domainkey.example.com |
| Mailchimp | k1, k2, k3 |
k1._domainkey.example.com |
| Postmark | Auto-generated | Varies per account |
How to find your selector: Open the full headers of an email you sent (in Gmail, click the three-dot menu and select "Show original"). Search for DKIM-Signature and look at the s= tag. That value is your selector. You can also query DNS directly: dig TXT selector._domainkey.yourdomain.com.
DKIM key lengths
The key length determines how resistant your DKIM signature is to brute-force attacks. Longer keys are harder to crack but produce larger DNS records.
| Key Length | Status | Notes |
|---|---|---|
| 512-bit | Deprecated | Crackable with commodity hardware. Yahoo and other providers reject 512-bit signatures. Do not use. |
| 1024-bit | Minimum acceptable | Still passes at most receivers. Considered weak by NIST standards since 2013. Acceptable only as a temporary measure during migration. |
| 2048-bit | Recommended standard | NIST-recommended minimum for RSA. Default for Google Workspace, Microsoft 365, AWS SES, and all major providers. Use this. |
| 4096-bit | Maximum practical | Stronger security but the DNS TXT record exceeds typical UDP response limits (512 bytes). Can cause resolution failures with some resolvers that do not fall back to TCP. |
2048-bit keys and DNS string limits
A 2048-bit RSA public key encodes to approximately 400 Base64 characters. DNS TXT records are limited to 255 characters per string. For 2048-bit keys, the p= value must be split across multiple strings within a single TXT record (for example, "v=DKIM1; k=rsa; p=MIIBIjAN..." "BgkqhkiG9w..."). Most DNS providers handle this splitting automatically, but some require you to do it manually. If your DKIM record fails validation, check for splitting errors first.
Canonicalization: relaxed vs. simple
Canonicalization defines how the signing and verifying servers normalize the message before hashing. This matters because intermediary mail servers sometimes make minor changes to messages (adjusting whitespace, changing header casing, adding line breaks). The canonicalization setting determines whether those changes break the signature.
The c= tag in the DKIM-Signature uses the format header-algorithm/body-algorithm. Each can be simple or relaxed.
| Mode | Headers | Body |
|---|---|---|
simple |
No modifications allowed. Headers must match exactly as signed, including whitespace and casing. | Trailing empty lines are ignored. Everything else must match byte-for-byte. |
relaxed |
Header names are lowercased. Consecutive whitespace is collapsed to a single space. Trailing whitespace is removed. | Consecutive whitespace is collapsed. Trailing whitespace on lines is removed. Trailing empty lines are ignored. |
Recommendation: Use relaxed/relaxed for production. Intermediary servers (mailing list processors, security gateways, virus scanners) commonly adjust whitespace. The simple mode is too strict for real-world email delivery and will produce false verification failures. All major email providers use relaxed/relaxed by default.
Step-by-step: setting up DKIM
Step 1: Generate DKIM keys (or enable via your provider)
If you use a hosted email provider (Google Workspace, Microsoft 365, AWS SES), the provider generates the key pair for you. You just need to enable DKIM in the admin console and copy the public key or CNAME record they provide.
If you run your own mail server (Postfix, Exim, OpenDKIM), generate a 2048-bit RSA key pair using openssl:
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem
Store the private key securely on your mail server. The public key goes into DNS.
Step 2: Publish the public key in DNS
Log in to your DNS provider (Cloudflare, GoDaddy, Namecheap, Route 53, etc.). Create a TXT record (or CNAME, depending on your email provider) with the name set to selector._domainkey (for example, google._domainkey for Google Workspace). Set the value to the public key string provided by your email service or extracted from your generated key file.
For hosted providers that use CNAME records (Microsoft 365, AWS SES, SendGrid), create CNAME records pointing to the provider's key servers instead of pasting the key directly.
Step 3: Enable DKIM signing in your email provider
After the DNS record propagates (typically a few minutes to an hour), go to your email provider's admin console and enable DKIM signing. For Google Workspace, this is in Admin Console > Apps > Google Workspace > Gmail > Authenticate email. For Microsoft 365, navigate to the Microsoft Defender portal > Email & collaboration > Policies > Threat policies > Email authentication settings > DKIM.
The provider will attempt to verify the DNS record before activating signing. If verification fails, double-check the record name and value for typos.
Step 4: Verify with a test email
Send a test email to a Gmail or Outlook account. Open the full headers (in Gmail: three-dot menu, "Show original") and confirm two things:
1. A DKIM-Signature header is present with your domain in the d= tag.
2. The Authentication-Results header shows dkim=pass.
You can also use our DKIM Record Checker to verify that your DNS record is correctly published and parseable.
Provider-specific DKIM setup
Each email provider has its own DKIM implementation. The table below summarizes the record type, default selectors, key length, and any provider-specific details.
| Provider | DNS Record Type | Default Selector(s) | Key Length | Notes |
|---|---|---|---|---|
| Google Workspace | TXT | google |
2048-bit | Generate in Admin Console > Gmail > Authenticate email. Prefix can be customized. |
| Microsoft 365 | CNAME | selector1, selector2 |
2048-bit | Two CNAME records required. Points to selector1-domain._domainkey.tenant.onmicrosoft.com. Microsoft manages key rotation. |
| AWS SES | CNAME (x3) | Auto-generated | 2048-bit | Three CNAME records. SES uses Easy DKIM with automatic key rotation. Records point to *.dkim.amazonses.com. |
| SendGrid | CNAME | s1, s2 |
2048-bit | Two CNAME records. Points to s1.domainkey.u1234.wl.sendgrid.net. Automated key management. |
| Mailchimp | CNAME | k1, k2, k3 |
2048-bit | Up to three CNAME records for redundancy. Managed via the Mailchimp domain authentication settings. |
| Postmark | TXT | Auto-generated | 2048-bit | Unique selector per account. TXT record with full public key. Rotation handled manually. |
Important distinction: Providers using CNAME records (Microsoft 365, AWS SES, SendGrid, Mailchimp) manage key rotation on their end because the CNAME points to their infrastructure, where they can update the underlying key at any time. Providers using TXT records (Google Workspace, Postmark) require you to update the DNS record manually when rotating keys.
DKIM key rotation
Key rotation means replacing your DKIM key pair with a new one on a regular schedule. If a private key is compromised, an attacker can sign emails that pass DKIM verification, making phishing messages from your domain appear legitimate. Regular rotation limits the window of exposure.
Recommended rotation frequency
- 2048-bit keys: Every 3 to 6 months. This provides a reasonable balance between security and operational overhead.
- 1024-bit keys: Every 1 to 3 months, or better yet, upgrade to 2048-bit.
- Automated providers (AWS SES, Microsoft 365): These handle rotation automatically. No action needed unless you are using custom selectors.
Best practices for key rotation
- Use dual selectors. Generate the new key pair under a new selector name. Publish the new public key in DNS while keeping the old one active. Update your mail server to sign with the new key. After a drain period (48 to 72 hours for in-transit messages to be delivered and verified), remove the old DNS record.
- Never delete the old key immediately. Emails already in transit were signed with the old key. If you remove the DNS record before those messages are delivered, they will fail DKIM verification.
- Test before switching. Verify the new DNS record with a DKIM Record Checker before configuring your mail server to use the new key.
DKIM and email forwarding
DKIM's biggest practical advantage over SPF is that it survives email forwarding. SPF checks the sending server's IP address against the authorized list. When a message is forwarded, the forwarding server's IP replaces the original, and SPF fails because the forwarder is not in your SPF record.
DKIM works differently. The signature is embedded in the message headers and travels with the email regardless of which server relays it. The receiving server verifies the signature against the public key in DNS, not against any IP address. As long as the message content has not been altered, DKIM passes.
The exception: mailing lists and content modification. Some mailing lists (Google Groups, Mailman, LISTSERV) add footers, prepend subject line tags like [list-name], or rewrite URLs for tracking. Any change to the message body invalidates the DKIM body hash, causing verification to fail. Some lists also modify headers that were included in the signature. This is why mailing list servers often re-sign messages with their own DKIM key.
With DMARC configured, a passing DKIM check (aligned with the From: domain) is sufficient for DMARC to pass, even if SPF fails due to forwarding. This is why configuring both SPF and DKIM is essential: they cover each other's weaknesses.
Common DKIM mistakes (and how to fix them)
1. Wrong selector in the DNS record
The DNS record name must exactly match the selector your mail server uses. If your provider uses google as the selector but you publish the key under dkim, verification will fail because the receiver looks up the wrong DNS name. Always confirm the exact selector value before creating the record.
2. Wrong record type (TXT vs. CNAME)
Microsoft 365 requires CNAME records, not TXT. If you paste Microsoft's DKIM key as a TXT record instead of creating a CNAME, DKIM will not work. Check your provider's documentation for the correct record type.
3. Key too short
Keys shorter than 1024-bit are rejected by Yahoo and may be flagged by other providers. If your DKIM check fails specifically at Yahoo, verify your key length. Upgrade to 2048-bit.
4. DNS string splitting errors for 2048-bit keys
A 2048-bit public key exceeds the 255-character DNS string limit. The key value must be split into multiple quoted strings within a single TXT record. Some DNS management interfaces handle this automatically; others require manual splitting. If your record looks correct but DKIM fails, check whether the key was truncated at 255 characters. Use our DKIM Record Checker to verify the published key is complete.
5. Forgetting to enable signing after DNS setup
Publishing the public key in DNS is only half the setup. You must also enable DKIM signing in your email provider's admin console. Without this step, your mail server sends unsigned messages, and the DNS record sits unused. This is especially common with Google Workspace, where DKIM is not enabled by default even though the option exists.
6. Body modification by intermediaries
Security appliances, mailing lists, and email gateways that modify message bodies (appending disclaimers, rewriting URLs, adding tracking pixels) will break the DKIM body hash. If DKIM is failing for messages that pass through an intermediary, check whether that system modifies message content. Configure it to leave the body intact, or accept that DKIM will fail for those messages and rely on SPF for those flows.
How to verify your DKIM setup
- Check the DNS record: Use our DKIM Record Checker to verify that your public key is published, correctly formatted, and the key length meets the 2048-bit recommendation.
- Run a full domain audit: The Domain Email Health Score checks DKIM alongside SPF, DMARC, blacklists, and overall sending reputation in a single report.
- Inspect actual email headers: Send a test email and paste the full headers into our Email Header Analyzer. Confirm that the Authentication-Results header shows
dkim=passand that thed=domain aligns with your From: address. - Check alignment for DMARC: DMARC requires either SPF or DKIM to pass with domain alignment. Verify that your DKIM
d=value matches your From: domain (exact match for strict alignment, or same organizational domain for relaxed alignment). Use our DMARC Record Generator to configure your DMARC policy.
If your emails are still landing in spam despite passing DKIM, the problem may be elsewhere in your authentication chain, your sender reputation, or your content. For a complete reference of email terminology, see the email glossary. For requirements specific to high-volume sending, read our bulk sender requirements guide.
Frequently asked questions
What is DKIM and how does it work?
DKIM (DomainKeys Identified Mail) is an email authentication protocol defined in RFC 6376. When you send an email, your mail server signs the message using a private cryptographic key. The signature is added as a DKIM-Signature header. The receiving server retrieves your public key from a DNS TXT record, then uses it to verify that the message content was not altered in transit and that the email was authorized by the domain owner.
What DKIM key length should I use?
Use 2048-bit RSA keys. NIST recommends 2048-bit as the minimum for RSA since 2013, and all major email providers (Google Workspace, Microsoft 365, AWS SES) now default to 2048-bit. Keys of 1024-bit still pass validation at most receivers, but they are considered weak by modern standards. Keys of 512-bit are deprecated and rejected by Yahoo and other providers. Keys of 4096-bit offer more security but exceed DNS UDP packet limits and may cause resolution failures.
How do I find my DKIM selector?
Open the full headers of an email sent from your domain (in Gmail, click the three-dot menu and select "Show original"). Look for the DKIM-Signature header and find the s= tag. The value of s= is your selector. Common selectors include google for Google Workspace, selector1 and selector2 for Microsoft 365, s1 and s2 for AWS SES and SendGrid, and k1 for Mailchimp. You can also query DNS directly: dig TXT selector._domainkey.yourdomain.com.
Does DKIM survive email forwarding?
Yes, in most cases. Unlike SPF, which checks the sending server's IP address (and fails when a forwarding server relays the message), DKIM verifies a cryptographic signature embedded in the email headers. That signature travels with the message regardless of which server delivers it. The one exception is when a forwarding system modifies the message body, such as a mailing list adding a footer or rewriting links. Body modifications invalidate the DKIM body hash and cause verification to fail.
