What Is DKIM? How Email Signing Works Under RFC 6376

DKIM (DomainKeys Identified Mail) lets a domain sign its outgoing mail with a private key and publish the matching public key in DNS, so a receiving server can verify that the message was authorized by that domain and that the signed parts were not altered in transit. It is defined in RFC 6376 (September 2011). DKIM authenticates the domain in the signature's d= tag, not the From address a recipient reads, and it takes DMARC to tie the two together.

What is DKIM, and which question does it answer

DKIM answers one question about a message: did a system holding the private key of the domain named in the signature produce it, and has the signed content arrived intact? RFC 6376 section 2.5 calls that domain the Signing Domain Identifier (SDID), carried in the d= tag, and section 3.11 makes it the identifier a verifier outputs. The From header a person reads is not part of that output.

DKIM is a signature scheme, not an authorization list; SPF, covered in the post on what an SPF record is, is the record that names permitted servers.

How a DKIM signature is created and verified, step by step

A DKIM signature is two hashes and one signing operation, and RFC 6376 section 3.7 sets the order: hash the body into bh=, hash the listed headers together with the DKIM-Signature header itself (its b= value empty), then sign that second hash.

1. Choose the headers to sign. The signer lists them in the h= tag. RFC 6376 section 5.4 requires From, and section 5.4.1 lists Reply-To, Subject, Date, To and Cc among the recommended fields.
2. Canonicalize. Section 3.4 defines simple, which tolerates almost no change, and relaxed, which folds whitespace and lowercases header names so a relay's reformatting does not break the signature. The default is simple/simple.
3. Hash the body. The canonicalized body (or the first l= octets of it) is hashed with SHA-256 and base64-encoded into bh=.
4. Sign the headers. The listed headers and the DKIM-Signature header itself (with b= empty, bh= filled) are hashed and signed with the private key. The result goes into b=.
5. The receiver fetches the key. It reads d= and s= from the signature and queries the TXT record at <s>._domainkey.<d> (section 3.6.2.1).
6. The receiver verifies. It recomputes the body hash against bh=, then checks b= against the public key. Section 6.1 says verifiers SHOULD evaluate each DKIM-Signature header independently.

The DKIM-Signature header tag by tag

The DKIM-Signature header is a list of tag=value pairs separated by semicolons, and RFC 6376 section 3.5 defines which are required. A typical signature looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 s=s1; t=1758326400; x=1758931200;
 h=from:to:subject:date:message-id;
 bh=2jmj7l5rSw0yVb/vlWAYkK/YBwk=;
 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

The DKIM record in DNS: selector._domainkey, v=DKIM1, k, p, t, h and n

A DKIM record is a TXT record at <selector>._domainkey.<domain> holding the public key, and RFC 6376 section 3.6.1 defines its tags. The record for the signature above looks like this:

s1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; t=s; h=sha256; n=Rotated 2026-09; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Under t=y, section 3.6.1 says verifiers MUST NOT treat the signer's mail differently from unsigned email, so a key left in test mode gives the domain no DKIM protection.

A 2048-bit RSA public key is about 392 base64 characters, and DNS caps each character-string in a TXT record at 255 octets (RFC 1035 section 3.3), so the record has to be published as two or more quoted strings that a resolver concatenates without whitespace (RFC 6376 section 3.6.2.2). Some DNS consoles split the string automatically; others truncate it, and a truncated p= is an invalid key.

DKIM selectors and key rotation: several keys, no downtime, revocation by empty p

A DKIM selector is the label in front of _domainkey that lets one domain publish several public keys at once, so keys can be rotated and shared across senders without an outage. RFC 6376 section 3.6.2.1 builds the lookup name from the s= and d= tags of each signature.

Rotation with no downtime uses two selectors: publish the new public key under a new selector, switch signing to it, wait for mail signed with the old key to finish arriving, then retire the old record. Revocation is explicit: under section 3.6.1 an empty p= means the key has been revoked, and verifiers SHOULD return an error for any signature referencing it.

RFC 8301 (January 2018) sets the key rules that apply today: section 3.1 requires rsa-sha256 and states that rsa-sha1 MUST NOT be used; section 3.2 requires RSA keys of at least 1024 bits, says signers SHOULD use at least 2048, and requires verifiers to accept 1024 to 4096 bits.

RFC 8463 (September 2018) adds ed25519-sha256, whose 44-character public key fits one TXT string. Section 5 says verifiers MUST implement it and signers SHOULD; section 6 notes that signers can add both an RSA and an Ed25519 signature for backward compatibility, under different selectors because each selector holds one key record. A given receiver's Ed25519 support has to be confirmed rather than assumed.

What DKIM does not do, and how DMARC uses the d= domain

DKIM makes no statement about who may send, what the visible From header says, or any message that arrives unsigned. RFC 6376 section 8.6 describes replay: a message signed once by a reputable domain can be re-sent to many recipients with the signature still verifying, since nothing in the signature binds it to a set of recipients.

