DKIM

From Learn, the They Sent It email marketing encyclopedia · First edition · Updated October 31, 2026

DKIM (DomainKeys Identified Mail) is an email authentication method. The sending server signs a message with a private key and adds the signature to the DKIM-Signature header. The receiving server looks up the public key in DNS and verifies the signature. If the signature is valid, the covered headers and message body were not altered in ways that affect the canonical form, and the message was signed by a server with access to the private key for the signing domain.^[1]

DKIM is defined by RFC 6376, an Internet Standard (STD 76). It is the more reliable of the two core authentication methods: where SPF checks a property of the sending server (its IP address) and breaks at forwarding, DKIM attaches a cryptographic property to the message itself. A DKIM signature survives plain forwarding. DKIM alignment is what most brands use to pass DMARC when sending through an email platform, because the platform's envelope sender (MAIL FROM) is on the platform's domain, not the brand's. A custom DKIM signing domain aligns with the brand's From header under DMARC relaxed alignment.^[6]

How DKIM works

Signing happens on the sending side before the message leaves the server. The signer:

Selects the headers to sign (From must be included; Subject, Date and other headers are typically added).
Canonicalizes the selected headers and the message body - normalizing whitespace and line endings according to the chosen canonicalization algorithm.
Hashes the body and places the hash in the bh= tag.
Constructs the DKIM-Signature header with the tag values but no signature (b=) yet.
Hashes the canonicalized headers listed in h= followed by the constructed DKIM-Signature header (with b= left empty), then signs the hash with the private key.
Places the Base64-encoded signature in b= and prepends the complete header to the message.

Verification is the same process in reverse. The receiving server reads the DKIM-Signature header, fetches the public key from DNS using <s=>._domainkey.<d=>, canonicalizes the message exactly as the signer would, and verifies the signature. Any change to a signed header, or to the signed part of the body, that affects the canonicalized input breaks the signature. Relaxed canonicalization tolerates minor whitespace changes; only changes that alter the canonical form invalidate it.

A message can carry more than one DKIM-Signature. A forwarding service may add its own alongside the original. Verifiers may check each signature in turn; any valid signature is sufficient. DMARC alignment requires one valid signature whose d= aligns with the From domain.^[1]

Selectors and DNS lookup

The selector (the s= tag) identifies which public key to use. The full DNS name for the public key lookup is:

<selector>._domainkey.<domain>

For example, if the DKIM-Signature has d=example.com and s=k1, the verifier looks up:

k1._domainkey.example.com  TXT

Selectors let a domain publish multiple keys at the same time under different names. This is what makes key rotation possible without any gap in delivery: publish the new key under a new selector, configure the signer to start using it, then remove the old selector after the old signatures have expired.

Selectors also let an ESP publish a key at the brand's own domain using a CNAME. The brand creates a CNAME at the selector name in their DNS, pointing to the ESP's own infrastructure. The ESP controls the key behind that CNAME. This is the mechanism behind most ESPs' "custom DKIM domain" feature.

Signature header tags

The DKIM-Signature header is a semicolon-separated list of tag=value pairs:

DKIM-Signature header tags^[1]
Tag	Required?	What it holds
`v=`	Required	Version. Always 1 in the DKIM-Signature header. (DKIM1 is the value used in the DNS public key record.)
`a=`	Required	Algorithm. rsa-sha256 is the standard; ed25519-sha256 requires RFC 8463 support at the verifier.
`b=`	Required	The signature value, Base64-encoded.
`bh=`	Required	The body hash, Base64-encoded. Computed over the canonicalized message body up to the length given by l=, or the full body if l= is absent.
`c=`	Optional (default simple/simple)	Canonicalization algorithm for header and body. relaxed/relaxed is the practical choice for most senders.
`d=`	Required	Signing Domain Identifier (SDID). The d= domain is what verifiers look up and what must align with From for DMARC.
`h=`	Required	List of signed headers, colon-separated. The From header MUST be in this list.
`i=`	Optional	Agent or User Identifier (AUID). Rarely used in practice.
`l=`	Optional	Body length limit. Covered separately in the l= section. Default: sign the entire body.
`s=`	Required	Selector. Combined with d= to form the DNS lookup name: <s>._domainkey.<d>.
`t=`	Optional	Signature timestamp, Unix epoch seconds.
`x=`	Optional	Signature expiry, Unix epoch seconds.

