DKIM Record Explained: How DomainKeys Identified Mail Works

What Is DKIM?

DKIM, or DomainKeys Identified Mail, is an email authentication protocol that allows a sending domain to digitally sign outgoing messages using public-key cryptography. When a receiving mail server gets a DKIM-signed email, it retrieves the sender's public key from DNS and uses it to verify the signature. If the signature checks out, the server knows two things: the email genuinely came from an authorized sender for that domain, and the message was not tampered with during transit.

Think of DKIM as a tamper-proof seal on a package. When you send an email, your server attaches a cryptographic signature to the message header. If anyone modifies the email contents, the headers, or even certain invisible fields along the way, the seal breaks, and the recipient's server knows something is wrong.

DKIM was defined in RFC 6376 (September 2011) and has become one of the three pillars of modern email security alongside SPF and DMARC. While SPF validates which servers are allowed to send for your domain, DKIM verifies message integrity and authenticates the sending domain through cryptographic proof. Together with DMARC, which enforces policies based on SPF and DKIM results, these protocols form a comprehensive defense against phishing and spoofing attacks.

How DKIM Works: The Signing and Verification Process

Understanding the DKIM process requires looking at both the sending and receiving sides of the equation. Here is what happens step by step when a DKIM-signed email is sent and delivered.

Step 1: Key Pair Generation

The domain owner generates a pair of cryptographic keys: a private key and a public key. The private key is stored securely on the sending mail server (or provided by your ESP), while the public key is published as a DNS TXT record under a special subdomain.

Step 2: Signing Outgoing Messages

When the sending server dispatches an email, it uses the private key to create a digital signature. This signature is computed from selected portions of the email, typically the From header, Subject, Date, message body, and other specified header fields. The signature is then embedded in the message as a DKIM-Signature header field.

Step 3: DNS Lookup by Receiver

The recipient's mail server reads the DKIM-Signature header to identify the signing domain and the selector. It then performs a DNS lookup for the corresponding TXT record at selector._domainkey.yourdomain.com to retrieve the public key.

Step 4: Signature Verification

Using the public key, the receiving server decrypts the signature and compares it against a freshly computed hash of the same email components. If the two values match, DKIM passes, confirming the message is authentic and unmodified. If they do not match, DKIM fails, signaling potential tampering or misconfiguration.

Anatomy of a DKIM Record

A DKIM record is a DNS TXT record published at a specific subdomain following the format selector._domainkey.yourdomain.com. Let's break down a real-world DKIM record to understand each component.

Example DKIM Record

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

DKIM Selectors Explained

The selector is the prefix in the DNS lookup path that identifies which DKIM key to use. A single domain can have multiple selectors, which is essential when you use several services to send email. For example:

• google._domainkey.yourdomain.com for Google Workspace emails
• s1._domainkey.yourdomain.com for SendGrid transactional emails
• k1._domainkey.yourdomain.com for Mailchimp marketing campaigns
• selector1._domainkey.yourdomain.com for Microsoft 365 emails

Each selector points to a different public key, and each sending service uses its own corresponding private key to sign outgoing messages. Selectors do not interfere with each other, so you can run multiple DKIM configurations for the same domain simultaneously.

Understanding the DKIM-Signature Header

When an email is signed with DKIM, a DKIM-Signature header is added to the message. Here is an annotated example:

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

Why DKIM Matters for Deliverability and Reputation

DKIM is no longer optional for anyone serious about reaching the inbox. Here is why it plays such a critical role in modern email infrastructure.

Mailbox Provider Requirements

Google, Yahoo, and Microsoft now require DKIM authentication for bulk senders. Google's sender guidelines mandate that anyone sending more than 5,000 messages per day to Gmail accounts must have valid SPF, DKIM, and DMARC records. Microsoft's Outlook requirements, effective May 2025, impose similar authentication standards. Without DKIM, your messages face rejection or spam folder placement at major mailbox providers.

Building Domain Reputation

Every DKIM-signed email that passes verification contributes positively to your domain reputation. Over time, mailbox providers like Gmail and Outlook build a trust profile for domains that consistently authenticate their messages. This accumulated trust translates directly into better inbox placement rates. Unlike IP-based reputation, which can shift when you change sending infrastructure, domain reputation through DKIM follows your domain wherever you go.

Preventing Spoofing and Phishing

DKIM makes it significantly harder for attackers to forge emails that appear to come from your domain. While SPF validates the sending server, DKIM goes further by cryptographically proving that the message content has not been altered. When combined with a DMARC policy set to quarantine or reject, DKIM ensures that forged messages are blocked before they reach recipients.

DKIM vs. SPF vs. DMARC: How They Work Together

Each authentication protocol serves a distinct purpose in the email security ecosystem. Understanding how they complement each other is critical for complete protection.

The key concept connecting these protocols is alignment. DMARC requires that the domain used for SPF or DKIM authentication aligns (matches) with the domain in the visible "From" header. DKIM alignment means the d= value in the DKIM signature matches the "From" header domain. This is why configuring DKIM with your own domain, rather than relying solely on your ESP's default signature, is so important for passing DMARC checks. For a deeper dive into enforcement policies, see our guide on email authentication.

