DKIM: A Complete Guide to Email Authentication

DKIM (DomainKeys Identified Mail) is an email authentication method that lets receiving mail servers verify a message actually came from your domain and was not altered in transit. It works by attaching a cryptographic signature to every outgoing email, which recipients check against a public key published in your DNS records.

If you send email from your own domain, whether through Gmail, Microsoft 365, a marketing platform, or your own mail server, DKIM is one of the three pillars of email authentication alongside SPF and DMARC. Without it, your messages are more likely to land in spam.

This guide covers everything from the basics to advanced multi-provider setups. Each section links to detailed guides if you need to go deeper.

How DKIM works

Every DKIM-signed email carries two things: a digital signature in the message header and a corresponding public key in DNS that the recipient uses to verify it.

The signing process

When your mail server sends a message, it performs these steps:

1. Canonicalization -- The server normalizes the message headers and body into a consistent format. This accounts for minor changes that mail servers sometimes make during transit, like adjusting whitespace or line endings. DKIM defines two canonicalization modes: "simple" (strict, no changes tolerated) and "relaxed" (allows minor formatting differences). Most configurations use relaxed for both headers and body.

2. Header selection -- The server decides which headers to include in the signature. The From header is always signed (it is required by the spec). Most implementations also sign To, Subject, Date, Message-ID, and MIME-Version. Signing more headers provides stronger protection against tampering but also increases the chance of breakage if an intermediary modifies a signed header.

3. Hashing -- The server generates a cryptographic hash of the selected headers and the message body. The body hash is computed first and included in the signature header as the bh= tag. Then the full header hash (including the DKIM-Signature header itself, minus the b= value) is computed.

4. Signing -- The body and header hashes are encrypted using the domain's private key (RSA with SHA-256 is the standard algorithm). The result is a base64-encoded string that becomes the b= value in the DKIM-Signature header.

5. Header insertion -- The complete DKIM-Signature header is prepended to the message. It contains the signature value plus metadata: the signing domain (d=), the selector (s=), the algorithm (a=), the list of signed headers (h=), the body hash (bh=), and optionally an expiration timestamp (x=).

The verification process

When the receiving server gets a message with a DKIM-Signature header, it:

1. Extracts the selector and domain from the s= and d= tags in the signature header
2. Queries DNS for the public key at selector._domainkey.domain.com
3. Canonicalizes the received message using the same method specified in the c= tag
4. Computes its own hash of the headers and body
5. Decrypts the signature using the public key to recover the original hash
6. Compares the two hashes. If they match, the message passes DKIM verification. If they differ, something changed after signing -- either the message was tampered with, the wrong key was used, or an intermediary modified a signed header or the body.

The result appears in the Authentication-Results header as dkim=pass, dkim=fail, or dkim=neutral. See How DKIM Works for the full cryptographic flow and DKIM Signatures Explained for a detailed breakdown of every tag in the signature header.

Key concepts

• Key pairs -- A private key (kept secret on your mail server) and a public key (published in DNS). The private key must never be exposed. If it is compromised, anyone can forge DKIM signatures for your domain.
• Selectors -- A label that tells the receiving server which public key to look up. You can have multiple selectors for different services or key rotation. For example, Google Workspace uses google, Microsoft 365 uses selector1 and selector2, and SendGrid uses s1 and s2. See DKIM Selectors Explained.
• Alignment -- For DMARC to consider DKIM a pass, the domain in the DKIM signature's d= tag must match the domain in the From header. This match can be exact (strict alignment) or allow subdomains (relaxed alignment). See DKIM Alignment Explained.

What DKIM does not do

DKIM proves a message was signed by a specific domain and was not altered. It does not:

• Encrypt the message content (anyone can still read it in transit)
• Verify the sender's identity beyond the domain level
• Prevent a domain from sending spam (a spammer can set up valid DKIM for their own domain)
• Replace SPF or DMARC (each covers different attack vectors)

Setting up DKIM

