DKIM Authentication Guide [2026]

What Is DKIM (DomainKeys Identified Mail)?

DKIM (DomainKeys Identified Mail) is an email authentication protocol that adds a digital signature to outgoing messages. The receiving server can verify this signature against a public key published in your DNS, confirming that the message hasn’t been altered in transit and was authorized by your domain.

Unlike SPF, which validates the sending server’s IP address, DKIM validates the message itself through cryptographic signatures. This means DKIM signatures survive forwarding — a critical advantage for mailing lists, help desk systems, and email forwarding services where the sending IP changes but the message content remains intact.

DKIM was standardized in RFC 6376 and is now a cornerstone of email security. When paired with DMARC, DKIM helps prevent domain spoofing, phishing, and email fraud.

How DKIM Works: Signing and Verification

DKIM operates in two phases: signing (by the sender) and verification (by the receiver).

Signing Phase:

1. Your outgoing mail server generates a hash of specific email headers (From, To, Subject, Date, etc.) and the message body.
2. The server encrypts this hash with your domain’s private key, creating a digital signature.
3. This signature is added as a DKIM-Signature header to the email.
4. The signed message is sent to the recipient’s mail server.

Verification Phase:

1. The receiving server extracts the DKIM-Signature header from the incoming message.
2. It looks up your public key via DNS at selector._domainkey.yourdomain.com, using the selector and domain specified in the signature.
3. The receiver decrypts the signature using your public key and compares it against a freshly computed hash of the same headers and body.
4. If they match, DKIM passes. If not, DKIM fails.

This process ensures message integrity (the content wasn’t modified) and authenticity (the domain owner authorized the message). However, DKIM alone doesn’t prevent spoofing — that requires DMARC alignment.

The DKIM Record: DNS TXT Format

Your DKIM public key is published as a DNS TXT record at:

selector._domainkey.yourdomain.com

The record format follows this structure:

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

DKIM DNS Record Tags:

If the p= tag is empty (p=), this signals key revocation — all signatures using that selector will fail.

DKIM Selectors: What They Are and How to Find Them

A DKIM selector is an identifier that allows you to publish multiple DKIM keys for the same domain simultaneously. Selectors appear in two places:

1. In the DKIM signature header (s= tag)
2. In the DNS record path (selector._domainkey.yourdomain.com)

Why use selectors?

• Key rotation: Publish a new key with a new selector before revoking the old one.
• Third-party senders: Gmail, Mailchimp, or other services signing on your behalf use their own selectors (e.g., google, k1, mte1).
• Per-server keys: Large organizations may use different selectors per mail server or department.

How to find your DKIM selector:

Examine the DKIM-Signature header in an email you sent. Look for the s= tag:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    h=from:to:subject:date; bh=...; b=...

Here, the selector is selector1. Your public key would be published at:

selector1._domainkey.example.com

Common selectors include default, google, k1, k2, mail, smtp, mte1 (for Mailchimp), and date-based selectors like 2026-03.

DKIM Record Examples

Below are real-world DKIM record examples for different providers and configurations.

Example 1: Google Workspace

DNS record:

google._domainkey.example.com    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu8..."

Google uses the google selector by default. The public key is a 2048-bit RSA key (starts with MIIBIjANBg...).

Example 2: Microsoft 365

DNS records (Microsoft uses two selectors):

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

Microsoft 365 rotates between selector1 and selector2 for key rotation.

Example 3: Mailchimp

DNS record:

k1._domainkey.example.com    TXT    "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Mailchimp uses the k1 selector and omits the v=DKIM1 tag (still valid, as v= is technically optional in practice but recommended).

Example 4: Self-Hosted Mail Server (Postfix + OpenDKIM)

DNS record:

mail._domainkey.example.com    TXT    "v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvN..."

The t=s flag enforces strict subdomain matching (the d= domain must exactly match the From header domain, not just the organizational domain).

Example 5: Ed25519 Key (Modern)

DNS record:

2026._domainkey.example.com    TXT    "v=DKIM1; k=ed25519; p=MCowBQYDK2VwAyEArM8..."

Ed25519 keys are significantly shorter than RSA keys (only ~68 bytes vs. 256+ bytes for RSA-2048) and offer equivalent or better security.

Creating a DKIM Record

To create and deploy a DKIM record:

Step 1: Generate a Key Pair

Use your mail server’s tools or a DKIM key generator:

• Postfix + OpenDKIM: opendkim-genkey -s selector -d yourdomain.com -b 2048
• Google Workspace: Admin Console → Apps → Gmail → Authenticate Email → Generate New Record
• Microsoft 365: Exchange Admin Center → Protection → DKIM → Enable DKIM signing
• Command-line (OpenSSL): openssl genrsa -out private.key 2048 && openssl rsa -in private.key -pubout -outform PEM

