DKIM Replay Attacks: Anatomy, Workflow, and Real-World Case Studies

“Even the strongest locks can be picked if you have the original key.” - Unknown

Email authentication protocols like DKIM (DomainKeys Identified Mail) are designed to guarantee a message's integrity and origin. Yet, attackers have devised a workaround: the DKIM replay attack. By capturing and resending a legitimately signed email, they can trick mail servers and users into trusting malicious or out-of-context messages. This blog explores the technical mechanics of DKIM replay, walks through a detailed attack workflow, reviews real-world incidents, and lays out robust defenses.

Understanding DKIM Foundations

DKIM cryptographically signs select portions of an email (headers and body) using the sender's private key. Recipients retrieve the matching public key from DNS to verify:

• Signature Header

• Canonicalized Headers (From, Subject, Date, etc.)

• Canonicalized Body Hash

If the hash matches, the message is deemed untampered and genuinely from the stated domain.

Key DKIM Concepts

• Canonicalization (c=): Defines how whitespace, header order, and line breaks are normalized.

• Header Fields Signed (h=): Which headers are included in the signature.

• Body Length Limit (l=): Optional parameter limiting the body bytes covered.

• Selector (s=): Chooses the DNS record containing the public key.

What Makes DKIM Replay Attacks Possible?

At its core, DKIM replay abuses two properties:

• Signature Validity Window: A DKIM signature remains valid until the email's DKIM key is rotated or expires.

• Lax Header Coverage: If critical headers (like To: or Date:) aren't signed, an attacker can modify them without invalidating the signature.

By capturing a signed email and resending it (unaltered or with permissible header tweaks), the attacker bypasses DKIM checks, making the message appear legitimate.

DKIM Replay attack

Detailed Attack Workflow

Below is a step-by-step technical breakdown:

1. Capture a Signed Email

   1. Man-in-the-Middle (Optional): On insecure networks, the attacker intercepts someone's incoming mail.

   2. At this stage, the attacker has a fully signed email

      
      

2. Analyze the DKIM Signature

   1. Extract the h= header list to see which fields are protected.

   2. Check for l= (body length) and c= (canonicalization) settings.

   3. Tools like dkimverify.py or MTA logs can display signed headers and hashing details.

      
      

3. Modify Unsigned Headers (Optional)

   1. If To: or Date: aren't in h=, attacker can change the recipient or timestamp. Since this header wasn't signed, the DKIM check still passes.

      
      

4. Replay the Email

   1. The attacker uses any SMTP client or automation.

   2. Because the DKIM signature is intact and valid, many MTAs and spam filters accept the message without further scrutiny.

      
      

5. Payload Execution

   1. Phish Credentials: Embed a malicious link or attachment.

   2. Spread Disinformation: Resend old confidential correspondence.

   3. Bypass Spam Filters: Exploit the trust in authenticated senders.

   
   

Real-World Case Study: ProtonMail's Reputation Hit

In April 2021, ProtonMail suffered a DKIM replay incident:

• Initial Discovery: Attackers subscribed a disposable address and received a legitimate newsletter signed by ProtonMail.

• Replay Campaign: They replayed the email to thousands of Gmail and Yahoo accounts, flooding inboxes with benign but unsolicited content.

• Impact: ProtonMail's domain reputation dipped, causing some legitimate emails to land in spam.

ProtonMail's response included:

• Key Rotation: Immediate generation of new DKIM keys.

• Oversigning: Adding To: and Date: to the signed header list.

• TTL Reduction: Lowering DNS TTL for faster public key updates.

Mitigation and Best Practices

1. Oversign Critical Headers

   1. Add To, Date, Message-ID, and Subject to your DKIM signature. This prevents attackers from altering recipients or timestamps without invalidating the signature.

      
      

2. Use body length limits

   1. Set an l= tag to cover only the first N bytes of the body. Even if the attacker appends content, the signature covers enough of the original body to detect changes

      
      

3. Key Rotation and Short TTL

   1. Rotate DKIM keys every 30–90 days.

   2. Set DNS TTL to a low value (e.g., 300 seconds) for swift revocation.

      
      

4. DMARC Enforcement

   1. Publish a strict DMARC policy to instruct receivers how to handle DKIM failures. A reject policy ensures replayed or modified emails are discarded.

      
      

5. Replay Detection

   1. Tracking identical Message-ID and signature combos.

   2. Alerting on unusually high volumes of the same signed email.

   3. Rate-limiting inbound messages from the same sender/domain.

DKIM replay attacks exploit the very mechanism designed to secure email. By understanding the technical underpinnings such as canonicalization, header coverage, and signature validation, organizations can fortify their email pipelines. Oversigning, key rotation, and strict DMARC policies convert DKIM from a potential liability into a robust defense.

“Security is not a product but a process.” – Bruce Schneier

Stay proactive: review your DKIM setup today, tighten oversigning, and monitor for anomalous replays. Your domain's reputation, and your users trust, depend on it.

Note: Feel free to drop your thoughts in the comments below - whether it's feedback, a topic you'd love to see covered, or just to say hi! Don't forget to join the forum for more engaging discussions and stay updated with the latest blog posts. Let's keep the conversation going and make cybersecurity a community effort!

-AJ