DKIM Signatures Don't Expire — and That's the Replay Attack Problem

DKIM signatures survive the journey from sender to recipient in most cases — but the act of forwarding an email, adding a footer, or passing through a mailing list rewrites the message in ways that invalidate the signature, and the receiving server has no way to distinguish "legitimate modification" from "malicious tampering"

The previous articles on this site covered DKIM basics, key rotation, the complete email authentication audit, ARC and mailing lists, and key length/algorithm. This article addresses DKIM replay attacks — a specific attack pattern where a valid DKIM signature is reused to make a malicious email appear legitimate, and the countermeasures that limit (but don't eliminate) this risk.

How DKIM replay attacks work

DKIM signs a specific message — specific headers, specific body content — and the signature is tied to that content. Anyone can read DKIM signatures (they're not secret; the public key is in DNS for anyone to query). And anyone who receives a legitimately DKIM-signed email has received a signed message they could, in principle, retransmit.

A DKIM replay attack: an attacker receives (or observes in transit) a legitimately signed email from [email protected]. They then forward that exact email — unmodified, with the original DKIM signature intact — to other recipients. Because the message content and headers haven't changed, the DKIM signature still verifies correctly. The receiving server sees a valid DKIM signature from example.com — which appears to be an endorsement from example.com's email infrastructure.

The attack's appeal: it doesn't require compromising example.com's private key or any of their servers. It exploits the fact that a valid signature stays valid indefinitely unless the message is modified.

Why DKIM alone doesn't prevent replay

DKIM was designed to protect message integrity in transit — to detect if a message was modified between sending and receiving. It was not designed to prevent the replay of an unmodified message, because "the original sender's content" is structurally indistinguishable from "a copy of the original sender's content."

What's absent from the DKIM specification that would prevent replay:

• Nonce or one-time token: a mechanism that would make each signed message valid for exactly one delivery (like a single-use auth token)
• Recipient binding: a mechanism that would tie the signature to a specific recipient, making it invalid when delivered to different addresses
• Timestamp expiry: a short validity window after which the signature expires

DKIM does support an x= (signature expiry) tag — a Unix timestamp after which the signature should be considered invalid. In practice, this is rarely implemented because: (a) it requires the signing infrastructure to set a specific future time for each message, (b) clock skew between mail servers creates delivery failures near expiry, and (c) legitimate message delivery itself can be delayed hours or days (into spam queues, retry queues), making short expiry windows problematic.

What DMARC adds to limit replay utility

DMARC's alignment requirement means a DKIM-signed message only satisfies DMARC if the d= domain in the DKIM signature aligns with the From: header domain. A DKIM replay attack using a signed message from [email protected] sent to new recipients would still show From: [email protected] — DMARC would still pass, because both the signature and the From header are legitimately from example.com.

However, DMARC aggregate reports (rua=) provide visibility that makes replay patterns detectable. If example.com's DMARC reporting shows messages authenticated by their DKIM signature being delivered to addresses example.com never actually emailed, this anomaly appears in the aggregate report. The volume of such anomalous deliveries compared to the sender's legitimate sending volume is a signal.

The limited scenarios where replay attacks are practically useful

Replay attacks require the attacker to have received (or intercepted) a legitimately signed message — which limits their practical applicability:

Limited to the original message's content: you can replay a signed "Your order has shipped" notification to different victims — they see a legitimately signed shipping notification. But the attacker can't change the content (which would invalidate the signature). The attack can create misleading legitimacy for the specific content of the original message.

Spam amplification: an attacker who receives a single legitimate marketing email might replay it to millions of addresses, using the legitimate DKIM signature to improve deliverability. This is the most practical real-world use case.

Phishing amplification: if a legitimate email contains a link, replaying it to different victims sends them a legitimately-signed email pointing to the original link — potentially useful if the original link is to a site the attacker controls or has compromised.

Countermeasures available to senders

Message-ID uniqueness: including a unique Message-ID header in every sent message is standard and required by email specifications. While not in the DKIM-signed header set by default, including Message-ID in the signed headers limits replay (the same Message-ID delivered multiple times can be detected as duplicate delivery by some systems).

Short signature expiry (x= tag): accepting the delivery-delay trade-off and setting a 24-48 hour expiry catches replays attempted after the expiry window. This is the most direct countermeasure, though rarely implemented.

IP-based reputation signals: replay attacks come from different IPs than the legitimate sender's infrastructure. Despite the DKIM signature being valid, IP reputation signals and behavioral anomalies (recipient engagement patterns, delivery patterns) can still route replayed messages to spam.

How to use the DKIM Checker on sadiqbd.com

1. Verify your selector and key are correctly published — the basic function, ensuring your DKIM configuration is correct before deeper concerns apply
2. Review which headers are included in your DKIM signature: signing the To: header (the designated recipient) in addition to From:, Subject:, and body content makes replay to different recipients detectable — the To: value in the signed headers won't match the actual delivery recipient
3. Consider implementing x= expiry for high-value, transactional emails where replay would be most damaging (password resets, security alerts) — accepting that delayed delivery might cause expiry-related failures in exchange for limiting the replay window

Frequently Asked Questions

If an attacker receives my newsletter and replays it, can DMARC aggregate reports actually detect this? Potentially, with some lag. DMARC aggregate reports show authentication results per IP per domain — if example.com's reports show messages authenticated by their DKIM keys being sent from IPs that are not example.com's sending infrastructure, that's a signal. However, the aggregate report format shows authentication results, not delivery anomalies — distinguishing "legitimate delivery from authorized third-party sender using our DKIM" from "unauthorized replay" requires correlating the sending IPs against your known authorized senders. Most smaller senders don't have monitoring sophisticated enough to catch this automatically; it's primarily visible in forensic reports (ruf=) which include actual message headers.

Is the DKIM Checker free? Yes — completely free, no sign-up required.

Try the DKIM Checker free at sadiqbd.com — verify your domain's DKIM record, selector, and signature configuration instantly.