Step 2: Publish the Public Key in DNS

Add a TXT record at selector._domainkey.yourdomain.com with:

v=DKIM1; k=rsa; p=<base64-encoded-public-key>

Strip any -----BEGIN PUBLIC KEY----- headers and newlines from the public key before adding it to DNS.

Step 3: Configure Your Mail Server

Configure your mail server to sign outgoing messages with the private key using the chosen selector and domain.

• Postfix (OpenDKIM): Edit /etc/opendkim.conf and add the domain, selector, and key path.
• Google Workspace: Click “Start Authentication” after DNS propagation.
• Microsoft 365: Enable DKIM signing in the Exchange Admin Center after DNS records are published.

Step 4: Test Your DKIM Signature

Send a test email to a service like [email protected] or use our DKIM checker. Verify the signature passes and the selector resolves correctly in DNS.

RSA vs Ed25519: DKIM Key Algorithms

DKIM supports two signing algorithms:

RSA-SHA256 (Standard)

• Key sizes: 1024-bit (weak, avoid), 2048-bit (recommended), 4096-bit (overkill for email)
• Pros: Universal support across all mail servers and receivers
• Cons: Larger DNS records (2048-bit keys produce ~400-byte TXT records), slower signing/verification
• Use when: You need maximum compatibility

Ed25519-SHA256 (Modern, RFC 8463)

• Key size: 256-bit (equivalent security to RSA-3072)
• Pros: Smaller DNS records (~90 bytes), faster signing/verification, more secure per bit
• Cons: Not yet universally supported (Gmail, Yahoo, Outlook support it; some smaller providers may not)
• Use when: Your receivers support it and you want future-proof security

Recommendation: Use RSA-2048 for now unless you’ve verified your primary receivers support Ed25519. As adoption grows, Ed25519 will become the preferred choice. Our 2026 email authentication research tracks current Ed25519 and DKIM adoption trends.

DKIM Canonicalization (relaxed vs simple)

Canonicalization defines how DKIM treats whitespace, line breaks, and formatting before hashing the message. DKIM supports two modes for headers and body separately:

simple (strict)

• No modifications allowed — the message must be byte-for-byte identical
• A single added space or line break causes signature failure
• Use when: You control the entire mail path and need maximum integrity guarantees

relaxed (lenient)

• Allows minor whitespace changes (trailing spaces removed, tabs converted to spaces, line breaks normalized)
• Survives mailing list footers, signature blocks, and mail server modifications
• Use when: Your email passes through mailing lists, forwarders, or other intermediaries

Default recommendation: c=relaxed/relaxed (both header and body use relaxed mode). This is the most robust choice for real-world email.

The canonicalization mode is specified in the c= tag of the DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector;

DKIM Key Rotation

DKIM keys should be rotated periodically to limit exposure if a private key is compromised. Best practices:

Rotation Schedule:

• Annual rotation: Minimum acceptable frequency
• Quarterly rotation: Recommended for high-security environments
• On-demand rotation: Immediately rotate if you suspect key compromise

How to Rotate Keys:

1. Generate a new key pair with a new selector (e.g., change mail to mail2 or use date-based selectors like 2026-03).
2. Publish the new public key in DNS at newselector._domainkey.yourdomain.com.
3. Wait for DNS propagation (24-48 hours recommended, though TTL may be shorter).
4. Configure your mail server to sign new outgoing messages with the new selector and private key.
5. Keep the old public key published in DNS for at least 7 days to allow in-flight emails to be verified.
6. After the grace period, delete the old DNS record and securely destroy the old private key.

Why selectors matter for rotation: Without selectors, you’d have to replace your public key in-place, breaking verification for any emails signed with the old key still in transit. Selectors let you run both keys simultaneously during the transition.

DKIM and DMARC Alignment

DKIM results feed into DMARC alignment checks. For DMARC to pass, at least one of the following must be true:

• SPF aligned (Return-Path domain matches From header domain)
• DKIM aligned (DKIM d= domain matches From header domain)

DKIM Alignment Modes:

• Relaxed mode (default): The organizational domain must match (e.g., DKIM d=mail.example.com aligns with From: [email protected])
• Strict mode: The domains must exactly match (e.g., DKIM d=example.com aligns with From: [email protected], but d=mail.example.com does not)

Example of DKIM-aligned DMARC pass:

From: [email protected]
DKIM-Signature: d=example.com; s=selector; ...
DMARC: example.com (p=reject, aligned=DKIM)