DMARC (RFC 9989, May 2026) connects the d= domain to the From header. Sections 3.2.3 and 4.4.1 make the d= value of a validated signature the DKIM-Authenticated Identifier, and section 5.3.5 passes the message when any authenticated identifier aligns with the From domain. An aligned DKIM pass is enough; SPF is not also required, and any one aligned signature among several produces a pass.

Alignment has two modes, set by the adkim tag (RFC 9989 section 4.7): relaxed, the default, accepts d=mail.example.com for a From at example.com; strict requires an exact match. Section 5.1.2 places the obligation on the domain owner: the Domain Owner MUST send mail that has a DKIM Signing Domain that will produce a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain.

Why DKIM survives forwarding, and where mailing lists break it

A DKIM signature travels inside the message, so a forwarder that passes the message through unchanged leaves it verifiable regardless of which IP delivered it. SPF lacks that property, which is why a domain at DMARC reject typically relies on DKIM to carry forwarded mail through.

Mailing lists break the signature when they change signed content: a tag added to the Subject or a footer appended to the body alters something the signer hashed. RFC 6376 section 5.3.1 offers the l= body length tag to leave room for trailers, and section 8.2 then warns that l= lets a malicious intermediary append content that can replace the original in the reader's eyes, advising signers to be extremely wary of it.

ARC (Authenticated Received Chain, RFC 8617, July 2019, Experimental) is the IETF response to that breakage. Each intermediary records the authentication results it saw on arrival (ARC-Authentication-Results), signs the message as forwarded (ARC-Message-Signature) and seals the chain (ARC-Seal), so a final receiver can see that DKIM passed before the list modified the message and may, as local policy, trust that chain. RFC 9989 does not reference ARC.

Common DKIM mistakes that leave a domain unsigned or unaligned

DKIM misconfigurations tend to fail silently: mail keeps arriving, and the only symptom is a DKIM fail in a DMARC aggregate report or a scan.

• A key under 2048 bits. A 1024-bit key still verifies under RFC 8301, but signers SHOULD use 2048, and a checker or auditor may flag the shorter key.
• t=y left on in production. Verifiers treat the mail as unsigned until the flag is removed.
• A selector typo. The record is at s1._domainkey while the platform signs with s=selector1; every lookup returns nothing.
• The provider's default d=. The signature passes DKIM for the provider's domain and never aligns for DMARC. Publish the CNAME or bring-your-own-key record the provider offers.
• No rotation. A key that has signed for years and been copied between systems has unknown exposure.
• Publishing the private key. Only the public key belongs in DNS. A private key pasted into a TXT record lets anyone sign as the domain until it is revoked.
• A record split incorrectly. A 2048-bit p= truncated at 255 characters leaves a record that parses but does not decode.

For SOC 2 or ISO 27001 evidence, a valid 2048-bit key with no test flag speaks to SOC 2 CC6.1, CC6.7 and CC7.2 and ISO 27001:2022 A.5.14 and A.8.20; a weak or missing key is a gap against the same controls.

How to check and generate a DKIM record

A DKIM record can be checked by reading the TXT record at the selector name, and a purpose-built tool saves decoding the key by hand. The DKIM checker takes a domain and a selector, reads the record over DNS over HTTPS, follows one CNAME hop, confirms the key is a real RSA or Ed25519 key, measures its length, and flags an empty p=, keys under 2048 bits and the t=y flag. It sends no mail.

The DKIM record generator creates an RSA key pair in the browser and outputs the public TXT record; the private key stays on the device and is never transmitted, so it has to be copied into the signing system before the tab is closed. Once signing is live, the DMARC checker shows whether a record exists at _dmarc.<domain> and which policy it declares.

The free security tools hub collects the SPF, DKIM, DMARC and MX lookups, and the overview of how SPF, DKIM and DMARC work together covers the order a receiver applies them in. Once DMARC is enforced, the post on what BIMI is covers the logo display that follows.

Frequently asked questions about DKIM

What is a DKIM record?

A DKIM record is a DNS TXT record at <selector>._domainkey.<domain> that publishes the public key a receiver uses to verify a DKIM signature. RFC 6376 section 3.6.1 defines its tags, of which p=, the base64 key, is the one that must be present; an empty p= means the key is revoked.

What is a DKIM selector?

A DKIM selector is the label in front of _domainkey in the record's DNS name, carried in the s= tag of every signature. It lets one domain publish several keys at once, which is how two platforms sign for the same domain and how a key is rotated without downtime.

Does DKIM encrypt email?

No. DKIM signs a message; it does not encrypt it. The headers and body remain readable by anyone on the path; the signature only proves they have not changed since the d= domain signed them. Encryption in transit is TLS between mail servers, a separate control.

How long should a DKIM key be?

RFC 8301 section 3.2 requires RSA keys of at least 1024 bits and says signers SHOULD use at least 2048; verifiers must accept up to 4096. RFC 8301 makes 2048 bits the recommended size.

Does DKIM work without SPF?

Yes. DKIM verification depends only on the signature and the public key in DNS, and RFC 9989 section 5.3.5 passes DMARC on an aligned DKIM result alone. Domains typically publish SPF as well, so a sender whose signing breaks has a second identifier to fall back on.