The setup process follows the same pattern regardless of your email provider. The difference is whether you generate your own keys or your provider generates them for you.

The general process

For the full walkthrough, see the DKIM Setup Guide. For real-world DNS record formats across different providers, see DKIM Record Examples.

TXT vs CNAME records

Your email provider will tell you whether to add a TXT or CNAME record. The distinction matters:

• TXT records contain the public key directly in your DNS. You control the key and can rotate it yourself, but you are responsible for updating DNS when you do.
• CNAME records point to a hostname your provider controls. The provider can rotate keys without you touching DNS, but you depend on them to manage it correctly.

Neither is inherently better. Use whichever your provider requires. For the full breakdown, see DKIM TXT vs CNAME Records.

Handling long records

2048-bit keys produce TXT records over 255 characters, which exceeds the single-string limit in DNS per RFC 1035. Most DNS providers handle this automatically by splitting the value into multiple quoted strings that get concatenated during lookup. If yours does not, you may need to split manually or fall back to a 1024-bit key. See DKIM Record Too Long for provider-specific details.

DKIM for your email provider

Most email providers handle DKIM key generation and signing for you. Your job is to add the DNS records they give you and verify the setup. The exact steps vary by provider.

Email providers

The major email hosting services each have their own DKIM configuration process:

• Google Workspace -- generates keys in the Admin Console, uses google._domainkey selector
• Microsoft 365 -- enables DKIM in the Defender portal with CNAME records
• Zoho Mail -- provides TXT records through the Mail Admin panel
• Proton Mail -- generates CNAME-based DKIM records for custom domains
• Fastmail -- uses three CNAME records (fm1, fm2, fm3)
• Gmail -- for personal accounts and Workspace setup

See all email provider guides.

Marketing and CRM platforms

Marketing tools send email on your behalf using their own mail servers. Without domain authentication, those emails are signed with the platform's domain instead of yours. This hurts deliverability because receiving servers see a mismatch between the "From" address (your domain) and the signing domain (the platform's). Domain authentication fixes this by letting the platform sign with your domain.

• HubSpot, Salesforce, Constant Contact
• Kit (ConvertKit), ActiveCampaign, Brevo

See all marketing and CRM guides.

Transactional and API senders

Password resets, order confirmations, and automated notifications need reliable delivery. Recipients expect these emails, and if they land in spam, it creates support tickets and erodes trust. Transactional services provide DKIM records during their domain verification process.

• SendGrid, Mailgun, Amazon SES, Postmark

See all transactional email guides.

Support platforms

Support replies landing in spam means customers miss your responses to their tickets:

• Zendesk, Freshdesk, Mimecast

See all support platform guides.

Website and ecommerce

Store notifications and marketing emails from your website builder:

• Shopify, Squarespace, Wix

See all website and ecommerce guides.

Adding DKIM records to your DNS host

Once your email provider gives you DKIM records, you need to add them at your DNS host. The interface varies by registrar, but you are always adding a TXT or CNAME record with a specific name and value.

The most common mistake is the record name. It must be selector._domainkey (or selector._domainkey.yourdomain.com depending on whether your DNS provider auto-appends the domain). If the _domainkey part is missing or misspelled, receiving servers will not find your public key.

Common DNS hosts with step-by-step guides:

• Control panels: cPanel
• Registrars: GoDaddy, Namecheap, Porkbun, OVH, IONOS
• Hosting providers: Cloudflare, Hostinger, Bluehost, SiteGround, DigitalOcean
• Cloud DNS: Amazon Route 53

See all guides in the Setup & Configuration category.

Testing and verification

Before relying on DKIM in production, verify everything is working. A misconfigured DKIM setup can be worse than no DKIM at all if it causes DMARC failures.

Check DNS first

Verify your public key is published and reachable. Use command-line tools:

dig TXT selector._domainkey.yourdomain.com

