Complete DKIM Guide

DomainKeys Identified Mail (DKIM) lets sending domains cryptographically sign email so receivers can verify that the message has not been modified in transit and that it came from an authorized sender. Unlike SPF, which checks the connecting IP, DKIM signs the message body and selected headers. Receivers fetch your public key from DNS, verify the signature, and treat verified mail as more trustworthy.

For founders: DKIM is one of the main signals mailbox providers use to decide inbox placement. Messages that pass DKIM are less likely to land in spam. For IT admins: DKIM requires publishing a public key under a selector in DNS. The sending system holds the private key and signs each message. When selectors are missing, keys are malformed, or the message changes after signing, verification fails. This guide covers record structure, selectors, alignment, and how to troubleshoot real-world DKIM failures. DKIM works with SPF and DMARC: SPF authorizes infrastructure, DKIM authenticates the message, and DMARC decides what to do when either fails or does not align with the visible sender.

What DKIM is

DKIM provides two things: integrity and domain authentication. Integrity means the signed content has not been altered. The receiver recomputes a hash of the message body and selected headers and compares it to the hash embedded in the signature. If they match, the message was not tampered with in transit.

Domain authentication means the signer used a private key that corresponds to a public key published in DNS for the signing domain. Only the holder of the private key could produce a valid signature. That proves the message originated from a system authorized by the domain owner. DKIM does not, by itself, say whether the message is spam or legitimate. It says the content was not modified and was signed by someone who controls the domain's DKIM keys. Receivers combine that with SPF, DMARC, reputation, and content analysis to make delivery decisions.

How DKIM signatures work

The flow: Sender composes the message → Signing system selects headers and body to sign → Computes a hash and signs it with the private key → Adds a DKIM-Signature header to the message → Message is sent. On receive: Receiver extracts the domain and selector from the DKIM-Signature header → Queries DNS for selector._domainkey.domain → Retrieves the public key → Verifies the signature with the public key and recomputes the hash from the received message. If both match, DKIM passes.

The DKIM-Signature header contains fields such as v=1 (version), a= (algorithm, e.g. rsa-sha256), d= (signing domain), s= (selector), h= (signed header list), bh= (body hash), and b= (signature value). The receiver uses d and s to locate the public key in DNS. See DKIM signature explained for header fields and verification in detail.

DKIM record structure

DKIM public keys are stored as DNS TXT records. The hostname is selector._domainkey.example.com. The value is a semicolon-separated list of tag-value pairs.

• v= — version; must be DKIM1
• k= — key type; typically rsa
• p= — the public key (base64-encoded)

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The p= value is the actual public key. Providers like Google, Microsoft, or SendGrid generate the key pair and give you the record to publish. Do not manually edit the key string; truncation or extra whitespace breaks verification. See DKIM record examples for provider-specific formats.

DKIM selectors

The selector is the first label in the DNS query. For selector1._domainkey.example.com, the selector is selector1. Selectors exist so a domain can publish multiple keys. Different senders—product mail, marketing, support—can use different selectors. Key rotation also depends on selectors: you publish a new key under a new selector, switch the signing system to use it, then retire the old selector once traffic has moved.

Providers assign selectors when they generate keys. Google Workspace might use google or default. Microsoft 365 uses values like selector1. The sender must use the same selector that appears in DNS. If the signing system uses marketing but DNS only has selector1, verification fails. See DKIM selector not found and DKIM selector explained for troubleshooting and rotation.

DKIM key length and security

RSA keys for DKIM are typically 1024 or 2048 bits. 1024-bit keys still work but are considered weak by modern standards. Most providers now recommend 2048-bit. Some receivers may treat 1024-bit keys with less trust or deprecate them over time.

Shorter keys are easier to brute-force. 2048-bit keys add a bit more CPU cost for signing and verification but are the safe default. If your provider offers a choice, use 2048. If you have legacy 1024-bit keys, plan a rotation to 2048. See DKIM key length too short for how to upgrade.

DKIM alignment

The d= domain in the DKIM-Signature header is the signing domain. The From header shows the visible sender. For DMARC, alignment means these domains match (relaxed or strict). Relaxed alignment allows organizational subdomains: mail.example.com aligns with example.com. Strict requires an exact match.

