DKIM (DomainKeys Identified Mail)
RFC 6376 reference plus RFC 8301 (rsa-sha256 required, 1024–4096-bit keys) and RFC 8463 (ed25519-sha256) — signature and key record syntax, tag meanings, canonicalization, signing scope, and risks.
Reference6 min read
Who it is for ESP operators, Senders
Applies to senders on any platform
ContentsOn this page — 7 sections
DKIM lets your domain take responsibility for a message by signing it. Receivers check the signature against a public key you publish in DNS. A valid signature proves that the signed content was not changed after signing, and it ties the message to the d= domain, which is the identifier DMARC checks for alignment (see DMARC). Unlike SPF, DKIM survives forwarding, as long as the signed content is not modified.
DKIM is defined in RFC 6376. It authenticates the content of the message: the signer adds a DKIM-Signature header that contains cryptographic hashes of selected headers and of the body.
The DKIM-Signature header: tag reference
| Tag | Req? | Meaning |
|---|---|---|
v= |
Required | Version; must be 1. |
a= |
Required | Signing algorithm: rsa-sha256 or ed25519-sha256 (RFC 8463). rsa-sha1 MUST NOT be used (RFC 8301). |
b= |
Required | The signature itself, in base64. Whitespace is ignored. |
bh= |
Required | The hash of the canonicalized body (limited by l= if present), in base64. |
c= |
Optional | Canonicalization, written as header/body, where each part is simple or relaxed. The default is simple/simple, and c=relaxed on its own means relaxed/simple. |
d= |
Required | SDID, the signing domain that claims responsibility. It must have a key record in DNS. This is the identifier used for DMARC alignment. |
h= |
Required | An ordered list of the signed header fields, separated by colons. It must not be empty and must not include the DKIM-Signature being created. It may list the same name several times, and may list fields that do not exist (see oversigning below). |
i= |
Optional | AUID, the identity of the agent or user: an address whose domain must be the same as d= or a subdomain of it (exactly the same if the key record has the flag t=s). The default is @ followed by the d= value. |
l= |
Optional | Body length: the number of canonicalized body octets covered by bh=. The default is the entire body. This is a security risk; see below. |
q= |
Optional | The method for retrieving the key. Only dns/txt is defined (the default). |
s= |
Required | The selector, which names the key within the domain (see the key record below). |
t= |
Recommended | The signature timestamp, in Unix seconds. Verifiers may ignore signatures with timestamps in the future. |
x= |
Recommended | An absolute expiration timestamp, which must be > t=. It is not a defense against replay. |
z= |
Optional | A copy of selected header fields at signing time, separated by ` |
Signing scope: which headers to sign
- The From: field MUST be signed. It is the identity DKIM exists to protect, and the field DMARC evaluates. In practice, also sign Subject, Date, To, Reply-To, Message-ID, the MIME headers and the List-* fields.
- Oversigning: listing a header name in
h=one more time than the header appears signs a "null" instance of it. Any header of that name added later (e.g., a second From: or Subject: inserted along the way) then breaks the signature. This is recommended for From, Subject, To and Reply-To. - When a header appears several times, its instances are signed from the bottom up. You cannot choose to sign only one of them.
The risk of the l= body length tag
l= lets a signature cover only the first N octets of the body, so that intermediaries can add content (e.g., mailing list footers) without breaking the signature. As a result, anything added after N octets is not verified. An attacker can replay a signed message with malicious content added at the end, and the signature still validates. This was exploited in practice ("DKIM l= vulnerability", 2024). Do not sign with l=. Verifiers should treat signatures with l= with suspicion, or ignore the exemption the tag grants.
The DNS key record
The key is published as a TXT record at:
<selector>._domainkey.<domain>
| Tag | Default | Meaning |
|---|---|---|
v= |
DKIM1 |
Version. If present, it must be the first tag. |
p= |
— (required) | The public key, in base64. An empty p= means the key is revoked. |
k= |
rsa |
Key type: rsa or ed25519 (RFC 8463). |
h= |
all allowed | The acceptable hash algorithms, separated by colons (sha256; sha1 is obsolete). |
s= |
* |
Service type: * or email. |
t= |
none | Flags: y means testing mode; s means the i= domain must be exactly the same as d= (no AUIDs on subdomains). |
n= |
empty | Notes for administrators to read. |
Example (Ed25519, from RFC 8463):
brisbane._domainkey.football.example.com. IN TXT
"v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="
Selector hygiene: selectors let you run several keys at the same time (for each system, each ESP or each date). To rotate keys, publish a new selector, switch signing to it, then revoke the old key. Never reuse a selector with a new key, because you lose the ability to tell old mail that was legitimately signed from forgeries.
Algorithms and key sizes (RFC 8301, RFC 8463)
| Rule | Requirement |
|---|---|
| Signing algorithm | Signers MUST sign with rsa-sha256. rsa-sha1 MUST NOT be used for signing or verifying (SHA-1 is historic). |
| RSA key size for signers | MUST use keys of ≥ 1024 bits. 2048 bits is recommended (the current operational baseline). |
| RSA key size for verifiers | MUST validate keys from 1024 to 4096 bits, and MAY support larger keys. MUST NOT treat signatures made with keys of < 1024 bits as valid. |
| Ed25519 (RFC 8463) | a=ed25519-sha256, key record k=ed25519, and p= is the Ed25519 public key in base64. The keys are 256 bits, so the encoded key is only 44 octets and fits in one TXT string of 255 bytes (large RSA keys often have to be split across strings). |
| Dual signing | For compatibility, sign with both rsa-sha256 and ed25519-sha256, using different selectors (one key record for each selector). Support for Ed25519 among verifiers is still not universal. |
Canonicalization
Canonicalization normalizes the content before hashing, so that the signature tolerates rewriting in transit. It does not change the message that is sent.
| Algorithm | Rules |
|---|---|
simple (header) |
Headers are used exactly as they appear, so any change breaks the signature. |
relaxed (header) |
Header names are lowercased, continuation lines are unfolded, runs of whitespace are reduced to a single space, trailing whitespace is removed, and whitespace around the colon is removed. |
simple (body) |
Trailing empty lines are removed, and the body ends with a single CRLF. |
relaxed (body) |
Whitespace at the end of lines is removed, runs of whitespace within lines are reduced to a single space, trailing empty lines are removed, and the body ends with a CRLF. |
relaxed/relaxed is the default in practice. simple header canonicalization breaks whenever any MTA folds or wraps headers again.
Verification behavior
- Each signature has one of three outcomes: SUCCESS, PERMFAIL (the failure cannot be recovered from: a bad signature, a revoked or undersized key, a syntax error) or TEMPFAIL (the failure is temporary, e.g., a DNS timeout).
- A failed signature is treated as if the message were unsigned. A DKIM failure is not in itself a reason to reject the message. It simply provides no positive identifier. DMARC is what turns the absence of an aligned pass into a policy decision.
- Multiple signatures are each evaluated on their own. Verifiers keep checking until one verifies. A message can legitimately carry a signature from the author's domain and signatures from one or more intermediaries.
- The verifier's output must include the
d=domain and the result. It appears later in the Authentication-Results header.
Deliverability notes
- Mailbox providers increasingly tie reputation to the DKIM d= domain, and prefer DKIM to SPF for DMARC alignment, enrollment in feedback loops and tools for senders.
- The requirements for bulk senders at Gmail and Yahoo in effect make an aligned DKIM signature, with a key of ≥1024 bits (2048 recommended), mandatory at scale.
- DKIM does not prevent replay. A spammer can resend a legitimately signed message unchanged to new recipients, and the signature still passes, which uses up the reputation of the d= domain. Mitigations are short
x=expiration times, selectors for each recipient or stream, and monitoring.
Related articles
Check your own record
The free check reads what your domain publishes in DNS.
In this topic
All 13 in Authentication →