DKIM Replay Attacks: Why a Valid DKIM Signature Isn't Proof of Anything

A DKIM replay attack is when a spammer obtains one legitimately DKIM-signed message from your domain and re-sends it, unchanged, to thousands of new recipients. Because the message body and signed headers are untouched, the DKIM signature still verifies — the spam arrives cryptographically "authenticated" as your domain, and your reputation pays for it.

This is the uncomfortable truth about DKIM (DomainKeys Identified Mail): it proves a message passed through a server holding your private key, exactly once, at some point. It says nothing about who the current recipient is, when the message was sent relative to now, or whether this delivery was ever authorized. Understanding that gap — and what providers and senders do about it — matters if you run a domain with any reputation worth borrowing.

How does a DKIM replay attack actually work?

The mechanics are depressingly simple. No crypto is broken. No keys are stolen. The attacker exploits what DKIM is designed to do: let anyone verify a signature with a public key from DNS.

1. Acquire a signed message. The attacker signs up for your newsletter, triggers a transactional email, or gets one of your messages through a compromised mailbox. Every message leaving your infrastructure carries a valid DKIM signature. That's the raw material.
2. Choose a payload. Ideally a message with broad appeal or a credible lure. A legitimate marketing email from a trusted brand, resent verbatim, is a phishing or spam vehicle with a perfect authentication wrapper. Some attackers get cleverer: they craft the original message themselves by signing up with content they control (think "your order confirmation for: <attacker's spam text>").
3. Re-inject at scale. The attacker connects to receiving mail servers and sends the captured message — byte-for-byte identical signed portions — to huge recipient lists. Envelope sender, envelope recipient, and connecting IP are all the attacker's. None of that is covered by the signature.
4. Verification passes. The receiver hashes the body, checks the signed headers, fetches your public key from DNS, and the math checks out. dkim=pass, aligned with your From domain. DMARC passes too, if SPF doesn't align (it usually won't for the attacker's envelope, but DKIM alone is enough for DMARC).

The result: spam waves that pass every authentication check, "from" a domain with a clean reputation. Receivers see authenticated mail from you, recipients report it as spam, and complaint rates attach to your domain.

Why doesn't the signature catch this?

Because DKIM binds to the message, not the delivery. Here's the annotated anatomy of what a signature does and doesn't cover:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
  c=relaxed/relaxed; q=dns/txt;
  h=from:to:subject:date:mime-version:content-type;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=K3vZ...signature over the headers above + body hash...
From: "Acme Deals" <[email protected]>        ← SIGNED: can't be altered
To: [email protected]              ← SIGNED: but attacker can strip/replace if not in h=
Subject: Your weekly deals                     ← SIGNED
Date: Mon, 03 Aug 2026 09:14:22 +0000          ← SIGNED: but nothing enforces freshness

What verifies: the From header, the body, the Subject, the Date — whatever's listed in h=, plus the body hash bh=.

What's spoofed or irrelevant in a replay:

• The envelope. MAIL FROM and RCPT TO at the SMTP level are never signed. The attacker addresses the replay to anyone.
• The recipient. Even though To: is in the signed headers here, DKIM doesn't require the envelope recipient to match it. And if the original sender omitted to from h=, the attacker can rewrite the visible To header entirely.
• The timestamp. The Date: header and the signature's t= tag (signature creation time) are verified as authentic, not as recent. A signature from three weeks ago verifies just as happily as one from three seconds ago. There's an optional x= expiration tag, but almost nobody sets it, and receivers mostly ignore it.
• The path. DKIM has no opinion about which server is delivering the message. That's SPF's job, and SPF fails for the attacker's IP — but DKIM passing is sufficient for DMARC, so the message still looks fully authenticated.

DKIM was designed to give a domain accountability for a message's content. It does that job. The mistake is reading dkim=pass as "this delivery is legitimate." It means "this content is unaltered from when the domain signed it." Those are very different claims, and the replay attack lives entirely in the difference. This is also why reading email headers properly means checking the whole authentication chain — Received hops, envelope paths, and signature timestamps — not just the DKIM verdict.

What does a replay wave look like from the sender's side?

If you're the domain being replayed, the symptoms are distinctive:

• Complaint spikes with no corresponding campaign. Your ESP dashboard shows flat sending, but Google Postmaster Tools shows spam-rate spikes and reputation drops. This mismatch is the fingerprint.
• Bounce and complaint reports for recipients you never mailed. Feedback loop complaints arrive for addresses nowhere in your list, all carrying the same Message-ID and content.
• DMARC aggregate reports showing your DKIM domain passing from unfamiliar IPs. Your rua XML shows source IPs you've never used, sending volume, with dkim=pass and dmarc=pass. That's replayed mail, authenticated as you. This is one of the strongest arguments for actually reading your DMARC aggregate reports weekly instead of filing them.
• Sharp reputation decay at Gmail. Because the replayed mail passes authentication, Gmail's domain reputation takes the hit directly — and since Yahoo's April 2025 shift to domain-reputation-first scoring, the same applies there.

