What Is DKIM? How It Works and How to Set Up a DKIM Record

DKIM (DomainKeys Identified Mail) is an email authentication standard defined in RFC 6376 that lets a receiving mail server verify two things: the message was authorized by the owner of a specific domain, and the message content was not altered in transit. It does this through a public/private key pair: the sender signs outgoing mail with a private key, and the receiver fetches the corresponding public key from DNS to verify the signature.

DKIM does not by itself tell receivers whether a message is legitimate or what to do if the signature fails. That policy layer is what DMARC adds on top.

How the Signing and Verification Flow Works

When your mail server sends a message, it computes a cryptographic hash of selected message headers and the message body, then signs that hash with a private RSA key. The result goes into a DKIM-Signature header attached to the outgoing message.

The receiving server extracts the DKIM-Signature header and performs a DNS lookup at selector._domainkey.yourdomain.com to retrieve the public key. Using that key, it verifies the signature against the same headers and body hash. If the verification passes, the message is confirmed to have been signed by the claimed domain and to have arrived unmodified. If anything in the signed content changed after signing, verification fails.

RFC 6376 states directly: “DKIM’s mandatory output to a receive-side Identity Assessor is a single domain name” (the signing domain from the d= tag). The protocol does not assert that this domain matches the visible From address; that alignment check is DMARC’s job.

Anatomy of a DKIM-Signature Header

A DKIM-Signature header is a set of tag=value pairs. Here is an illustrative example (keys abbreviated):

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2024;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LFc...

The tags that matter:

Tag	Meaning
v=1	DKIM version; always 1
a=rsa-sha256	Signing algorithm; RFC 8301 requires rsa-sha256
d=example.com	The signing domain (SDID); used to build the DNS lookup
s=mail2024	The selector; combined with d= to form the DNS query
h=from:to:...	Colon-separated list of headers that were signed
bh=...	Base64 hash of the canonicalized message body
b=...	The actual signature, base64-encoded

The h= tag is worth understanding: only the headers listed here were included in the signature. If a header not in h= gets modified in transit, verification still passes. For that reason, best practice is to include from, to, subject, date, and message-id at minimum.

The DKIM DNS Record

The public key lives in a DNS TXT record at selector._domainkey.yourdomain.com. A typical record looks like this (public key abbreviated for readability):

mail2024._domainkey.example.com  IN TXT
  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

The fields:

• v=DKIM1 — record version
• k=rsa — key type
• p=... — the base64-encoded public key

Setting p= to an empty string (p=) signals that the key has been revoked and any mail signed with the corresponding private key should be rejected.

The 2048-bit split problem. DNS TXT record strings are limited to 255 characters per RFC 1035. A 2048-bit RSA key encodes to roughly 350-400 base64 characters, so it exceeds that limit. The correct fix is to split the p= value across multiple quoted strings inside a single TXT record — not into two separate TXT records. Most DNS providers handle this through their UI or by accepting the key split across quoted strings:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNA" "DCBiQKBgQC..."

RFC 8301 is specific: signers must use RSA keys of at least 1024 bits and should use at least 2048 bits. Smaller keys “are permanently failed evaluation.” Use 2048-bit keys.

Selectors: What They Are and Why They Matter

The selector (s= tag) is a label you choose that points to one specific public key in DNS. A domain can have many selectors active at the same time, each pointing to a different key. This matters for two reasons.

First, if you send through multiple providers — say, your own mail server plus Mailchimp — each provider needs its own key pair and its own selector. You might have mail2024._domainkey.example.com for your own server and mailchimp._domainkey.example.com for Mailchimp. If one provider’s key is compromised, you can revoke just that selector without affecting the others.

Second, key rotation uses selectors. You publish a new selector with a new key, update signing to use it, then after DNS propagation retire the old one by revoking its p= value. Messages sent before the rotation, which may still be in transit, continue to verify against the old key until it is revoked.

How to Set Up DKIM

The process differs slightly depending on whether you manage your own mail server or use an ESP (email service provider).