Key algorithms and sizes

RFC 6376 originally specified RSA with SHA-256 as the required algorithm. Since then, two updates have changed the picture:^[2][3]

RFC 8301 (Proposed Standard, 2018): Updates RFC 6376 to say signers MUST NOT use rsa-sha1. Signers MUST use RSA keys of at least 1024 bits and SHOULD use at least 2048 bits. Verifiers MUST support RSA keys from 1024 to 4096 bits and MUST NOT accept keys shorter than 1024 bits as valid. Gmail requires at least 1024 bits and recommends 2048.
RFC 8463 (Proposed Standard, 2018): Adds Ed25519-SHA256 (ed25519-sha256) as a second signing algorithm. Verifiers MUST implement Ed25519 verification; signers SHOULD support it. Ed25519 keys are much smaller (a 32-byte public key against a 256-byte modulus for 2048-bit RSA) and are considered stronger per bit than RSA, but they are not yet universally supported at every verifier. Signers using Ed25519 should also sign with RSA as a fallback.

The public key in DNS is published as a TXT record at the selector name. The record carries a p= tag with the Base64-encoded public key and a k= tag for the algorithm (rsa or ed25519):

k1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

An empty p= tag means the key has been revoked: all signatures using that selector should be treated as invalid. This is how you disable a key when it must be replaced immediately.

Canonicalization

Canonicalization normalizes the message before hashing so that minor formatting changes during transport do not break the signature. RFC 6376 defines two algorithms for headers and two for the body, applied independently:^[1]

Header canonicalization:

simple - headers must be exactly as signed. Any whitespace change breaks the signature.
relaxed - folds whitespace in header values, converts header names to lowercase, unfolds continuation lines. Resilient to minor MTA adjustments.

Body canonicalization:

simple - only allows an empty line at the end of the body to change. Any other body modification breaks the signature (exception: content added beyond the byte count specified by the optional l= tag is not covered).
relaxed - reduces all whitespace sequences within lines to a single space, removes trailing whitespace from each line.

The c= tag specifies both in the form header/body. The default is simple/simple, but relaxed/relaxed is the practical recommendation: some MTAs alter whitespace in ways that would break a simple-canonicalization signature even without malicious modification.

The l= body length tag

The optional l= tag limits how many bytes of the body are covered by the signature. Content added after the signed length is not covered and cannot be detected as modified.

This is a security risk. A receiver who sees a valid DKIM signature may treat the entire message as authenticated, including content the signer never signed. A spammer can take a legitimately signed message and append malicious content after the signed portion; the signature remains valid. For this reason, do not use the l= tag. Sign the entire body. If a mailing list or forwarding service adds a footer after your signed content and you need to work around it, the right solution is to work with the list operator, use ARC, or accept a signature failure on those paths, not to artificially limit what you sign.^[1]

Key rotation

Key rotation replaces the private key used for signing without causing mail to fail at receivers. The process:^[1]

Publish the new public key under a new selector in DNS. The old key remains in DNS and continues to verify in-flight mail.
Configure the signer to start signing new outbound messages with the new private key, using the new selector in s=.
Wait for in-flight messages signed with the old key to clear. RFC 5321 says the give-up time for undeliverable mail generally needs to be at least four to five days, so retain the old key through at least that window.
Remove the old key from DNS by either deleting the record or setting p= to empty to explicitly revoke it.

Do not reuse selectors. Some receivers cache DNS records aggressively. If you reuse a selector name with a new key, a receiver with a stale cache may try the old cached key against the new signature and fail. A new selector name sidesteps cache collisions entirely.

