DKIM was designed in 2007 to solve a specific problem: prove that a message was actually sent by the domain in the From header, and prove that the body has not been tampered with in transit. It does both jobs well. What it was never designed to prevent is a much subtler attack that has exploded in 2024 and 2025: signature replay.
A DKIM replay attack does not break DKIM. The signature is genuinely valid. The cryptography works exactly as intended. The attacker simply takes a real message, signed by a real reputable sender, and re-sends it to millions of new recipients. Every one of those messages passes DKIM, passes DMARC, and arrives in the inbox with the full weight of the original sender's reputation behind it.
This guide explains exactly how DKIM replay works, why the protocol allows it, what major mailbox providers are doing about it, and what senders can do to reduce the value of their signatures to attackers.
- A DKIM replay attack reuses a legitimate, validly signed message from a reputable sender and delivers it to entirely different recipients. The signature still validates because DKIM does not bind a message to its envelope recipients.
- Attackers typically obtain the seed message through normal means: signing up for a newsletter, transactional account, or freemium service, and capturing the signed message they receive.
- Major mailbox providers including Google have publicly identified DKIM replay as a top abuse vector for laundering spam through reputable domains, especially large platforms with permissive signup processes.
- Defensive measures include short DKIM key TTLs, frequent key rotation, signing the X-Original-Recipient or similar binding headers, and adding message expiry. None of these completely solve the problem.
- The IETF DKIM2 working group is actively developing a successor protocol with explicit replay resistance, but adoption is years away. Practical defense in 2026 relies on hardening the existing protocol.
How DKIM Replay Works
The attack has three steps, and none of them break the DKIM specification.
Step 1: Obtain a signed message from a high-reputation sender
The attacker signs up for an account at a reputable platform: a major social network, a financial newsletter, a SaaS trial, or any service that sends authenticated transactional or marketing email. The attacker receives a real, validly DKIM-signed message in their own inbox. They save the complete raw message including all headers and the DKIM signature.
The original message body is essentially irrelevant. The attacker is shopping for a signature, not content. They want a signature from a domain with strong reputation at Gmail, Outlook, Yahoo, and other major providers.
Step 2: Re-inject the message to new recipients
The attacker uses their own SMTP infrastructure to deliver the saved message to a completely different set of recipients. The envelope (SMTP MAIL FROM and RCPT TO) can be anything; the attacker controls those fields directly. The message data, including the DKIM signature, is unchanged.
When the receiving mailbox provider validates the DKIM signature, it works. The signature was computed over the message body and a specific set of headers that the attacker has preserved exactly. The signing domain has not revoked the key. The signature matches. DKIM passes.
Step 3: Inherit the reputation
Because DKIM passes and the From domain has a strong sender reputation, the message is treated as trustworthy. DMARC passes because DKIM aligns with the From domain. The message lands in the inbox of millions of recipients who never signed up for anything from the reputable sender.
The reputable sender did not authorize this. Their authentication infrastructure is technically working correctly. But their reputation has just been used to deliver spam.
Why the Protocol Allows This
DKIM was designed to answer two questions: did this domain authorize the message, and has the message been modified in transit. Neither question requires knowing who the original recipients were. In fact, DKIM was specifically designed to survive legitimate forwarding, where a message is delivered to a mailing list and then re-delivered to many list members.
The signature is computed over the message body (or a portion of it, depending on the canonicalization algorithm) and a list of selected headers. The list of headers signed is declared in the signature itself via the h= tag. Critically, the envelope-level recipient information is not part of any signed header. The To: header can be signed, but it is independent from the actual SMTP RCPT TO list.
This is by design. If DKIM bound a message to a specific recipient list, every legitimate forwarding scenario would break, defeating one of the protocol's key goals.
The result is that a validly DKIM signed message is, from a cryptographic standpoint, fungible. It belongs to whoever has a copy of it.
Real-World Patterns
Public discussion of DKIM replay has accelerated since 2023. Several patterns are now well documented in anti-abuse research from Google, Yahoo, and Microsoft.
The "free transactional" pattern
Attackers sign up for services that send transactional email with high-reputation signatures. Confirmation emails, password reset emails, and welcome messages are particularly valuable because they often contain minimal personalization, making them easier to send to arbitrary recipients without looking obviously wrong.
The "newsletter signup" pattern
Attackers subscribe to newsletters from high-reputation publishers, then replay the signed newsletter content to spam targets. The content may not be obviously spam, but the attacker uses the trusted delivery channel to slip links or attachments into recipients' inboxes.
The "boilerplate marketing" pattern
Generic marketing emails from large brands with weak personalization make ideal replay candidates. An offer email or product announcement signed by a Fortune 500 domain can be replayed widely with the original content intact, leveraging brand trust to drive click-throughs that the attacker monetizes through traffic redirection.
Critical: If your platform offers free or freemium signup that triggers authenticated transactional email, you are a target. The combination of low signup friction, strong domain reputation, and predictable signed messages is exactly what replay attackers shop for.
How Mailbox Providers Are Responding
Detection of replay at the receiving side is hard because the signature is genuinely valid. Mailbox providers have developed several heuristics:
Volume anomaly detection
If a domain typically sends 50,000 messages per hour and Gmail suddenly receives 50 million signed messages from that domain in an hour, the volume spike is a strong replay signal. Modern filters compare incoming volume against the historical sending pattern for the signing domain.
Recipient diversity analysis
Legitimate signed messages from a transactional source go to a known recipient base. Replayed messages go to random or scraped lists with no relationship to the signing platform. Gmail and Microsoft both reportedly use recipient-graph analysis to flag this.
Source IP correlation
Legitimate signed messages come from the signing domain's known sending infrastructure (its IP ranges or ESP IPs). Replayed messages come from arbitrary attacker-controlled IPs. When DKIM passes but the source IP has no historical relationship with the signing domain, that mismatch is a strong signal.
This is one reason SPF still matters even though DMARC can authenticate via DKIM alone: SPF binds the message to the sending IP, which catches the replay scenario that DKIM does not.
DMARC alignment plus envelope analysis
Providers have begun examining the envelope return-path domain in conjunction with DKIM alignment. A signed message arriving from an envelope domain that does not match the signing platform's usual return-path infrastructure is flagged for additional scrutiny even if it passes DMARC.
Defenses Senders Can Deploy
If you are a high-reputation sender being used as a replay source, the goal is to reduce the value of your signatures to attackers. Several practical measures help.
Short DKIM key lifetimes and frequent rotation
A captured signature is only valuable as long as the corresponding DKIM key remains published in DNS. Aggressive DKIM key rotation, every 30 days or shorter, limits the window during which a stolen signature can be replayed. The existing DKIM key rotation guide covers the operational details of frequent rotation without breaking delivery.
Sign the Date header tightly
The Date header is signed by default in most ESP configurations. Mailbox providers can compare the Date in the signed message to the current time at delivery. A six-month-old Date header on an arriving message is a strong replay signal. Some providers reject signed messages older than 7 days regardless of signature validity.
Add a Message-Expires header
The proposed Message-Expires (or x-anthropic-expires style) header lets senders declare an expiration time. Including this in the signed header list creates a hard deadline beyond which the message is meant to be discarded. Adoption is uneven, but Gmail honors several variants of this.
Minimize signed transactional content
If a transactional email has only one or two interchangeable variants, replay attackers can capture one and replay it indefinitely. Adding small recipient-specific personalization to the message body, even just an account ID or a hashed value tied to the user, breaks the perfect replayability. The signature still validates, but the body now contains a fingerprint that mailbox providers can flag when it appears at multiple unrelated recipients.
Rate limiting at signup
If your platform offers free signup that triggers signed transactional email, rate limiting and bot detection at signup directly reduces the number of seed messages attackers can harvest. CAPTCHAs, phone verification, and email verification before signup completion all raise the cost of the harvesting step.
Audit your transactional emails for "replay value." If the same exact bytes can be sent to any recipient without looking wrong, you are a high-value replay target. Adding even minimal per-recipient content (account ID, timestamp, hashed identifier) inside the signed body breaks perfect replayability without breaking legitimate forwarding.
The DKIM2 Future
The IETF DKIM2 working group, active since 2024, is developing a successor specification that addresses replay explicitly. The proposed changes include mandatory message expiration, sender-supplied replay-protection tokens, and explicit binding of the signature to the envelope MAIL FROM domain.
DKIM2 is still in draft, with no major mailbox provider currently enforcing it. Realistic deployment timelines are 2027-2029 for any meaningful coverage, with full ecosystem adoption taking longer. Senders cannot rely on DKIM2 to solve the problem in the near term.
In the interim, the existing protocol is what we have, and the practical defenses listed above are the available tools.
What Receivers Should Do
If you operate a mailbox infrastructure (corporate mail server, mail forwarder, or anti-abuse pipeline), you can add replay detection beyond the basic DKIM validation:
- Check the Date header. Reject or quarantine signed messages older than 7 days.
- Compare the source IP to the signing domain's known infrastructure. Mismatches deserve scrutiny.
- Track message Body-Hash values. The same Body-Hash arriving from multiple unrelated sources is a strong replay signal.
- Use feedback loop data to identify domains being heavily replayed and increase scrutiny on incoming signed mail from those domains.
Reporting Replay Abuse
If you suspect your domain is being used in a replay attack:
- Pull your DMARC aggregate reports and look for sources sending high volume that do not match your known infrastructure.
- Rotate your DKIM keys immediately and consider shortening your rotation cadence going forward.
- Submit reports to Google ({admin}sender-support) and Microsoft (the SNDS team) describing the abuse pattern.
- If you can identify a specific harvested message, share the message hash and signature with the receiving provider. This helps them tune detection.
- Review signup friction on any free or freemium services you operate, looking for harvesting patterns in recent account creation logs.
Google publicly stated in 2024 that DKIM replay had become one of the top sources of inbox-delivered spam at Gmail, surpassing several traditional spam vectors. The attack's appeal to spammers is exactly that it exploits the trust infrastructure rather than fighting against it.
Frequently Asked Questions
A DKIM replay attack is the reuse of a legitimately DKIM-signed message to deliver mail to completely different recipients than the original sender intended. Because the signature is genuinely valid, the message passes authentication checks and inherits the reputation of the signing domain. The attacker does not break the cryptography; they exploit the fact that DKIM does not bind a message to its recipients.
No. DMARC validates that DKIM signatures align with the From domain. In a replay attack the original signature is valid and aligned, so DMARC passes. Defending against replay requires detection mechanisms outside the SPF/DKIM/DMARC stack, including volume analysis, source-IP correlation, and message expiration enforcement.
Watch DMARC aggregate reports for high-volume sources outside your sending infrastructure that pass DKIM but do not match your known IP ranges. Sudden spam complaint spikes from recipients you never emailed, or reputation drops at Google Postmaster Tools without a corresponding change in your sending behavior, are also warning signs of replay abuse.
For high-volume senders or platforms that send authenticated transactional email to free signups, rotation every 30 days or less meaningfully limits replay value. A rotated key remains in DNS for a short overlap window, then is removed, invalidating any captured signatures that used it. The shorter the rotation cycle, the smaller the replay window.
DKIM2 is designed to address replay explicitly through mandatory message expiration and explicit envelope binding. However, the specification is still in IETF draft as of 2026, and realistic ecosystem adoption is 3 to 5 years away. Senders should rely on existing defenses (short key rotation, message expiry headers, recipient-specific content) in the meantime.