What Is DKIM? DomainKeys Identified Mail and the Signing Domain

DKIM (DomainKeys Identified Mail) is a cryptographic signature added to an email's headers. The signing server hashes selected headers and the body with a private key and records the result in a DKIM-Signature header. A receiver fetches the public key from DNS and verifies the signature. A pass proves that the domain in the d= tag took responsibility for the message. It does not prove that domain matches the visible From address.

DKIM is one of three authentication layers covered in the SPF, DKIM and DMARC overview. The specification is RFC 6376, published in September 2011 and now an IETF Internet Standard (STD 76). Two later RFCs updated its cryptography: RFC 8301 in January 2018 and RFC 8463 in September 2018. Google's sender guidelines require SPF or DKIM from all senders to personal Gmail accounts, and SPF, DKIM and DMARC from bulk senders.

What does a DKIM pass prove?

That a specific domain signed the message and that the signed parts have not changed since. RFC 6376 defines d= as "The SDID claiming responsibility for an introduction of a message into the mail stream". The signature covers the header fields listed in h= and a hash of the body in bh=. If any of those change in transit, verification fails.

Unlike SPF, which checks the IP address of the connecting server, DKIM travels with the message. A signature made at the origin can still verify after the message has passed through other servers, provided nothing signed was altered on the way.

What does it not prove?

That the signing domain is the domain in the From header. Nothing in RFC 6376 requires d= to match the address a reader sees. An email service provider can sign with its own domain, and the signature will pass.

Connecting the two is the job of DMARC. RFC 9989, published on 20 May 2026 and obsoleting RFC 7489, states the requirement directly: "A DMARC result of "pass" requires not only an SPF or DKIM pass verdict for the email message but also and more importantly that the domain associated with the SPF or DKIM pass be "aligned" with the Author Domain in one of two modes -- "relaxed" or "strict"." Relaxed alignment requires the same Organizational Domain, so d=news.example.com aligns with a From address at foo.example.com. Strict alignment requires identical domains. A message can carry several DKIM signatures, and it produces a DMARC pass "if any DKIM-Authenticated Identifier aligns with the Author Domain."

Google applies the same rule at the receiving end: "For direct email, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain."

What does a DKIM-Signature header look like?

A list of tag=value pairs. RFC 6376: "This header field contains all of the signature and key-fetching data." The example below is illustrative, with the base64 values shortened:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
    s=mail-202610-2048; t=1760572800; x=1761177600;
    h=from:to:subject:date:message-id;
    bh=<base64 hash of the canonicalized body>;
    b=<base64 signature data>

Reading it tag by tag:

• v=1: version. Required, and it must be 1.
• a=rsa-sha256: the signing algorithm. RFC 8301 removed the older option outright: "rsa-sha1 MUST NOT be used for signing or verifying."
• c=relaxed/relaxed: canonicalization for headers, then body. Optional; the default is simple/simple.
• d=example.com: the signing domain. Required. It is also half of the DNS name used to fetch the key.
• s=mail-202610-2048: the selector. Required. It is the other half of the DNS name.
• t= and x=: signature timestamp and expiry, in seconds since 1 January 1970 UTC. Both are recommended, not required. RFC 6376 notes that "The "x=" tag is not intended as an anti-replay defense."
• h=: the signed header fields, separated by colons. Required, and "This list MUST NOT be empty."
• bh=: the hash of the canonicalized body. Required.
• b=: the signature itself. Required. It is treated as an empty string while the signature is computed.

Two optional tags complete the set most readers will meet. i= names the user or agent on whose behalf the domain signs, and defaults to an empty local part at the d= domain. l= limits how much of the body is hashed, and is covered below.

Where does the public key live?

In a DNS TXT record whose name is built from the selector and the signing domain. RFC 6376, Section 3.6.2.1: "All DKIM keys are stored in a subdomain named "_domainkey". Given a DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag of "foo.bar", the DNS query will be for "foo.bar._domainkey.example.com"."

For the signature above, the receiver queries mail-202610-2048._domainkey.example.com. An illustrative record:

mail-202610-2048._domainkey.example.com.  IN  TXT  ( "v=DKIM1; k=rsa; p=<base64 public key, part 1>"
                                                     "<base64 public key, part 2>" )

