DKIM Replay: When a 'Valid' Signature Becomes a Cyberweapon

You see it in the headers: `dkim=pass`, `dmarc=pass`. The green checkmarks light up in your mail client. The email is from your CFO, it passed authentication, and it carries an urgent request to wire funds to a new vendor. But something feels off. The request is unusual, the tone slightly askew. You dig deeper, and the truth is chilling: the signature is valid, but the email is a fraud.

This isn't a failure of cryptography. It's a failure of context. Welcome to the DKIM replay attack, a sophisticated technique where an attacker captures a legitimately signed email and 'replays' it to new victims, often with subtle, dangerous modifications. It exploits the very trust that DomainKeys Identified Mail (DKIM) was designed to create.

Understanding this attack vector is non-negotiable for anyone in a SOC or on a security team. It proves that a passing authentication result isn't a free pass for an email to land in an inbox. It’s just one signal among many, and sometimes, it’s the most misleading one.

Anatomy of a Perfect Forgery

A DKIM replay attack doesn't involve breaking the cryptographic signature. Quite the opposite—it relies on the signature being perfectly valid. The attacker isn't a digital lockpicker; they're a master of social engineering who found a key left unattended.

The attack unfolds in a few key stages. First, the attacker needs a signed email from the target domain. This is the easy part. They can simply sign up for a newsletter, get a password reset email, or receive any automated transactional message from the domain they wish to impersonate. The goal is to obtain an email with a valid DKIM signature that is unlikely to change frequently.

Capture, Modify, Resend

Once the attacker has this 'seed' email, they download the raw source. This gives them the full message, including the `DKIM-Signature` header and the signed portions of the body. The original signature, defined in RFC 6376, is a cryptographic pledge that certain headers and the message body have not been altered since they left the original sending server.

Here's the critical flaw. The DKIM standard does not require all headers to be signed. An attacker can take the captured email, keep the signed headers and body intact, and then alter or add *unsigned* headers. Most crucially, they can change the `To`, `Cc`, `Bcc`, and often the `Subject` and `Date` headers. They then resend this doctored message to their new, intended victims.

The receiving mail server performs a DKIM check. It fetches the public key from the sender's DNS, uses it to verify the signature against the signed headers and body hash, and finds a perfect match. The signature is cryptographically sound. `dkim=pass`. Because DMARC only requires SPF *or* DKIM alignment, the passing DKIM result often leads to a `dmarc=pass` as well, effectively giving the malicious email a green light past the first line of defense.

The Treachery of Unsigned Headers

The entire attack hinges on a simple truth: you can't trust what isn't signed. A DKIM signature is a promise about specific parts of an email, listed explicitly in the signature header itself. Everything else is just hearsay.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=m1; t=1678886400; bh=ABC...xyz; h=From:Subject:Date:Message-ID:To; b=GHI...jk1=

Take a look at that `h=` tag in the example header. This is the list of signed headers. In this case, `From`, `Subject`, `Date`, `Message-ID`, and `To` are protected. An attacker couldn't change the `Subject` without invalidating the signature. But what's missing? There’s no `Cc`, no `Reply-To`, no `List-Unsubscribe`. The attacker has free rein to add or modify those.

Why Aren't All Headers Signed?

It seems like an obvious flaw, so why does it exist? The email ecosystem is messy. As an email travels from sender to receiver, it passes through multiple Mail Transfer Agents (MTAs). Some of these, like mailing list servers or forwarding services, legitimately add or modify headers. For example, a forwarder will prepend a `Received` header, and a mailing list might add a `List-Unsubscribe` header.

If every header had to be signed, any legitimate modification by an intermediary MTA would break the signature, causing valid emails to fail authentication. Think of a forwarded calendar invite from a vendor's mail exchange—it gets legitimately modified en route. The creators of DKIM had to build in flexibility to accommodate this reality, but that very flexibility is what attackers exploit. They don't have to break the lock if the door was left partially open by design.

Partial Fixes and Paper Shields

The authors of RFC 6376 foresaw the potential for replay attacks and included a few optional tags meant to mitigate them. Unfortunately, their adoption is inconsistent and their effectiveness is limited.

Body Length (`l=` tag)

The `l=` tag specifies the exact number of bytes in the message body that are included in the hash. The idea is to prevent an attacker from appending malicious content (like a phishing link) to a legitimately signed message. While it sounds good, its protection is brittle. An attacker can't append content, but if the original message contains elements they can manipulate—like URLs in a marketing email where parameters can be changed—they might still achieve their goal. Furthermore, many MTAs make tiny alterations to the body, like converting character sets or changing line endings, which can break a strict length check, leading many senders to avoid using it to prevent deliverability issues.

Signature Expiration (`x=` tag)

The `x=` tag provides a timestamp after which the signature should be considered expired. This is the most direct defense against replay attacks. If a signature is only valid for a few hours, it drastically reduces the window for an attacker to capture and reuse it. However, many legitimate senders set this value weeks or months into the future, if they set it at all. They do this to ensure their messages remain valid even if there are delivery delays or the email sits in a user's inbox for a long time before being processed by an automated system. An expiration date set to 30 days from now is useless against an attacker who plans to replay the signature within 30 minutes.

Beyond the Signature: Context is King

If a `dkim=pass` can be a lie, what's a security analyst to do? You stop trusting single data points and start demanding a broader narrative. True email security isn't about one protocol; it's about correlating signals across the entire delivery chain.

This starts with the `Authentication-Results` header. Don't just look for `dkim=pass`. Look at the whole picture. Did SPF pass or fail? If it failed, why? Maybe the sending IP doesn't match the purported domain's SPF record, a huge red flag if DKIM is passing. This misalignment is a classic indicator of a replay, where the message is sent from an attacker's server, not the legitimate one.

Next, trace the `Received` headers. These form a forensic breadcrumb trail showing the path the email took. In a replay attack, you'll often see a strange path. The first 'hop' might be from a residential IP address or a cheap VPS provider, not the expected corporate mail servers of the domain in the `From` header. The legitimate part of the signature doesn't cover this new, malicious delivery path.

For complex forwarding scenarios, the Authenticated Received Chain (ARC), specified in RFC 8617, becomes essential. ARC provides a way for downstream MTAs to see the original authentication results *before* a forwarder broke SPF and DKIM. An ARC chain can show you an original `dkim=pass` but also reveal the new hops that were added later, giving you the context to spot a malicious detour.

Your Tools Need to See the Whole Story

A simple 'pass' or 'fail' is not enough information for a modern defense. Security platforms must look beyond the DMARC result and analyze the components that produced it. Was it an SPF pass or a DKIM pass? If DKIM passed, which headers were signed? Which were not? Does the `Subject` or `To` header appear to be recently manipulated, even if some other headers were signed?

Behavioral analysis is also key. Is this the first time this sender has communicated with this recipient? Is the topic of the email consistent with past communications? Does the email contain an unusual sense of urgency or a request that deviates from normal business processes? These are questions that can only be answered by a system that maintains a memory of communication patterns, not just a cryptographic checklist.

The takeaway

A valid DKIM signature proves who sent an email and that parts of it were not changed. It does not prove the email is safe or that the context surrounding it is honest. The DKIM replay attack is a stark reminder that our security protocols are only as strong as our interpretation of their results. A passing checkmark is the beginning of an investigation, not the end.

As an analyst, your job is to be the professional skeptic. Question the green check. Correlate it with header traces, SPF results, and behavioral context. A platform like MailSleuth.AI is built to surface these correlations automatically, but the fundamental principle is one every analyst must internalize: trust, but always verify every single signal.