With an ESP (most SaaS teams): Most ESPs, including Coldletter, generate the DKIM key pair for you. Your ESP will give you either a TXT record to publish at selector._domainkey.yourdomain.com, or — increasingly common — a set of CNAME records that delegate the key management to the provider.

CNAME-based delegation is the default for SendGrid (Automated Security), Amazon SES (Easy DKIM), and others. Instead of hosting the public key yourself, you publish CNAME records like:

s1._domainkey.example.com  CNAME  s1.domainkey.u12345.wl123.sendgrid.net

The ESP hosts the actual TXT record with the public key. This lets the provider rotate keys automatically without any further DNS changes on your end.

With your own mail server: Generate a 2048-bit RSA key pair (OpenSSL or your MTA’s key generator), publish the public key as a TXT record at the appropriate selector._domainkey.yourdomain.com name, configure your MTA to sign outgoing mail with the private key, then verify with a DKIM checker such as MXToolbox or mail-tester.com.

Verification: After publishing the DNS record, send a test message and check the received headers for dkim=pass. Allow up to 48 hours for DNS propagation, though most changes resolve within minutes.

DKIM, SPF, and DMARC: the Division of Labor

These three protocols are distinct and complementary. Using one without the others leaves authentication gaps.

Protocol	What it checks	Where the check happens
SPF record	Whether the sending IP is authorized for the domain	Envelope sender (Return-Path), invisible to recipient
DKIM	Whether the message was signed by the claimed domain and arrived unmodified	DKIM-Signature header, survives forwarding if content unchanged
DMARC	Whether SPF or DKIM aligns with the visible From domain; defines policy (none/quarantine/reject)	Evaluated after SPF and DKIM; results reported to domain owner

As dmarc.org puts it: “Email authentication technologies SPF and DKIM were developed over a decade ago in order to provide greater assurance on the identity of the sender of a message.” DMARC builds on both, adding the alignment requirement and the policy enforcement that turns authentication pass/fail into a concrete action.

DKIM has one meaningful advantage over SPF: its signature travels with the message. SPF checks the sending IP, which changes the moment a message is forwarded. DKIM signatures survive forwarding as long as the message body and signed headers are not modified. That durability is why DMARC can use either SPF or DKIM alignment — but in practice DKIM alignment is more reliable across indirect mail flows.

For a complete picture of how these fit together, see What Is Email Authentication? SPF, DKIM, and DMARC Explained.

Common DKIM Problems

Signature fails after forwarding or through mailing lists. DKIM is cryptographically bound to the message at signing time. Mailing lists typically add footers, modify the subject line, or add list-specific headers. If any signed header or the body changes after signing, verification fails. The emerging fix is ARC (Authenticated Received Chain), which lets each intermediary document the authentication state it observed, preserving the audit trail even when the original signature no longer verifies. Relaxed canonicalization (c=relaxed/relaxed) helps tolerate minor whitespace changes but cannot survive content modification.

Key length below minimum. RFC 8301 requires a minimum of 1024-bit keys and recommends 2048-bit. Some legacy configurations still use 512-bit or 768-bit keys; these produce “permanently failed evaluation” at verification.

p= empty or missing. An empty p= tag means the key is revoked. If you see this in your own record, check whether your DNS was accidentally updated during a migration. A missing p= tag is a malformed record.

DMARC alignment failure despite DKIM pass. DKIM can pass while DMARC fails if the signing domain (d= tag) does not match the visible From address domain. This happens when an ESP signs with its own domain rather than yours. The fix is to configure the ESP to sign with your domain (or use a custom BIMI-aligned sender identity).

DNS propagation delay. Publishing a new DKIM record and immediately sending mail can produce verification failures if the receiving server queries DNS before the record has propagated. Wait for propagation or use a TTL-aware testing approach.

Good DKIM configuration is one layer of the sender reputation foundation that determines whether messages reach the inbox or the spam folder. Email deliverability best practices cover the full stack, but DKIM is a non-negotiable starting point.

Frequently Asked Questions