The key record has its own tags. v=DKIM1 is recommended, and if present "This tag MUST be the first tag in the record." k= is the key type, defaulting to rsa. p= holds the public key, and "An empty value means that this public key has been revoked." The t=y flag marks a domain as testing DKIM, and verifiers "MUST NOT treat messages from Signers in testing mode differently from unsigned email".

The record is split into two quoted strings because of DNS tooling, not DKIM. RFC 8301 notes that widely used DNS configuration software "only handles a single 256-octet string in a TXT record, and RSA keys significantly longer than 1024 bits don't fit in 256 octets." RFC 6376 allows the split: "Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace." Two separate TXT records at the same selector are a different matter. The RFC says the results are undefined.

How do you find a domain's selectors?

You read them from a message. There is no standard way to list the selectors a domain publishes, because the DKIM lookup is a query for one specific name, <selector>._domainkey.<domain>, and nothing in RFC 6376 defines a query for the set. Selectors exist so a domain can run several keys at once: "To support multiple concurrent public keys per signing domain, the key namespace is subdivided using "selectors"." To find the one in use, open the source of a message the domain sent and read the s= value in its DKIM-Signature header. Google gives the same tip for finding your own selector.

What is canonicalization, and why is l= risky?

Canonicalization decides how strictly the signed content must survive transit. RFC 6376 defines two algorithms, simple and relaxed, chosen separately for headers and body with c=header/body. The default is simple/simple. A single name is a trap: "c=relaxed" is treated the same as "c=relaxed/simple", which leaves the body on the strict setting. Microsoft 365 signs with relaxed for both headers and body by default.

The l= tag caps how many body octets the signature covers. It was added for mailing lists that append footers, and the RFC is plain about its cost: "using the "l=" tag enables attacks in which an intermediary with malicious intent can modify a message to include content that solely benefits the attacker. ... To avoid this attack, Signers should be extremely wary of using this tag, and Assessors might wish to ignore signatures that use the tag." Content appended after the signed length is not covered by the signature at all.

How long should a DKIM key be?

At least 1024 bits, and 2048 where possible. RFC 8301, Section 3.2, replaced the original key-size text in RFC 6376: "Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits." Verifiers must handle keys from 1024 to 4096 bits, and "MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures."

Google enforces the floor: "Sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer. For security reasons, we recommend using a 2048-bit key if your domain provider supports this." Google Workspace offers 2048 and 1024 as options, and Amazon SES Easy DKIM adds a 2048-bit key by default.

For context, M3AAWG's 2019 rotation guidance described 1024-bit keys as "at the edge of attack for general purpose computer systems", while 2048-bit keys "are considered to be immune to cracking in today's computing environment."

What about Ed25519?

RFC 8463 adds Ed25519-SHA256 as a second algorithm, signalled by a=ed25519-sha256 in the signature and k=ed25519 in the key record. The RFC says "Signers SHOULD implement and verifiers MUST implement the Ed25519-SHA256 algorithm."

Receiver support lags the standard. In a test published on 16 April 2026, the email security vendor Red Sift reported that "Only 9 out of 19 providers (47%) successfully validate Ed25519 DKIM signatures", and that Gmail, Microsoft 365 and Yahoo were among those that did not. The same test found six providers still accepting 512-bit RSA keys, below the RFC 8301 floor, and all 19 validating 1536-bit and 4096-bit RSA keys. This is a single vendor's test, not an independent measurement. RFC 8463 itself shows the safe pattern: its example message carries both an RSA-SHA256 and an Ed25519-SHA256 signature, so a receiver without Ed25519 support can still verify the RSA one.

How often should DKIM keys be rotated?

At least every six months, according to M3AAWG's DKIM Key Rotation Best Common Practices: "DKIM keys should be rotated at least every six months." The March 2019 update relaxed the earlier recommendation of quarterly rotation.

The M3AAWG procedure, in outline:

1. Generate a new key pair and publish the public key under a new selector. Wait for DNS propagation.
2. Switch the mail server to sign with the new private key.
3. Leave the old public key in DNS for at least seven days and up to 30, so messages already in transit still verify.
4. Retire the old key by emptying its p= value. Do not delete the selector record, so it remains visible that the key was retired on purpose.

M3AAWG adds two rules. Never reuse a selector name: "The reuse of selector names is strongly discouraged." Reusing one breaks re-validation of old messages and runs into stale caches at receivers. And name selectors by date, as in its example sales-201309-1024. M3AAWG also describes keeping the next key published in advance.

