What is DKIM? The Complete Guide to DomainKeys Identified Mail

DKIM - DomainKeys Identified Mail - is the second pillar of modern email authentication. While SPF verifies that a message was sent from an authorized server, DKIM goes further: it cryptographically signs the message itself, proving that the content has not been tampered with and that the claimed sending domain actually authorized the message.

RFC 6376 defines DKIM as a method for associating a domain name with an email message, thereby permitting a person, role, or organization to claim some responsibility for the message. The signature survives email forwarding, which is a critical advantage over SPF.

Understanding DKIM is essential for anyone managing email infrastructure, because DKIM alignment is one of the two paths to passing DMARC authentication - and for forwarded mail, it is often the only path.

How DKIM Works: The Big Picture

DKIM operates on a simple cryptographic principle: the sending server signs the message with a private key, and the receiving server verifies the signature with a public key published in DNS.

The Signing Process (Outbound)

1. The sending mail server generates a hash of specific email headers and the message body
2. The server encrypts this hash using the domain’s DKIM private key
3. The server adds a DKIM-Signature header to the message containing the encrypted hash, the selector name, the signing domain, and metadata about which headers were signed
4. The message is transmitted to the receiving server

The Verification Process (Inbound)

1. The receiving server extracts the DKIM-Signature header from the message
2. It reads the d= (domain) and s= (selector) values from the signature
3. It performs a DNS lookup for <selector>._domainkey.<domain> to retrieve the public key
4. It uses the public key to decrypt the signature and recover the original hash
5. It independently hashes the same headers and body using the specified algorithm
6. If the two hashes match, the signature is valid - the message is authentic and unmodified

For a detailed technical walkthrough of this process, see How DKIM Works: A Comprehensive Guide to Email Authentication.

For the RFC-level details of the verification algorithm, see Inside RFC 6376: How DKIM Verification Actually Works.

The DKIM-Signature Header

A DKIM signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    c=relaxed/relaxed; q=dns/txt; t=1618884473;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...

Tag	Meaning
v=1	DKIM version (always 1)
a=rsa-sha256	Signing algorithm
d=example.com	Signing domain (used for DMARC alignment)
s=selector1	Selector - identifies which public key to use
c=relaxed/relaxed	Canonicalization method for header/body
q=dns/txt	Query method for the public key
t=1618884473	Timestamp of signing
h=from:to:subject:...	List of headers included in the signature
bh=...	Body hash
b=...	The signature itself

DKIM Keys: Public and Private

DKIM uses asymmetric cryptography. The domain owner generates a key pair:

• Private key - Stored securely on the sending mail server. Never shared or published. Used to sign outgoing messages.
• Public key - Published in DNS as a TXT record at <selector>._domainkey.<domain>. Used by receiving servers to verify signatures.

DNS Record Format

A DKIM DNS record looks like this:

selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

Tag	Meaning
v=DKIM1	Version
k=rsa	Key type (RSA is the standard; Ed25519 is emerging)
p=...	The public key, base64-encoded

You can look up any domain’s DKIM public key using the DKIM Lookup Tool.

Key Sizes

• 1024-bit RSA - The minimum recommended key size. Still widely used but considered weak by modern standards.
• 2048-bit RSA - The current recommended standard. Provides strong security but produces longer DNS records that may require TXT record splitting.
• Ed25519 - A newer, more efficient algorithm that produces shorter signatures and keys. Supported by a growing number of mail servers but not yet universal.

Detailed guide: Understanding DKIM’s Cryptographic Algorithms: RS256 vs RS512 and Emerging Trends

Selectors: Managing Multiple Keys

DKIM selectors allow a domain to publish multiple DKIM keys simultaneously. Each key is identified by a selector string, and the s= tag in the DKIM-Signature header tells the receiver which selector (and therefore which public key) to use for verification.

Selectors serve several purposes:

• Multiple sending services - Your primary mail server and each third-party service (SendGrid, Mailchimp, etc.) can each have their own DKIM key pair with a unique selector
• Key rotation - When rotating keys, you can publish the new key under a new selector while the old selector remains active during the transition period
• Departmental separation - Different teams or divisions can use different selectors for tracking and management purposes

Common selector naming conventions include s1, s2, google, sendgrid, k1, or date-based names like 202604.

Canonicalization: Handling Message Modifications

Email messages are frequently modified in transit - whitespace is added or removed, headers are rewritten, and line breaks may change. Canonicalization defines how the signing and verification processes normalize the message before hashing, so that minor modifications do not break the signature.

