How a DKIM Replay Attack Successfully Spoofed Google — A Deep Dive

In today’s email threat landscape, phishing attacks have grown far more sophisticated than ever before. Gone are the days when scammers relied on bad grammar, obvious spoofed domains, or clearly malicious links. Modern attacks can mimic legitimate system alerts so convincingly that even tech-savvy users hesitate to dismiss them. One such evolving threat is what’s known as a DKIM replay attack — and in a recent real-world case, attackers used it to convincingly spoof official Google emails, passing all standard email authentication checks.

In this article, we’ll walk you through how this attack worked, why it bypassed SPF, DKIM, and DMARC protections, how it leveraged trusted infrastructure, and — most importantly — how organizations can harden their defenses against similar threats.

A Harmless-Looking Email That Was Anything But

Imagine receiving an email that looks like an urgent message from no-reply@google.com. The subject line references a subpoena issued by law enforcement demanding access to your Google account data. The body clearly appears professional — official-sounding language, polished formatting, no grammatical errors, and even a branded footer.

At first glance, everything seems legitimate:

• The sender’s email appears to be from Google.
• The branding and formatting feel professional.
• There are no immediately obvious red flags such as misspellings or odd attachments.

But appearances can be deceptive. The email was, in fact, part of a highly technical phishing campaign that bypassed every major authentication control in place.

Understanding the Enemy: What Is a DKIM Replay Attack?

Before diving deeper, it’s essential to clarify what a DKIM replay attack really is.

DKIM (DomainKeys Identified Mail) is an email authentication method that cryptographically signs outgoing messages using the sender’s private key. Recipients use the public key published in DNS to verify that the message truly came from the claimed domain and wasn’t altered in transit.

A DKIM replay attack works by capturing an email that was legitimately sent and signed using DKIM. The attacker then reuses the same signed email — including its headers and body — to deliver malicious content to other recipients. If the signed parts of the email remain unchanged, the DKIM signature will still validate, making the message appear authentic even though it’s been replayed by an attacker.

Critically, DKIM signatures do not embed timestamps or recipient addresses, so the same signed content can be reused without breaking the signature. This makes DKIM-based replay attacks particularly dangerous and hard to detect.

How Attackers Weaponized Trusted Infrastructure

In this attack targeting Google users, the attacker didn’t just spoof a domain — they leveraged trusted infrastructure in a way that made the email look truly legitimate.

Here’s a step-by-step breakdown of how it unfolded:

1. Capturing a Validly Signed Email from Google

The attacker first obtained a legitimate email from Google that carried a DKIM signature. This email could have been something as mundane as a Google Workspace alert or notification but was signed using Google’s DKIM private key, meaning the signature would later validate against Google’s public key record.

2. Preparing the Replay

Instead of altering the signed content itself, the attacker embedded phishing content elsewhere — such as links directing users to fake login portals — while preserving the exact signed headers and body elements required for DKIM verification.

3. Sending via Third Parties

Rather than sending the email directly from Google’s mail servers (which would be obvious), the attacker used a series of third-party services:

• They sent the email through an Outlook account as the initial hop.
• It then passed through a custom SMTP relay (such as Jellyfish SMTP) and
• Finally was routed through Namecheap’s PrivateEmail forwarding service before landing in the victim’s Inbox.

Every forwarding service kept Google’s original DKIM signature intact, so when the email reached Gmail’s servers, Gmail saw a signed header that matched the domain in the “From” field and marked DKIM as valid.

4. DMARC Alignment and Delivery

Most email receivers use DMARC to determine whether to trust an email. DMARC evaluation passes if either SPF or DKIM aligns with the domain in the “From” field. In this attack:

• SPF technically passed (often due to forwarding rewriting the return path).
• DKIM passed unequivocally because the signed material was untouched.
• Because DKIM aligned with the “From” domain (google.com), the email also passed DMARC.

As a result, the entire authentication chain looked legitimate — even to advanced email filters.

Why This Attack Was So Effective

This campaign was successful for a few key reasons:

1. Trusted Domains and Infrastructure

Using domains owned and managed by major service providers (like Google and Google Sites) lends inherent credibility. Attackers even hosted a fake credential harvesting page on sites.google.com, a legitimate Google subdomain that uses secure HTTPS and Google branding.

2. Preserved DKIM Signatures

DKIM signatures that remain unchanged continue to validate, even if the message is replayed. Since DKIM does not cover every header and lacks timestamp enforcement, old signed content can be reused.

3. Forwarding With Signature Preservation

By passing the signed message through multiple trusted systems that preserved the original signatures, the attackers ensured that key authentication signals were exactly what Gmail expected.

4. Psychological Manipulation

The fake subpoena scenario leverages fear and urgency — classic social engineering tactics — making it more likely a user will follow malicious instructions without skepticism.

How to Spot and Mitigate DKIM Replay Attacks

Traditional email protections like SPF, DKIM, and DMARC are essential — but this attack showed that they’re not foolproof on their own. Here’s how organizations can tighten defenses:

1. Rotate DKIM Keys Frequently

Regularly updating DKIM keys reduces the window of opportunity for replaying previously signed content. For high-risk environments, a rotation cycle of 30 days or less is recommended.

2. Minimize the Signed Content Window

Configure your DKIM signing policy to cover as many headers as feasible, including those that might change during forwarding. The more content is signed, the harder it is for attackers to manipulate or reuse it convincingly.

3. Use Advanced Threat Detection

Behavior-based and heuristic analysis tools can detect suspicious patterns such as unusual sender chains, multiple relays, or content mismatches that purely technical checks don’t catch.

4. Educate Users About Sophisticated Phishing

Human vigilance remains crucial. Educate users not only on the superficial traits of phishing emails but also on more subtle cues — such as unexpected legal requests, unfamiliar links, and unsolicited account alerts.

5. Employ Additional Standards Like ARC

Authenticated Received Chain (ARC) helps receivers validate whether an email forwarded through intermediate services should be trusted. Though not a complete solution, ARC can help prevent some replay scenarios.

Final Thoughts

The Google DKIM replay attack wasn’t just a phishing campaign — it was a demonstration of how trusted infrastructure and authentication protocols can be turned against us if not configured and monitored properly. As email threats evolve, defenders must go beyond baseline authentication and adopt layered strategies that include key rotation, advanced filtering, user education, and continuous monitoring.

Secure authentication protocols like SPF, DKIM, and DMARC are foundational — but attackers will keep pushing the boundaries. Staying one step ahead means understanding these threats deeply and responding with equally intelligent defenses.

If you’ve encountered similar attacks or want help assessing your email authentication posture, reach out or share your experiences. Together, we can make email safer for everyone.