If your provider signs with a subdomain (e.g. dkim.mail.example.com) and the From shows example.com, relaxed alignment passes. Strict would fail. DMARC uses alignment to decide whether SPF or DKIM "count"—both must align with the From domain for DMARC pass. See DKIM alignment failed when the signing domain does not align.

DKIM verification process

Receivers verify DKIM by: 1) Finding the DKIM-Signature header, 2) Extracting d= and s=, 3) Querying DNS for the public key, 4) Recomputing the body hash from the received message, 5) Verifying the signature with the public key. If the key is missing, malformed, or the recomputed hash does not match the signed hash, verification fails.

Common failure causes: Body hash mismatch—the message changed after signing. Gateways that add footers, mailing lists that modify content, or forwarding that rewrites the body break the hash. See DKIM body hash mismatch. Missing selector—no DNS record exists for selector._domainkey.domain. Malformed key—truncation, extra characters, or wrong encoding. See Invalid DKIM key. Selector mismatch—the sender uses a different selector than the one published. See DKIM selector mismatch.

DKIM record examples

Google Workspace

Host: google._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=YOUR_GOOGLE_PUBLIC_KEY

Google provides the exact record in the Admin Console. Use the selector and key they give you.

Microsoft 365

Host: selector1._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=YOUR_MICROSOFT_PUBLIC_KEY

Microsoft uses CNAME records for DKIM in many configurations. Follow the exact instructions in the Exchange admin center.

SendGrid

Host: s1._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=YOUR_SENDGRID_PUBLIC_KEY

SendGrid, Mailgun, and similar ESPs generate keys in the dashboard. Create the authentication setup, copy the CNAME or TXT records they provide, and publish them. Wait for DNS propagation, then enable signing.

Common DKIM mistakes

• Missing selector. The sender is configured to use a selector, but no DNS record exists. Add the record at the hostname the provider specifies.
• Wrong DNS host. The record is at selector._domainkey.www.example.com instead of selector._domainkey.example.com. Use the root domain or the exact hostname the provider gives.
• Weak key length. 1024-bit keys are legacy. Rotate to 2048-bit when the provider supports it.
• Body hash mismatch. A gateway, footer tool, or forwarder modifies the message after signing. Route mail so signing happens after all modifications, or send from a system that does not alter the body.
• Signature added by wrong system. Multiple systems can add DKIM. If a relay signs with a different domain or selector than your primary sender, alignment can fail. Ensure the correct system signs for the From domain.

Troubleshooting DKIM failures

1. Run a live check. Use our domain checker to confirm your DKIM record is published and valid.
2. Verify the selector. Check that the sending system uses the same selector as the one in DNS. Inspect a received message's DKIM-Signature header for s= and d=.
3. Confirm DNS propagation. New or changed records can take up to 48 hours. Use dig or nslookup to query selector._domainkey.yourdomain.com from multiple locations.
4. Inspect the public key. Ensure it is not truncated, has no extra spaces, and matches exactly what the provider gave you.
5. Check for body modifications. If body hash fails, trace the path of the message. Identify any system that adds footers, disclaimers, or rewrites content after the signing MTA.
6. Review authentication results in received headers. Look for dkim=pass or dkim=fail in Authentication-Results. Some providers include a reason for failure.

Best practices

• Rotate keys periodically. Use a new selector for the new key, switch traffic, then retire the old selector after propagation.
• Document selectors. Keep a list of which selector each sending system uses. Avoid reusing selectors across different platforms.
• Monitor alignment. DMARC reports show DKIM pass/fail and alignment. Use them to catch configuration drift.
• Test after DNS changes. Publish the record, wait for propagation, send a test message, and verify dkim=pass in the received headers before assuming the setup is correct.
• Use 2048-bit keys. Prefer them over 1024-bit when your provider supports them.
• Ensure signing happens last. If a gateway adds content, either sign after the gateway or send through a path that does not modify the body.

Related DKIM deep dives

Go deeper on specific topics:

Return to the DKIM Hub for the full troubleshooting index.