You should see a response containing v=DKIM1; k=rsa; p=... with your public key. If you get NXDOMAIN or no TXT records, the record is missing or still propagating.

Send a test email

Send an email to a Gmail account and view the original message headers. Look for the Authentication-Results header:

Authentication-Results: mx.google.com;
    dkim=pass header.i=@yourdomain.com header.s=selector header.b=abc123

The dkim=pass confirms your DKIM setup is working. If you see dkim=fail, the headers will usually include a reason like body hash did not verify or key not found, which points you to the specific issue.

Check alignment

For DMARC purposes, verify the domain in the d= tag of your DKIM-Signature matches the domain in the From header. If you send from user@yourdomain.com but DKIM signs with d=sendgrid.net, DKIM passes but does not align -- and DMARC will not count it.

The testing flag

During initial setup, you can add t=y to your DKIM DNS record. This tells receiving servers the domain is testing DKIM, and they should not treat failures differently from unsigned mail. Remove t=y once you have confirmed everything works -- leaving it in production signals that your DKIM setup is not authoritative.

Test across providers

Do not stop at Gmail. Send test emails to Outlook, Yahoo, and any other major provider your recipients use. Each has its own DKIM verification implementation and edge cases. What passes on Gmail might fail on Outlook if there is a subtle canonicalization issue.

For a complete pre-launch checklist, see DKIM Testing Before Go-Live.

Troubleshooting DKIM failures

When DKIM verification fails, the Authentication-Results header shows dkim=fail, dkim=neutral, or dkim=temperror. The header usually includes a reason that tells you exactly what went wrong.

Common failure causes

• Record not found -- The receiving server could not find a DKIM public key in DNS. This usually means the selector name is wrong, _domainkey is missing from the record name, or DNS has not propagated yet. Double-check the exact selector your provider uses. See DKIM Record Not Found.

• Key mismatch -- The public key in DNS does not correspond to the private key that signed the message. This happens when you generate new keys but forget to update DNS, or when you copy the wrong key from your provider's dashboard.

• Body hash did not verify -- The message body was modified after signing. Mailing lists, security gateways, and email forwarding services sometimes alter message bodies (adding footers, rewriting URLs, or modifying HTML). The body hash computed by the receiver no longer matches the one in the signature. See DKIM Body Hash Errors.

• Signature not verified -- A signed header was modified in transit, the canonicalization method does not match what the receiver expects, or the signature has expired (the x= timestamp has passed). See DKIM Signature Not Verified.

• Record too long -- The DNS provider truncated or rejected the TXT record because it exceeded their character limit. The record looks valid in the dashboard but is incomplete when queried. See DKIM Record Too Long.

For a full list of error codes and fixes, see Common DKIM Errors or browse all troubleshooting guides.

DKIM with SPF and DMARC

DKIM is one of three email authentication standards. Each protects against a different type of attack, and they are designed to work together.

SPF (Sender Policy Framework)

SPF lets a domain publish a list of IP addresses authorized to send email on its behalf. When a message arrives, the receiving server checks whether the sending server's IP appears in the sender's SPF record. If it does, SPF passes.

SPF has a critical limitation: it checks the envelope sender (the MAIL FROM address used during SMTP), not the From header that the recipient sees. It also breaks when email is forwarded, because the forwarding server's IP is not in the original sender's SPF record.

DKIM's advantage

DKIM does not depend on IP addresses. It signs the message content itself. Because the signature travels with the message, DKIM survives forwarding -- as long as the forwarding server does not modify signed headers or the body. This makes DKIM especially important for mailing lists, forwarding rules, and any scenario where email passes through intermediary servers.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC builds on SPF and DKIM by adding two things: alignment requirements and a policy for handling failures.

Alignment means the domain checked by SPF or DKIM must match the domain in the From header. Without alignment, a spammer could pass SPF with their own domain in the envelope but forge your domain in the From header.

Policy tells receiving servers what to do when both SPF and DKIM fail to align: none (monitor only), quarantine (send to spam), or reject (bounce the message).

