# What Is DKIM? Email Authentication Standard Explained URL: https://notificationharbor.com/journal/what-is-dkim Type: blog Locale: en Published: 2026-09-08 Updated: 2026-09-09 --- > DKIM adds an RSA cryptographic signature to every outbound email. The receiving MTA verifies it against your DNS-published public key before deciding where the message lands. 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 `._domainkey.`, 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. ![Two digital envelopes secured with padlock representing DKIM signed email in transit](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/95ba5d-img-2.webp) ## 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 `._domainkey.`. 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. ![Terminal screen showing DNS TXT records for DKIM selector configuration](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/02b314-img-3.webp) ## 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](https://support.google.com/mail/answer/81126) 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](https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final). 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 ._domainkey.` 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`. ## FAQ ### What is DKIM and how does it work? DKIM (DomainKeys Identified Mail) is a cryptographic email authentication protocol. Your sending server signs each outbound message with a private RSA key and attaches the signature to a DKIM-Signature header. The receiving MTA queries your DNS for the corresponding public key under the selector subdomain, verifies the signature, and reports dkim=pass or dkim=fail. That result feeds inbox reputation scoring and DMARC alignment evaluation. ### What does DKIM protect against? DKIM protects against exact-domain spoofing: an attacker claiming to send from your domain without access to your private signing key. Combined with a DMARC p=reject policy and DKIM alignment, it prevents that class of spoofed message from reaching inboxes. It does not protect against display name spoofing, spam from legitimately authenticated domains, or content-based phishing where the attacker controls their own valid domain. ### What is a DKIM selector and why does it matter? A DKIM selector is a label in the DKIM-Signature header (the s= field) that tells the receiving MTA which public key to look up in DNS. The DNS query format is selector._domainkey.yourdomain.com. Multiple selectors can coexist on a single domain, each pointing to a different public key. This allows independent key rotation per sending service and clean revocation: delete the selector's DNS record and that sender can no longer sign as your domain. ### How often should DKIM keys be rotated? Most production teams rotate DKIM keys annually. The safe sequence is: publish the new public key under a new selector in DNS, wait for TTL propagation (24 to 48 hours), switch the signing key on your MTA to the new selector, verify dkim=pass on outbound test messages, then delete the old DNS record. Deleting the old record before the new key is confirmed live causes a dkim=fail window. ### Does DKIM survive email forwarding? Yes, unlike SPF. When a message is forwarded, the SMTP envelope sender changes and SPF alignment fails against the new sending IP. DKIM alignment survives forwarding because the signature travels with the message headers and body and is not rewritten by relay MTAs, as long as the message body is not modified in transit. This makes DKIM the more reliable authentication signal for DMARC policy enforcement across forwarded mail. ### What DKIM key length should be used in 2026? Use 2048-bit RSA keys. NIST deprecated 1024-bit RSA for most use cases in 2015, and 1024-bit keys present a calculable risk at current compute costs. All major MTAs and receiving providers support 2048-bit keys. If you have legacy 1024-bit selectors still published in DNS, audit them: a valid but deprecated selector is a security exposure even if your current signing infrastructure has already moved to longer keys. ### What is the difference between DKIM, SPF, and DMARC? SPF authenticates the SMTP envelope sender domain by checking whether the sending IP is listed in that domain's DNS as authorized. DKIM authenticates the message itself via a cryptographic signature on headers and body. DMARC uses SPF and DKIM alignment results to enforce a domain-owner policy: none, quarantine, or reject. SPF fails on forwarding; DKIM typically survives it. DMARC requires at least one alignment to pass before applying its policy.