Hosted providers impose their own timing. Microsoft 365 states that after a rotation "It takes four days (96 hours) for the new private key to start signing messages", and that there is currently no automatic rotation for *.onmicrosoft.com domains.

Why does DKIM survive forwarding but break on mailing lists?

Because forwarding usually leaves the message intact, and mailing lists usually do not. Google's forwarding guidance recommends DKIM precisely because "forwarded messages often fail SPF authentication", while a DKIM signature keeps verifying as long as signed content is untouched. Google lists what breaks it: modifying MIME boundaries, modifying the Subject, third-party software changing or re-encoding the body, expanding recipients with LDAP, and modifying signed headers "including To, Cc, Date, and Message-ID". A list that tags the Subject line or appends a footer does two of those things.

Microsoft describes the knock-on effect for mail modified in transit: "SPF fails because of the new message source (IP address). DKIM fails because of content modification. DMARC fails because of the SPF and DKIM failures."

Where does ARC fit?

ARC (Authenticated Received Chain, RFC 8617, Experimental) records the authentication results each intermediary saw before it modified the message. It "provides an authenticated "chain of custody" for a message", using three header fields: ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results. The RFC names mailing lists as a use case.

Receivers decide whether to trust a chain. Google tells forwarders to add it: "If you manage a forwarding service, including mailing lists or inbound gateways, add ARC headers to outgoing email." Microsoft 365 uses the original authentication results only from ARC sealers that an admin has added as trusted in the Defender portal.

Which selectors do the major providers use?

Each provider documents its own naming. Most publish CNAME records that point into the provider's DNS, which lets the provider manage the key while signing with d= set to your domain, the arrangement DMARC alignment needs.

• Google Workspace: "The default prefix selector is google", giving google._domainkey. Google notes that after turning on Gmail for an organization, it takes 24 to 72 hours before the DKIM key is available in the Admin console.
• Microsoft 365: selector1._domainkey and selector2._domainkey, CNAMEs whose names are "the same for all Microsoft 365 organizations". Only one is active at a time; the other is used after the next rotation. Existing domains point to targets such as selector1-contoso-com._domainkey.contoso.onmicrosoft.com. New custom domains added since May 2025 point to targets under dkim.mail.microsoft, and the two formats cannot coexist for the same selector.
• Amazon SES: three CNAME records per identity, named with per-identity tokens (<token>._domainkey.<domain>) and pointing to <token>.dkim.<region>.amazonses.com. There is no fixed selector name.
• Twilio SendGrid: s1._domainkey and s2._domainkey, as CNAMEs into sendgrid.net.
• Mailchimp: two CNAME records for DKIM. Its help page refers to k2._domainkey.

Which Gmail errors point to DKIM?

Gmail returns dedicated codes for DKIM and alignment failures, each with a temporary and a permanent form:

• 421 4.7.30: "Your email has been rate limited because DKIM authentication didn't pass for this message. Gmail requires all email bulk senders to authenticate their email with DKIM."
• 550 5.7.30: "This message was blocked because it didn't pass DKIM authentication. Gmail requires bulk email senders to authenticate their email with DKIM."
• 421 4.7.32: "Your email has been rate limited because the From: header (RFC5322) in this message isn't aligned with either the authenticated SPF or DKIM organizational domain."
• 550 5.7.32: "Your email was blocked because the From: header (RFC5322) in this message isn't aligned with either the authenticated SPF or DKIM organizational domain."

The split matters for debugging. A 4.7.30 or 5.7.30 means the signature itself did not verify: check the selector record, the key, and anything that modifies the message after signing. A 4.7.32 or 5.7.32 means authentication may have passed, but for a domain that does not align with the From header: check the d= value your provider signs with. When neither SPF nor DKIM passes, Gmail uses 5.7.26 instead. The full list of SMTP error codes covers the rest.

How Trueguard handles this

DKIM key records are public, and their names give away infrastructure. A record at google._domainkey, or a selector1._domainkey record pointing to onmicrosoft.com, shows which provider hosts a domain's mail. Trueguard's email validation queries these known selectors, alongside other DNS signals such as MX records, to identify the mailbox provider before it checks an address. It also shows the limit described above: a check can only test selector names it already knows.