For DMARC to pass, at least one of the following must be true:

• SPF passes and the SPF domain aligns with the From domain
• DKIM passes and the DKIM signing domain aligns with the From domain

Since SPF breaks on forwarding, DKIM is often the only mechanism that keeps DMARC passing for forwarded mail. This is why DKIM is considered the more reliable of the two for DMARC alignment.

You need all three for strong email authentication. For detailed comparisons:

• DKIM vs SPF
• DKIM vs DMARC
• SPF vs DKIM vs DMARC
• DKIM vs S/MIME

Key management

DKIM keys are not set-and-forget. Without ongoing management, keys can become a security liability.

Key rotation

Rotate keys periodically -- every 6 to 12 months is a common cadence. Rotation limits exposure if a private key is compromised without your knowledge. The process:

1. Generate a new key pair with a new selector name (e.g., 202610 if the current selector is 202604)
2. Publish the new public key in DNS
3. Wait for DNS propagation
4. Update your mail server to sign with the new private key and selector
5. Keep the old public key in DNS for a transition period (at least 7 days) so messages still in transit can be verified
6. Remove the old public key from DNS

Using a new selector for each rotation ensures a seamless transition. Both the old and new keys can coexist in DNS because they have different selector names.

See DKIM Key Rotation for the full process and automation options.

Key length

2048-bit RSA is the current recommendation per RFC 8301. It provides strong security and is supported by all major email providers and DNS hosts. 1024-bit RSA still works and passes verification, but it is considered weak against well-funded attackers and is deprecated by industry guidance.

The trade-off is DNS record size. A 2048-bit public key produces a TXT record of about 420 characters, which exceeds the 255-byte single-string limit in DNS. Most providers handle this transparently, but some require manual string splitting. If your DNS host cannot handle long records, 1024-bit is an acceptable fallback. See 1024-bit vs 2048-bit DKIM Keys.

Multiple domains

Each domain that sends email needs its own DKIM key pair and DNS record. If you send from example.com and example.org, you need separate keys for each. You can reuse the same selector name across domains (e.g., s1._domainkey.example.com and s1._domainkey.example.org) because the DNS lookup includes the domain.

Subdomains are treated separately. If you send from notifications.example.com, the DKIM record goes under that subdomain, not the parent domain. See DKIM for Multiple Domains.

Multiple email providers

Most businesses use more than one email service -- a corporate email provider (Google Workspace, Microsoft 365), a marketing platform (HubSpot, Mailchimp), and a transactional service (SendGrid, Postmark). Each service needs its own DKIM selector and key pair.

This works because DKIM selectors are independent. google._domainkey.yourdomain.com and s1._domainkey.yourdomain.com coexist without conflict. Each service signs with its own private key and the corresponding public key lives at its own selector in your DNS.

The main challenge is tracking which selectors belong to which services, especially during key rotation. A simple spreadsheet or document listing each service, its selector, and the last rotation date is usually enough. See DKIM for Multiple ESPs.

See all guides in the Security & Best Practices category.

Advanced topics

For teams managing their own infrastructure or building custom integrations:

• DKIM for Developers -- key generation, header construction, testing, and debugging at the protocol level
• DKIM for Self-Hosted Servers -- OpenDKIM with Postfix, Mail-in-a-Box, iRedMail, and other self-hosted solutions
• DKIM for Multiple Senders -- managing keys across a complex email stack
• DKIM in Cyber Security -- how DKIM fits into broader email security strategy

Next steps

If you are setting up DKIM for the first time, start with the DKIM Setup Guide, then find your specific email provider guide. If you are troubleshooting an existing setup, check Common DKIM Errors.

References

• RFC 6376 -- DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301 -- Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7208 -- Sender Policy Framework (SPF)
• RFC 7489 -- Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 1035 -- Domain Names -- Implementation and Specification

DKIM Creator generates keys, builds DNS records, and gives you copy-paste instructions for your provider.