What Is DKIM?
DKIM (DomainKeys Identified Mail) is an email authentication method that lets a domain owner take responsibility for a message by attaching a cryptographic signature, which receiving mail servers verify against a public key published in the domain's DNS. Standardized as Internet Standard STD 76 in RFC 6376 (opens in new tab), it proves two things: the signing domain authorized the message, and its signed content was not altered in transit. DKIM authenticates the sending domain only. It does not encrypt the message, and it does not vouch for the visible sender a person actually reads, which is the job DMARC (opens in new tab) layers on top.
How DKIM works
The sending server signs each outbound message (opens in new tab) before it leaves. It selects a private key and a matching selector, then runs the message through a canonicalization step so minor transport changes do not break verification. It computes SHA-256 hashes (opens in new tab) of the body and a chosen set of headers, then signs the result with an RSA or Ed25519 (opens in new tab) private key.
The signature travels in a DKIM-Signature header whose tags carry the signature (b=), the body hash (bh=), the signing domain (d=), the selector (s=), and the list of signed headers (h=); the From header must appear in that list. The receiving server reads the selector and domain, queries DNS for a TXT record at <selector>._domainkey.<domain>, retrieves the public key, recomputes the hashes, and validates the signature.
The server records the verdict in an Authentication-Results header:
Authentication-Results: mx.google.com;
dkim=pass header.d=example.com header.s=s202603DMARC then checks alignment (opens in new tab) between the d= domain and the visible From domain. Because the signature travels inside the message and does not depend on the sending IP, a forwarded message with unmodified content still passes DKIM (opens in new tab), even though the same forwarding breaks SPF: the forwarder's IP is not in the original sender's SPF record.
Why DKIM matters
Bulk senders now authenticate or land in spam. Google requires high-volume Gmail senders to set up SPF and DKIM and to publish DMARC under its sender guidelines (opens in new tab), and Yahoo (opens in new tab) asks bulk senders for the same three. Consumer mail to Outlook.com, Hotmail, and Live.com faces substantially similar requirements (opens in new tab), with non-compliant mail routed to Junk. For a bulk sender today, missing DKIM means rejected or junk-filed mail.
Passing DKIM is not the same as protecting your brand. An attacker can attach a fully valid signature from a domain they control; that signature is cryptographically sound and says nothing about the name shown in the inbox. This is why the d= domain must align with the visible From domain under DMARC (opens in new tab). Because an aligned DKIM signature also survives forwarding, it is the more resilient route to a DMARC pass in the indirect mail flows where SPF tends to fail.
What DKIM does not protect against
DKIM authenticates the signing domain, not the identity a person reads in the From field. NIST frames the gap as the difference between who signed a message and who claims to have written it (opens in new tab). Several impersonation techniques live in that gap:
- Lookalike domains. DMARC treats visually similar domains as out of scope (opens in new tab). An attacker who registers exampl3.com can sign mail with a fully valid DKIM key for that domain and pass SPF, DKIM, and DMARC for it.
- Display-name spoofing. SPF and DKIM authenticate technical identifiers (opens in new tab), not the display name a recipient actually reads. An attacker can show a trusted brand in the From display name while sending from a domain that passes every check.
- DKIM replay attacks. An attacker captures a legitimately signed message and reposts it to new recipients (opens in new tab). Because the content is unchanged, the signature still validates, so the mail rides on the original signer's reputation.
- Compromised legitimate accounts. In business email compromise, the attacker takes over a legitimate account (opens in new tab) through social engineering or intrusion, then sends from its own authorized infrastructure, so DKIM, SPF, and DMARC all pass.
How to implement DKIM
Sign with rsa-sha256 and a strong key. RFC 8301 (opens in new tab) bars the older rsa-sha1, sets a 1024-bit floor, and recommends at least 2048 bits. Weak keys are not hypothetical: in 2012 a researcher factored Google's 512-bit DKIM key on rented cloud compute and used it to send a proof-of-concept message spoofed as one company founder to another. The underlying weakness (opens in new tab) reached any domain still signing with short keys.
RFC 8463 (opens in new tab) adds Ed25519 as a second signing algorithm and recommends dual-signing with RSA so verifiers that do not yet support it can still validate. From there, a few operational practices keep signatures trustworthy:
- Rotate keys on a schedule using the M3AAWG baseline (opens in new tab): publish a new public key under a fresh selector, switch the MTA to the new private key, and keep the old DNS record live long enough for in-flight mail before you revoke it (opens in new tab).
- Oversign sensitive headers such as From, To, and Subject so an attacker cannot append duplicates without breaking the signature.
- Skip the l= body-length tag, which leaves appended content outside the signature; RFC 6376 (opens in new tab)'s Security Considerations flag the risk.
- Give third-party senders distinct DKIM keys (opens in new tab) per customer, the recommended practice for ESPs.
- Start DMARC at p=none to monitor (opens in new tab), then move to p=quarantine and p=reject.
How Doppel helps
DKIM stops at the domain in the signature. The lookalike domains and replay infrastructure that route around it sit outside any authentication check. Doppel is the AI-native Social Engineering Defense (SED) platform that unifies Digital Risk Protection (DRP) and Human Risk Management (HRM), and it goes after that infrastructure directly. The Doppel Threat Graph correlates spoofed domains, fake profiles, scam ads, and malicious messaging into multi-channel campaigns, so a technically valid signature from an attacker-controlled domain is judged by the infrastructure behind it, not the signature alone.
Brand Protection then dismantles the lookalike domains and sending infrastructure behind mail that clears SPF, DKIM, and DMARC, with agentic AI mapping the registrations, hosting, and relays and driving the takedowns while analysts handle the novel or ambiguous cases.
A guided demo traces an authenticated-looking email back to the campaign behind it and shows how the platform makes your brand too costly to attack. Request a demo to get started.
Frequently asked questions about DKIM
What is DKIM in cybersecurity?
DKIM (DomainKeys Identified Mail) is the RFC 6376 email authentication standard that attaches a cryptographic signature to outgoing messages. The receiving server retrieves the sending domain's public key from DNS and verifies the signature, which confirms that the domain authorized the message and that its signed content was not altered in transit. DKIM does not encrypt the message (opens in new tab); it computes a SHA-256 hash of selected headers and the body and signs that hash with an RSA or Ed25519 private key.
What is the difference between DKIM, SPF, and DMARC?
SPF (Sender Policy Framework, RFC 7208 (opens in new tab)) checks whether the sending server's IP is authorized in a record the domain owner publishes in DNS; it validates the envelope sender, and forwarding breaks it. DKIM (RFC 6376) uses a cryptographic signature to confirm a domain's responsibility for a message and survives forwarding when the content is unchanged. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer, standardized in RFC 9989 (opens in new tab), that ties both to the visible From address: it requires the SPF domain or the DKIM signing domain to align with the From domain and tells receivers what to do when neither does. A message passes DMARC (opens in new tab) if either SPF or DKIM passes with alignment.
Does DKIM prevent email spoofing?
By itself, DKIM authenticates the domain in the signature's d= tag. Paired with a DMARC policy at enforcement, it blocks exact-domain spoofing (opens in new tab), because DMARC requires the signing domain to align with the visible From domain. It does not stop lookalike domains (opens in new tab), display-name abuse (opens in new tab) from a domain the attacker legitimately controls, or mail from compromised legitimate accounts (opens in new tab), all of which can still produce authentication results that check out.
What is an example of a DKIM attack?
A DKIM replay attack occurs when an attacker captures a legitimately signed message and reposts it to additional recipients (opens in new tab) while preserving the original signature. Because the signed headers and body remain unchanged, the signature still validates, so the message inherits the original signer's reputation without authorization for those new recipients. Receivers have to distinguish the replay from legitimate forwarding, which produces the same valid signature.