There are two canonicalization modes, applied independently to headers and body:

• simple - Almost no modification tolerance. Headers must match exactly (except for trailing whitespace). The body is normalized only for trailing empty lines. Use this when you control the entire delivery path and no intermediary will modify the message.
• relaxed - More tolerant. Header names are lowercased, whitespace is normalized, and multiple spaces are collapsed to one. In the body, trailing whitespace is removed from each line. Use this for most real-world deployments.

The c=relaxed/relaxed setting (relaxed for both headers and body) is the most common and recommended configuration.

DKIM Alignment

DKIM alignment is a DMARC concept that determines whether the domain in the DKIM signature (d= value) matches the domain in the visible From header. This is critical because DMARC requires at least one of SPF or DKIM to be both valid and aligned.

Relaxed Alignment

The organizational domains must match, but subdomains are allowed. For example:

• From: user@example.com with d=mail.example.com - Passes relaxed alignment (same organizational domain)
• From: user@example.com with d=example.com - Passes relaxed alignment

Strict Alignment

The domains must match exactly:

• From: user@example.com with d=example.com - Passes strict alignment
• From: user@example.com with d=mail.example.com - Fails strict alignment

Detailed guide: Mastering DKIM Alignment: Keys, Signatures, and Why Emails Fail Verification

DKIM Key Rotation

DKIM private keys should be rotated periodically to limit the damage if a key is compromised. The rotation process involves:

1. Generating a new key pair with a new selector
2. Publishing the new public key in DNS
3. Configuring the sending server to sign with the new private key
4. Waiting for DNS propagation and verifying signatures with the new key
5. Removing the old public key from DNS after a transition period

How often should you rotate? There is no universal standard, but common recommendations range from every 6 months to annually. High-security environments may rotate more frequently.

Detailed guide: When Should You Rotate Your DKIM Keys?

Why DKIM Fails

DKIM verification can fail for several reasons:

Message Modification in Transit

If any signed header or the message body is modified after signing, the hash will not match and verification will fail. Common culprits include:

• Mailing lists that add footers or modify the Subject line
• Email gateways that rewrite headers for compliance or security scanning
• Forwarding services that alter message headers

DNS Issues

• The DKIM public key record does not exist or is unreachable
• The selector in the signature does not match any published key
• DNS propagation delays after a key rotation

Configuration Errors

• The private key does not match the published public key
• The signing algorithm specified in the signature does not match the key type
• Headers listed in the h= tag were not included in the actual signature computation

Detailed guides:

• Why Does DKIM Fail? What Can You Do About It?
• Invalid DKIM Signature Error: Here’s How You Can Fix It
• Avoiding the Common SPF and DKIM Mistakes in 2026

DKIM vs SPF: Complementary, Not Competing

DKIM and SPF serve different purposes and have different strengths:

Feature	SPF	DKIM
What it verifies	Sending server’s IP address	Message integrity and origin
How it works	DNS lookup of authorized IPs	Cryptographic signature verification
Survives forwarding	No - forwarding changes the sending IP	Yes - signature travels with the message
Protects content integrity	No	Yes - detects tampering
DNS record type	TXT on the domain	TXT at selector._domainkey.domain
DMARC alignment basis	Return-Path domain	d= domain in signature

Because SPF breaks during email forwarding (the forwarding server’s IP is not in the original domain’s SPF record), DKIM is often the only authentication method that passes for forwarded messages. This makes DKIM alignment essential for domains that use mailing lists, forwarding rules, or any relay infrastructure.

Detailed guides:

• How SPF Differs from DKIM and DMARC
• Are Your SPF and DKIM Identifiers Aligned?
• How to Combine SPF Testing, DKIM, and DMARC for Security

DKIM for Forwarded and Relayed Mail

One of DKIM’s most important practical advantages over SPF is its behavior during email forwarding. When a message is forwarded through an intermediary server (a mailing list, an auto-forward rule, or a relay service), SPF breaks because the forwarding server’s IP address is not listed in the original domain’s SPF record. DKIM, by contrast, survives forwarding as long as the message content is not modified.

This is why DKIM is critical for DMARC compliance in environments with:

• Mailing lists - Organizations that participate in industry mailing lists or internal distribution groups
• Email forwarding - Users who forward email from one provider to another (e.g., forwarding a university address to Gmail)
• Shared hosting - Environments where email passes through shared relay servers
• Email gateways - Security appliances that relay mail without modifying content