Here, the d=example.com in the DKIM signature matches the From domain, so DMARC alignment passes even if SPF fails.

Example of DKIM misalignment:

From: [email protected]
DKIM-Signature: d=mailchimp.com; s=k1; ...
DMARC: example.com (p=reject, aligned=FAIL)

Mailchimp signed the message with d=mailchimp.com, which doesn’t match example.com. DMARC alignment fails unless SPF passes.

DKIM vs SPF

Both DKIM and SPF are email authentication protocols, but they validate different aspects of the message.

In practice: Use both. DKIM provides message integrity and survives forwarding. SPF prevents IP spoofing for direct sends. DMARC ties them together by requiring at least one to align with the From: domain.

Common DKIM Failures and How to Fix Them

For a deeper walkthrough of diagnosing authentication failures, see our DMARC failure guide.

Failure: “DKIM selector not found”

• Cause: DNS record missing or selector name mismatch
• Fix: Verify the DNS TXT record exists at selector._domainkey.yourdomain.com using dig or nslookup. Ensure the selector in your mail server config matches the DNS record name.

Failure: “Body hash mismatch”

• Cause: Message body was modified after signing (common with mailing lists that add footers)
• Fix: Use c=relaxed/relaxed canonicalization. If you control the mailing list, configure it to add footers before DKIM signing, not after.

Failure: “Signature expired”

• Cause: The x= tag (signature expiration timestamp) has passed
• Fix: Remove or extend the x= tag in your DKIM signing configuration. Most mail servers don’t set expiration by default.

Failure: “Key too short”

• Cause: 1024-bit RSA keys are considered weak and rejected by some receivers
• Fix: Regenerate your key pair with 2048-bit or 4096-bit RSA, or switch to Ed25519.

Failure: “Headers modified”

• Cause: One or more signed headers (specified in h= tag) were altered in transit
• Fix: Check the h= tag in the DKIM-Signature header. Ensure you’re not signing headers that intermediate servers modify (e.g., Received, X-* headers). Stick to From, To, Subject, Date, and Message-ID.

Failure: “DKIM signature missing”

• Cause: Your mail server isn’t signing outgoing messages
• Fix: Verify your DKIM signing configuration is enabled and the private key path is correct. Check mail server logs for errors.

Frequently Asked Questions

What is DKIM?

DKIM (DomainKeys Identified Mail) is an email authentication protocol that adds a digital signature to outgoing messages. The signature is created using a private key on your mail server and can be verified against a public key published in your DNS records. This proves the message hasn’t been altered in transit and was authorized by your domain.

What is a DKIM selector?

A DKIM selector is a string identifier that allows you to publish multiple DKIM public keys for the same domain. It appears in the DKIM signature header (s= tag) and in your DNS record at selector._domainkey.yourdomain.com. Selectors are useful for key rotation, third-party services signing on your behalf, or rotating keys per mail server.

How do I create a DKIM record?

To create a DKIM record: (1) Generate a public/private key pair using your mail server or email provider’s tools. (2) Publish the public key as a DNS TXT record at selector._domainkey.yourdomain.com with the format v=DKIM1; k=rsa; p=yourPublicKeyHere. (3) Configure your mail server to sign outgoing messages with the private key using that selector.

What is the difference between DKIM and SPF?

SPF validates the sending server’s IP address, while DKIM validates the message content itself using cryptographic signatures. DKIM signatures survive email forwarding, but SPF breaks when messages are forwarded because the forwarding server’s IP won’t match the original domain’s SPF record. Both are complementary protocols used by DMARC.

Why is my DKIM failing?

Common DKIM failure causes include: selector not found in DNS (wrong selector name or DNS not propagated), body hash mismatch (message modified in transit by mailing lists or antivirus), signature expired, public key too short (1024-bit RSA is weak), or headers modified after signing. Check your DKIM record exists and mail server configuration.

How do I find my DKIM selector?

To find your DKIM selector, examine the DKIM-Signature header in an email you sent. Look for the s= tag in that header — that’s your selector. If you don’t have access to sent emails, check your mail server configuration or email provider’s documentation for the selector name they use.

Does DKIM prevent spoofing?

DKIM alone doesn’t prevent spoofing — it only proves the message was signed by whoever holds the private key. An attacker can send email from a different domain with their own valid DKIM signature. DKIM must be paired with DMARC, which checks that the DKIM signing domain (d= tag) aligns with the From header, to prevent spoofing effectively.

Related Protocols

• DMARC — Uses DKIM results (with alignment) to enforce email policy and prevent domain spoofing
• SPF — Complements DKIM by authorizing sending servers via IP address
• ARC — Preserves DKIM results through forwarding chains and mailing lists