How do mailbox providers mitigate replay?

Providers have known about replay for years and layer defenses on top of DKIM rather than trusting it alone:

Per-signature reputation and fingerprinting. Gmail computes fingerprints over signed content and tracks how many distinct recipients a given signature/content pair targets. One signature suddenly addressed to millions of unrelated recipients is an anomaly, and the message gets spam-foldered regardless of the valid signature. The signature vouches for content; Google's behavioral layer judges the delivery pattern.

Reputation overrides. If a domain's mail is being replayed and complained about, providers can downgrade or disregard the positive signal from DKIM for suspicious delivery patterns while preserving it for normal traffic. Authentication is one input to the filtering decision, never the whole decision.

Envelope and recipient analysis. Since the replayed envelope differs from anything the domain would legitimately produce, providers correlate envelope senders, HELO identities, and connection patterns against the domain's history.

This is why replay attacks are damaging but usually self-limiting: the wave gets absorbed after the first burst of complaints trains the filters. The cost lands on the victim domain's reputation during the absorption window — days of degraded inbox placement, which for a sender is exactly the kind of sudden spam placement that's miserable to diagnose if you don't know replay exists. The asymmetry is worth internalizing: the attacker spends nothing beyond one signup, and you spend weeks rebuilding domain reputation. That asymmetry is why the mitigation section below is about speed of detection, not prevention — you cannot win the prevention game, only the response-time game.

Where does ARC fit?

ARC (Authenticated Received Chain, RFC 8617) solves a different but related problem: what happens when a legitimately signed message passes through an intermediary — a mailing list, a forwarder, a university alumni alias — that modifies it and breaks the original signature.

Without ARC, forwarding breaks DKIM (modified body, added headers), and the receiver has no way to know the message was authenticated upstream. With ARC, each intermediary that verifies authentication adds a sealed header set:

ARC-Authentication-Results: i=2; mx.forwarder.net; dkim=pass ...
ARC-Message-Signature: i=2; a=rsa-sha256; d=forwarder.net; s=arc; ...
ARC-Seal: i=2; a=rsa-sha256; d=forwarder.net; s=arc; cv=pass; ...

The final receiver can evaluate the chain: "forwarder.net (which I trust) says it saw dkim=pass from example.com at hop 1." ARC vouches for what the intermediary observed, not for the message's legitimacy — and receivers only honor ARC chains from intermediaries they trust.

The connection to replay: ARC makes forwarding survivable, which reduces pressure to weaken DKIM verification for forwarded mail. But ARC doesn't stop replay — a replayed message typically has no ARC chain at all, or a chain from an untrusted sealer. If anything, ARC helps receivers distinguish legitimate redistribution (trusted ARC chain) from replay (no chain, anomalous pattern).

What can senders actually do?

You can't prevent replay — the signed message is public by design. You can shrink the blast radius:

1. Oversign headers. Sign headers beyond the minimum, and sign some headers that don't exist yet to prevent them being added on replay. Common practice: include to, cc, reply-to, message-id, and list-unsubscribe in h=, and add empty instances of headers you want frozen. An oversigned h= list might read:

h=from:to:subject:date:message-id:mime-version:content-type:list-unsubscribe:list-unsubscribe-post:to;

(The repeated to is intentional: it means "the To header is signed, and no second To header may exist.") Oversigning narrows what an attacker can modify, though it can't stop the core verbatim replay.

2. Set the signature expiration tag `x=`. x= gives a signature a hard expiry timestamp. Receiver support is inconsistent, so treat it as a bonus signal, not a control — but it costs nothing.

3. Rotate keys aggressively. Short key lifetimes don't stop a replay, but they bound it: once you rotate and retire the old selector, signatures made under it become conspicuous — and you can even revoke the old key (p= empty) to fail verification outright. This is where replay defense feeds directly into DKIM key rotation discipline: 6–12 month rotation is hygiene, but in an active replay incident, immediate rotation plus old-key revocation is the kill switch.

4. Monitor for the fingerprint. Watch complaint rates against send volume, watch feedback loops for unknown recipients, and watch DMARC rua reports for your d= passing from foreign IPs. The earlier you spot the wave, the earlier you rotate and the shorter the reputation damage. WillItInbox's DMARC monitoring surfaces exactly this — authentication results by source IP with drift alerts — so a replay wave shows up as an anomaly, not a mystery.

5. Verify your own signatures regularly. Part of replay defense is knowing your baseline. Run your domains and selectors through the free DKIM checker so you know every key that's valid in the wild; an attacker replaying under a selector you forgot existed is the worst version of this attack.

6. Analyze suspicious inbound headers. When users report odd mail "from" you, pull the full headers and compare: which selector signed it, what's the t= timestamp versus the Received chain, where did it actually originate. The header analyzer parses this in seconds and shows you exactly which claims verify and which don't.