However, DKIM will break if the intermediary modifies the signed portions of the message. Common modifications that break DKIM include adding footers, rewriting the Subject line, or stripping attachments. Mailing list software like Mailman and LISTSERV often adds list headers and footers, which can break body-based DKIM signatures.

The solution is to configure DKIM with c=relaxed/relaxed canonicalization (which tolerates minor whitespace changes) and to ensure that any mailing list software you operate is configured to preserve DKIM signatures where possible.

Common DKIM Configuration Patterns

Different email infrastructure setups require different DKIM configuration approaches:

Single Provider

If all your email goes through a single provider (e.g., Google Workspace), that provider handles DKIM signing automatically. You just need to publish the public key they provide in your DNS.

Multiple Providers with Separate Selectors

When multiple services send email on your behalf, each service gets its own DKIM key pair with a unique selector. For example:

• google._domainkey.example.com - Google Workspace’s DKIM key
• s1._domainkey.example.com - SendGrid’s DKIM key
• k1._domainkey.example.com - Mailchimp’s DKIM key

Each service signs messages with its own private key, and receivers look up the correct public key based on the selector in the DKIM-Signature header.

On-Premises Signing

Organizations running their own mail servers (Exchange, Postfix, Exim) need to generate their own key pairs, install the private key on the mail server, and publish the public key in DNS. This gives you full control over the signing process but requires you to manage key generation, rotation, and storage.

DKIM and TLS: Different Layers of Security

DKIM and TLS (Transport Layer Security) both contribute to email security but operate at different layers:

• TLS encrypts the connection between mail servers during transmission, preventing eavesdropping in transit. It does not verify the sender’s identity or protect against spoofing.
• DKIM verifies the sender’s identity and message integrity but does not encrypt the message content.

Both are necessary for comprehensive email security.

Detailed guide: TLS and DKIM: Why You Need Both for Strong Email Security

Setting Up DKIM for Your Platform

DKIM configuration varies by email platform. The general process is:

1. Generate a DKIM key pair (your email platform usually does this)
2. Publish the public key as a DNS TXT record at the correct selector location
3. Enable DKIM signing on the sending platform
4. Verify the configuration with a DKIM Lookup

For platform-specific instructions, see these guides:

• Definitive Guide to Microsoft 365 SPF and DKIM Configuration
• DKIM Authentication: A Complete Guide to Secure Email Deliverability
• Setting SPF and DKIM for Salesforce
• Mastering SPF and DKIM for SendGrid
• Complete Guide to Setting Up Mailgun SPF and DKIM
• How AutoSPF Enables SPF and DKIM in cPanel

DKIM in the Authentication Stack

DKIM is one of three protocols that work together to authenticate email:

• SPF - Verifies the sending server is authorized
• DKIM - Verifies message integrity and provides a domain-level signature (this guide)
• DMARC - Ties SPF and DKIM together with alignment requirements, defines enforcement policy, and enables reporting

DMARC requires that at least one of SPF or DKIM passes and is aligned with the From header domain. In practice, configuring both SPF and DKIM maximizes your chances of passing DMARC, because if one method fails (e.g., SPF fails due to forwarding), the other can still provide a valid aligned result.

Detailed guides:

• How SPF, DKIM, and DMARC Work Together During Authentication Failures
• Email Authentication Protocols: SPF, DKIM, DMARC Explained
• How to Test SPF Flattener Compatibility with DMARC and DKIM

Diagnostic Tools

• DKIM Lookup Tool - Look up and validate DKIM public keys for any domain and selector
• Domain Auth Checker - Check SPF, DKIM, and DMARC in a single lookup
• SPF Checker - Validate your SPF record alongside DKIM
• DMARC Checker - Verify your DMARC policy and alignment settings

Next Steps

1. Verify your current DKIM setup - Use the DKIM Lookup Tool to check if your domain has valid DKIM keys published
2. Check alignment - Ensure the d= domain in your DKIM signatures matches your From header domain
3. Review key strength - Confirm you are using at least 2048-bit RSA keys
4. Plan key rotation - Establish a rotation schedule and document the process
5. Deploy DMARC - If you have not already, set up DMARC to enforce SPF and DKIM alignment and receive aggregate reports
6. Monitor with DMARC reports - Use DMARC aggregate reports to identify DKIM failures across all receiving servers