If a key is compromised, skip the wait in step 3 and revoke immediately by setting p= to empty. This causes old signed messages to fail verification, but that is the correct behavior when the key was compromised: those signatures can no longer be trusted.

ESP and CNAME delegation

Every major email platform signs outbound mail with DKIM. By default they sign with their own domain (e.g. klaviyomail.com, mcsv.net). That signing domain typically does not match your From domain, so DKIM does not align for DMARC.

Setting up a custom DKIM signing domain makes the platform sign with your domain instead. The most common mechanism is a CNAME in your DNS at the selector name, pointing to the ESP's infrastructure; some platforms use other arrangements such as NS delegation. The ESP controls the key pair; you publish the DNS record. When a receiver looks up your selector, it resolves to the ESP's TXT record with the real public key. The signature's d= is your domain, so DMARC alignment works.

Every platform has a help page for this setup. The CNAME approach means you do not hold the private key yourself - the ESP does. If you leave the platform, remove the CNAME.

In practice: a custom DKIM signing domain is the most important authentication step for a brand sending marketing email. It makes DMARC alignment work on the highest-volume mail stream. SPF alignment from a custom bounce domain is optional once DKIM alignment is established, DMARC only requires one to align.

Forwarding and mailing lists

DKIM survives plain forwarding because the signature covers the message, not the server. If a receiver forwards a message to another address and does not alter it, the DKIM signature remains valid at the final destination. This is the main advantage of DKIM over SPF for forwarded mail.

However, mailing lists often break DKIM. A typical mailing list processor:

Adds a subject prefix ([list-name]) to the Subject header, which is signed.
Adds a footer to the message body, which is signed.
Either modification invalidates the signature on the original domain.

ARC (Authenticated Received Chain) was designed to address this gap. It lets an intermediary record what authentication results it observed before making changes. A receiver who trusts the intermediary's ARC chain can still honor authentication information from upstream. ARC is described in RFC 8617 (Experimental) and is implemented by major receivers including Gmail and Outlook.

DMARC alignment

For a message to pass DMARC via DKIM, the d= domain in the DKIM signature must align with the domain in the From header. Alignment can be relaxed (the default) or strict:^[6]

Relaxed alignment: the signing domain and the From domain must share the same organizational domain. mail.brand.com aligns with brand.com. This is how custom DKIM on a subdomain aligns with the brand's root From domain.
Strict alignment: the signing domain and the From domain must be exactly equal. mail.brand.com does not align with brand.com.

DMARC only requires one authentication method to align: SPF or DKIM. For a brand sending through a platform, DKIM alignment via a custom signing domain is the standard path. A brand with DMARC at p=reject and no custom DKIM signing domain passes DMARC only if its platform's own domain happens to align, or if SPF alignment is set up separately. Neither is reliable without deliberate configuration.

Gmail, Yahoo and Microsoft requirements

Gmail, from February 1, 2024: bulk senders (approaching 5,000 messages per day to personal Gmail accounts) must set up both SPF and DKIM, and the From domain must align with either SPF or DKIM under DMARC. Gmail requires DKIM keys of at least 1024 bits and recommends 2048 bits.^[9]
Yahoo: the same requirements apply to bulk senders. Yahoo publishes no volume threshold.^[10]
Outlook.com, from May 5, 2025: senders above 5,000 per day must pass both SPF and DKIM, publish DMARC at p=none or above, and align. Failing mail is rejected with error 550 5.7.515.^[11]

DKIM2

The IETF DKIM working group has been developing a successor specification, informally called DKIM2. As of October 2026, there are three active Internet-Drafts in the working group and no published RFC. The drafts propose architectural changes including a different key publication mechanism and new approaches to the l= tag problem. The working group materials are available at the IETF Datatracker.^[8]

DKIM2 is work in progress. Nothing in the drafts changes current requirements or practice; the existing RFC 6376 Internet Standard remains authoritative.

What brands sign