How to Set Up DKIM for Your Domain

Setting up DKIM involves three core steps: generating your key pair, publishing the public key in DNS, and enabling signing on your sending server or ESP. The exact process varies by provider, but the principles are the same.

General Setup Steps

1. Inventory your sending sources. List every service and server that sends email on behalf of your domain, including your primary mail server, marketing platforms, CRM systems, transactional email providers, and helpdesk tools.
2. Generate DKIM keys. Most ESPs (SendGrid, Mailchimp, Amazon SES, etc.) provide DKIM keys in their domain authentication settings. For self-managed servers, install a DKIM package like OpenDKIM.
3. Publish the public key in DNS. Add a TXT record at selector._domainkey.yourdomain.com with the public key value provided by your ESP or generated by your server.
4. Enable DKIM signing. Activate signing in your ESP's dashboard or configure your mail server to sign outgoing messages with the private key.
5. Test and verify. Send a test email and inspect the Authentication-Results header for dkim=pass. Use our DKIM checker to validate the DNS record.

Setup for Google Workspace

In the Google Admin console, navigate to Apps, then Google Workspace, then Gmail, and select "Authenticate email." Choose your domain, click "Generate New Record," select a 2048-bit key length, and copy the generated TXT record to your DNS provider. After DNS propagation (up to 48 hours), return to the Admin console and click "Start authentication."

Setup for Microsoft 365

Microsoft 365 uses CNAME records rather than TXT records for DKIM. You need to create two CNAME records for selector1._domainkey and selector2._domainkey pointing to Microsoft's DKIM infrastructure. In the Microsoft Defender portal, navigate to Email authentication settings, select the DKIM tab, and enable signing for your custom domain.

DKIM Key Rotation and Management Best Practices

Publishing your DKIM key is just the beginning. Proper key management is essential for long-term security and deliverability.

Why Rotate DKIM Keys?

DKIM key rotation limits the damage if a private key is ever compromised. If an attacker gains access to your private key, they can forge emails that pass DKIM verification until you replace the key. Regular rotation minimizes the window of exposure. Industry best practice recommends rotating DKIM keys at least every six months, though quarterly rotation provides stronger security.

How to Rotate Keys Without Downtime

1. Generate a new key pair with a new selector (e.g., switch from s1 to s2).
2. Publish the new public key in DNS under the new selector.
3. Wait for DNS propagation (24-48 hours).
4. Update your sending server to sign with the new private key and selector.
5. Keep the old public key in DNS for at least 7 days to allow in-flight messages to verify.
6. Remove the old DNS record after the transition period.

Additional Key Management Tips

• Never share private keys between different sending services. Each service should have its own selector and key pair.
• Monitor DKIM pass rates through DMARC aggregate reports. A sudden drop in DKIM pass rates may indicate a misconfigured key or unauthorized sending.
• Avoid 4096-bit keys despite their stronger encryption. Many DNS providers and email gateways (including Cisco's email security gateway) do not support keys above 2048 bits, which can cause silent DKIM failures.

Common DKIM Failures and How to Fix Them

DKIM failures can silently damage your deliverability. Here are the most frequent issues and their solutions.

DKIM, Email Forwarding, and ARC

One of DKIM's known limitations is its sensitivity to message modification during forwarding. Mailing lists, auto-forwarders, and security gateways often add footers, modify headers, or rewrite addresses, all of which can invalidate the DKIM signature.

The Authenticated Received Chain (ARC) protocol, defined in RFC 8617, was created to solve this problem. ARC allows intermediate servers to save the original authentication results and sign them, so that the final receiving server can still evaluate the original DKIM and SPF status even if the forwarding process broke them.

Major mailbox providers including Gmail, Microsoft, and Yahoo now support ARC validation. If you operate mailing lists or forwarding services, implementing ARC alongside DKIM helps preserve authentication across the delivery chain.

How to Verify Your DKIM Configuration

Regular verification ensures your DKIM setup remains functional and correctly configured. Here are several methods to check your DKIM records and signatures.

Method 1: Check the Email Headers

Send a test email to a Gmail account, open the message, click the three-dot menu, and select "Show original." Look for the Authentication-Results header. A passing result looks like:

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

Method 2: Use a DKIM Checker Tool

Our DKIM checker lets you enter your domain and selector to verify that the public key is published correctly in DNS and is properly formatted.

Method 3: Command-Line DNS Lookup

You can query your DKIM record directly using the dig or nslookup command:

dig TXT selector1._domainkey.yourdomain.com +short

This should return your DKIM public key record. If it returns empty or an error, the record is not published or has not propagated yet.

Method 4: DMARC Aggregate Reports

DMARC aggregate reports include DKIM authentication results for every message sent from your domain. Monitoring these reports over time gives you a comprehensive view of your DKIM pass rates across all sending sources. A drop in pass rates from a particular source signals a configuration issue that needs immediate attention.

Frequently Asked Questions

← Back to Blog