What Is DKIM? Email Authentication Standard Explained
Summary
DKIM uses RSA public-key cryptography to stamp outbound email with a verifiable origin claim. Your sending server signs each message with a private key. The recipient MTA looks up your public key in DNS using the selector label, verifies the signature, and reports the result. DKIM does not block anything on its own: it produces a pass or fail signal that gates DMARC policy enforcement and feeds inbox providers' reputation scoring.
DKIM (DomainKeys Identified Mail) is a cryptographic email authentication protocol. What is DKIM in practical terms: it attaches an RSA signature to every outbound message your mail server sends. The receiving MTA retrieves your public key from DNS, verifies that signature, and reports the result as dkim=pass or dkim=fail. That result feeds your domain's reputation model and determines whether DMARC alignment holds. No valid signature means the receiving MTA has no cryptographic confirmation the message came from your infrastructure.
DKIM Is a Signing Protocol, Not a Filter
The name invites a common misconception. DKIM does not block email. It does not quarantine messages or enforce any policy on its own. What it does is stamp every outbound message with a verifiable claim: this message was signed by the domain in the d= field, using the private key corresponding to selector s=.
The receiving MTA takes that claim, constructs a DNS query to <selector>._domainkey.<domain>, retrieves the TXT record containing the public key, and runs the cryptographic verification. If verification passes, the authentication results header shows dkim=pass. If it fails, you see dkim=fail or dkim=temperror.
Neither outcome causes rejection by itself. The signal feeds the receiving server's reputation model and, critically, into DMARC evaluation. DKIM's job is to produce a verifiable result, not act on it.
What Gets Signed and What the Signature Covers
DKIM signs two things: selected message headers and the message body. The signing algorithm hashes both and stores the result in the DKIM-Signature header field.
The header list is controlled by the h= tag in the signature. A typical production setup includes from:subject:date:message-id:content-type. The from header is the field that matters for DMARC alignment. The body hash covers the complete message body, canonicalized via either simple or relaxed canonicalization.
Relaxed canonicalization is what most production stacks use. It normalizes whitespace before hashing, which allows the signature to survive minor reformatting by relay MTAs. Simple is stricter: a single trailing whitespace change breaks the signature. You will see c=relaxed/relaxed in the DKIM-Signature header of virtually every well-configured ESP.
What DKIM does not sign: the SMTP envelope sender, routing headers like Received, and any header outside the h= list. This is by design. Signing the envelope would break forwarding scenarios, which is where DKIM's advantage over SPF comes from.
The Selector: An Access Control Handle Most Teams Treat as a Label
The selector is the part of DKIM that most teams underestimate until they need to rotate keys under pressure.
The s= field in your DKIM-Signature points to a specific public key in your DNS. The lookup format is <selector>._domainkey.<yourdomain.com>. If your selector is mail2026 and your domain is example.com, the resolver looks for a TXT record at mail2026._domainkey.example.com.
One domain can have multiple selectors active simultaneously. Each sending service, each ESP, each internal MTA should use its own selector. This gives you three concrete operational capabilities:
Independent key rotation per service without touching other senders.
Traceable attribution in authentication logs: the selector tells you which signing key was used on any given message.
Clean offboarding: delete the selector's DNS record, and that ESP can no longer sign as your domain regardless of what they do on their end.
At the usage, voilà ce qu'on observe dans les traces: teams that configure a shared selector across all sending services cannot revoke access for one sender without disrupting all of them. The selector is not cosmetic. It is an access control handle.
DKIM and DMARC Alignment: How the Enforcement Layer Actually Works
DKIM passing is a prerequisite for a specific type of DMARC pass called DKIM alignment.
DMARC requires at least one of two alignment conditions: SPF alignment or DKIM alignment. DKIM alignment means the domain in the From: header matches the d= value in the DKIM signature, and the signature verifies. When both conditions hold, DMARC considers the message authenticated.
This is why DKIM is the more durable authentication signal. SPF alignment breaks on forwarding: when a message is forwarded, the SMTP envelope sender changes, and SPF evaluation fails against the new sending IP. DKIM alignment survives forwarding because the signature and the From: header travel with the message body and are not rewritten by relay MTAs, assuming the body is not modified in transit.
For domains with a p=reject DMARC policy, a message that fails both SPF and DKIM alignment is rejected at the receiving MTA. That is the mechanism that stops spoofed email from your domain reaching inboxes at scale. DKIM is not the last line of defense here. But it is the line that holds when forwarding is in the path.
Since 2024, Google, Yahoo, and Microsoft require DKIM for bulk senders sending 5,000 or more messages per day to their MX. Messages from unsigned domains are routed to spam or rejected by default.
Ce n'est pas une feature marketing. C'est une contrainte d'infrastructure.
Key Length and Rotation: Practical Decisions for 2026
Most DKIM implementations use RSA-SHA256. The key question is key length.
1024-bit RSA keys still appear in legacy configurations. NIST deprecated 1024-bit RSA for most use cases in 2015. A 2048-bit key provides significantly stronger margin and is supported by every major MTA and receiving provider. If you are generating a new key today, use 2048-bit.
Some teams have migrated their active signing key to 2048-bit but left old 1024-bit selectors published in DNS because no one audited the inventory. Trois signaux qui changent le comportement du moteur: if you see k=rsa with a 1024-bit key in an old selector, that selector is a liability even if your current signing infrastructure has already moved on. A valid but deprecated selector is exploitable.
Key rotation schedule: most infrastructure teams rotate annually, some quarterly for higher-sensitivity domains. The sequence matters:
Generate a new key pair.
Publish the new public key under a new selector name in DNS.
Wait for TTL propagation, typically 24 to 48 hours for records with a low TTL.
Switch the signing key on your MTA configuration to the new selector.
Verify DKIM pass on outbound messages via a mail testing tool or by inspecting authentication results headers on a test message.
After confirming the new key is live and signing correctly, delete the old DNS record.
The rotation is non-disruptive if you follow the order: DNS first, signing switch second, old record deletion last. Reversing steps 4 and 6 causes a dkim=fail window.
Operational Signals to Track After DKIM Setup
DKIM is not a one-time configuration task. The following signals indicate something drifted or broke.
dkim=temperror in received headers. Temporary failures usually indicate DNS lookup issues on the receiving side, or a TTL mismatch during key rotation. If you see this on outbound messages shortly after a key rotation, wait for full propagation before concluding the key itself is misconfigured.
dkim=fail on messages you sent. Body modification by an intermediate relay is the most common cause. Check whether a forwarding hop, a mailing list processor, or a footer-injecting relay is in the delivery path. If the failure is consistent on a single flow, map the relay chain hop by hop.
Missing DKIM-Signature header entirely. The signing daemon on your MTA is not running, the signing key path is wrong, or the domain selector mapping is misconfigured in your MTA config. This is a complete DKIM outage for affected message flows.
Selector TXT record absent from DNS. The DNS zone was edited or migrated without preserving the DKIM selector record. Verify with dig TXT <selector>._domainkey.<domain> from an external resolver.
On a multi-region sending setup, inconsistent DKIM results across nodes are frequently caused by different nodes using different selector configurations. Confirm the signing key configuration is synchronized across all sending nodes before deploying a rotation.
What DKIM Does Not Protect Against
DKIM is not a spam filter. A sender can register a new domain, configure valid DKIM, and send fully authenticated spam. The signature verifies cleanly. Authentication confirms origin, not intent or content quality.
DKIM also does not address display name spoofing, where the From: header shows a trusted name like "Payroll Team" paired with an attacker-controlled domain. The cryptographic verification operates on the domain, not the visual presentation in the MUA. Most phishing at the MUA level relies on display name deception rather than exact-domain spoofing.
What DKIM does protect against: exact-domain spoofing, where an attacker attempts to send as your domain without possessing your private key. Combined with a DMARC p=reject policy enforcing DKIM alignment, this prevents that class of spoofed message from reaching inboxes at the receiving providers that enforce DMARC.
On a practical note: DKIM alone is not enough. The protection model requires DMARC policy enforcement at the receiving MTA. DKIM is the authentication layer that makes DMARC meaningful. SPF is the other authentication layer, and it handles envelope-sender verification. All three work together. The absence of any one of them leaves a gap in the enforcement chain.
If you have already set up DKIM and SPF but have not yet published a DMARC record, the signatures exist but no enforcement policy is active. Monitoring mode (p=none with rua reporting) is a reasonable first step: you get aggregate reports showing authentication pass rates across your sending domain before committing to p=quarantine or p=reject.