We looked at the DKIM-Signature headers in a one-in-seven sample of 57,105 emails that published brands sent to our subscriptions, September 26 to October 26, 2026.^[12]

DKIM signatures in 57,105 emails, September 26 to October 26, 2026
Email carries at least one DKIM signature	99.99%
No DKIM signature	3 emails
Two or more signatures	48.7%

Signing domain, among signed emails
A signature's d= domain matches the From domain (last two labels)	94.6%
No signature matches the From domain (last two labels)	5.4%

Most common selectors in the sample
Selector	Share	Associated with
`def1`	41.8%	Klaviyo
`kl2`	36.2%	Klaviyo
`mtd1`	33.0%	Klaviyo
`s1`	8.0%	Mostly Klaviyo brands
`k3`	5.0%	Mailchimp
`kl1`	4.6%	Klaviyo
`hs2`	2.6%	HubSpot
`mtb1`	2.6%	Klaviyo
`acdkim1`	1.8%	ActiveCampaign
`hs1`	1.7%	HubSpot

Almost every email is signed. Only 3 of 57,105 carried no signature. That is expected: nearly all of this mail comes through email platforms that sign by default.
94.6% of signed emails carry a signature matching the From domain on its last two labels. The other 5.4% carry no signature that matches on that test. This test does not establish whether these messages passed DMARC or which authentication method supplied an aligned pass.
48.7% of signed emails carry two or more signatures, usually one for the brand's domain and one for the platform's.
Selectors mostly show which platform sent the email. Klaviyo brands sent 87.7% of this sample, which is why its selectors lead the table. A selector is only a label: brands and platforms can change it.

Method: the d= and s= values recorded from DKIM-Signature headers, in a one-in-seven sample by email. Domains were matched on their last two labels. That is a rough test, not the organizational domain lookup DMARC uses, so some domains, country-code ones especially, may be misclassified. We recorded signatures but did not verify them, so these figures show what was signed, not what passed. Algorithm (a=) and key size were not recorded and are not reported. Klaviyo brands dominate the archive, so these shares describe this archive, not all email.

Common mistakes

No custom DKIM signing domain when using an ESP. The platform signs with its own domain. The signature passes DKIM verification but does not align with the brand's From domain. If SPF alignment is also absent, DMARC fails. Setting up the custom DKIM domain is the fix.
Using the l= tag. It limits what is signed and allows content to be appended after the signed portion without detection. Leave it out.
Reusing selectors after key rotation. DNS caching can cause verifiers to try the old key against the new signature. Use a new selector name for each rotation.
Never rotating keys. A key used for years is harder to detect if compromised. Annual rotation is a common practice; more frequent for high-volume senders.
Leaving old CNAME entries in DNS after changing platforms. The old selector still resolves to the previous ESP. If they reuse the key pair, mail could technically verify under a key you no longer control.
Using a 1024-bit RSA key. Gmail currently accepts 1024-bit, but RFC 8301 says signers SHOULD use 2048 bits. A 1024-bit key created today is below current guidance. Use 2048-bit minimum for new keys.

History

2004: Yahoo develops DomainKeys; Cisco develops Identified Internet Mail. The two are merged.
2007: RFC 4871 publishes DKIM as a Proposed Standard.
2011: RFC 6376 replaces RFC 4871 and is promoted to Internet Standard (STD 76).^[1]
2018: RFC 8301 restricts the algorithm choices (no rsa-sha1, 2048-bit SHOULD).^[2] RFC 8463 adds Ed25519-SHA256.^[3]
2024: Gmail and Yahoo require DKIM from bulk senders.^[9]
2025: Outlook.com does the same for senders over 5,000 a day.^[11]
2026: IETF DKIM WG drafts toward DKIM2 (work in progress, no RFC published).^[8]

References

First edition, October 31, 2026, by Conner Baker. Corrections are made in place and noted here. October 31, 2026, after an independent review: labeled the From-domain figure as a rough last-two-label match, not a DMARC result, and withdrew the suggestion that unmatched mail depends on SPF alignment. Found an error? Tell us.