Google Spoofed Via DKIM Replay Attack: A Technical Breakdown

This morning started with a call from a friend – clearly shaken. He had just received an alarming email that looked strikingly legitimate. Unsure whether it was safe or a scam, he reached out to me for help verifying its authenticity.

What followed was a deep dive into the message to determine whether it was a genuine communication or a cleverly crafted phishing attempt. The email was convincing enough to create real concern, and that’s what makes this story worth sharing.

This was the email:

The email claimed that a subpoena had been issued by law enforcement requesting the extraction (access/download) of the contents of his Google Account.

What made the situation even more alarming was that the email appeared to come from a legitimate Google no-reply address. On the surface, everything looked clean – no typos, no odd links, and the sender domain seemed genuine. But something felt off, and that gut feeling is often your first line of defense.

Digging Deeper: Investigating the Suspicious Email

Curious and concerned, I examined the email headers and link previews in a sandbox environment, a secure setup isolated from production systems, specifically designed for this kind of research. On the surface, everything appeared to check out:

• The sender address looked like an official Google no-reply domain
• The branding and language were polished and professional
• There were no obvious grammar issues or suspicious attachments.

But as we know, phishing campaigns have gotten much more sophisticated. So, I dug into the email headers, checking the SPF, DKIM, and DMARC authentication results. That’s when the red flags began to appear.

Important Reminder: Don’t Engage with Suspicious Emails

Never click on links or follow instructions in suspicious emails, no matter how legitimate they may seem. Even opening a link or downloading a file could trigger malicious scripts or redirect you to phishing sites designed to steal your credentials.

If you’re unsure, leave the investigation to professionals who can safely analyze the message in a sandboxed environment..

Interacting with a malicious email outside of such an environment could result in:

• Loss of sensitive data
• Business Email Compromise (BEC)
• Account takeovers
• Wider network breaches

When in doubt, don’t click – report and escalate.

Here is the URL from that email:

https://sites.google.com/u/34961821/d/1XMIxkFiq54WpH2tKqay2EPnhN0Ukovet/edit 

This redirects to the Google account login page if you are not logged in :

After logging in, or if you are already logged in, it sends you to the Google Sites page. 

Here’s something critically important to understand: This is not a real Google support page. It’s not a Google sign-in page. It’s not any official Google property in the traditional sense.

Instead, it’s a regular Google Sites page, a free tool anyone can use to build a website. In this case, cybercriminals used it to create a page that mimics an official Google support case, complete with convincing visuals and language.

Because it’s hosted on a trusted google.com subdomain (like sites.google.com), many users let their guard down. But don’t be fooled – just because the domain looks legitimate doesn’t mean the content is.

What Google Sites Is Used For

Google Sites serves as a practical tool for various purposes, including:

• Internal team pages (like company intranets or project dashboards)
• Documentation hubs
• Event landing pages
• Personal portfolios or school projects
• Simple public websites
  

You can create a site by dragging and dropping content blocks (text, images, videos, Google Docs, etc.), and it’s tightly integrated with other Google Workspace tools.

When Trusted Infrastructure Becomes a Threat: Google Sites Abuse

Google Sites, originally launched in 2008, is part of Google Workspace and allows any authenticated user to create a custom website hosted under the sites.google.com domain. It’s widely used for internal and public-facing content due to its ease of use, zero cost, and native integration with Google products.

However, that same convenience is now being weaponized by attackers.

Why it’s dangerous:

• Anyone with a Google account can create a site that looks legitimate and is hosted under a trusted Google-owned domain.
  
• There’s no need for custom hosting or domain registration, and attackers benefit from Google’s SSL certificates and brand reputation.
  
• Attackers can embed deceptive content (fake login screens, credential harvesting forms, misleading CTAs) under a domain that would normally pass casual user trust and even automated link validation checks.

Now let’s take a closer look at the key elements that make this scam so deceptive.

How the Attacker Performed a DKIM Replay to Spoof Google

This attack was a confirmed DKIM Replay Attack where a spoofed message appeared to be from [email protected], had passed DKIM and DMARC, and was delivered to a Gmail inbox.

Below is a step-by-step explanation of exactly what the attacker did, from start to finish — including all infrastructure involved.

Step 1: Attacker receives a legitimate email from Google

The attacker first received a real email from Google, originating from [email protected].

It included a valid DKIM signature:

DKIM-Signature: d=accounts.google.com; s=20230601; bh=a+1bch/…

The attacker then extracted and saved this exact email, including headers and body, without modifying anything signed by DKIM.

Step 2: Attacker prepares to replay the signed message

Instead of forging anything, the attacker reused the message as-is:

• From: → [email protected]
• Subject, Date, Message-ID, etc.
• Body content matching the original DKIM bh=…
  

The attacker was now ready to inject it using infrastructure they controlled or could access.

Step 3: Attacker sends the email from Outlook

The attacker used an Outlook account ([email protected]) to send the spoofed message.

Outbound hop:

Server: LO3P265CU004.outbound.protection.outlook.com
IP: 40.93.67.3

This IP is not associated with Google, but remember,, DKIM doesn’t validate IP, it only checks the signature and the From: domain (with DMARC).

Step 4: Message is relayed through Jellyfish SMTP

Microsoft then hands the message over to a custom SMTP service:

Relay: asp-relay-pe.jellyfish.systems
IP: 162.255.118.7

This system acts as a middle relay, distancing the spoof even further from Google. It’s not affiliated with Namecheap or PrivateEmail.

Step 5: Message forwarded via Namecheap’s PrivateEmail

The message is then received by Namecheap’s mail infrastructure (PrivateEmail), which provides mail forwarding:

Systems involved:

• mta-02.privateemail.com
• DIR-08
• fwd-04.fwd.privateemail.com
• fwd-04-1.fwd.privateemail.com
  

During this phase:

• A new DKIM signature is added: DKIM-Signature: d=fwd.privateemail.com; l=52331;
• The body beyond 52KB is not signed, but this DKIM is not aligned, so it’s not used for DMARC.
• SPF passes due to rewritten Return-Path, but is also not aligned.
  

However, since the original Google DKIM is untouched and aligned, DMARC still passes.

Step 6: Final delivery to Gmail

Final delivery is handled by:

Sender: fwd-04-1.fwd.privateemail.com (66.29.159.58)
Recipient MX: mx.google.com

At this point, the email reaches the victim’s inbox looking like a valid message from Google, and all authentication checks show as passing:

• SPF=pass (via forwarder)
• DKIM=pass (from Google)
• DMARC=pass (based on aligned DKIM)

Final SMTP Hop Breakdown:

When a Fake Subpoena Becomes an Attack Vector

Fake subpoena emails are especially dangerous because they trigger fear, urgency, and confusion. Most people don’t know precisely how subpoenas work, so when an email looks official and mentions legal action, it’s easy to panic and click without thinking.

To clarify, a subpoena is typically issued by:

• A court
• A lawyer (in civil cases)
• A government agency (in administrative cases)

A subpoena can require someone to:

• Appear in court
• Provide documents or evidence
• Testify at a deposition or trial

Serving a Subpoena

The subpoena must be formally served to the person or entity. Common methods include:

Personal Service (most common and preferred)

• A process server or law enforcement officer physically hands the subpoena to the individual.
• Required in most cases to ensure proper delivery and acknowledgment.

Mail or Email (only in some cases)

• Some jurisdictions or situations (especially civil subpoenas) allow service by certified mail or email, but only with prior consent or court approval. In such cases, the subpoena should be delivered in an encrypted way using the company’s official email address. It’s never delivered through third-party platforms.

A Registered Agent (for companies)

• If the subpoena is for a business, it’s often served to their registered agent (a person or service officially designated to receive legal documents on the company’s behalf).

Knowing how real subpoenas are issued and delivered can help you spot red flags. Phishing threats are evolving, no longer marked by broken English and sketchy URLs. Today’s attacks often come cloaked in legitimacy, sometimes even using platforms like Google Sites to mimic real support cases. As we saw in this real-world example, even the most tech-savvy users can be caught off guard.

The Takeaway?

Always question unexpected emails, especially those urging urgent action or containing links to login pages. Just because something looks like it comes from Google (or any other trusted source) doesn’t mean it’s safe.

When in doubt, don’t click, don’t reply, and don’t engage. Escalate to your security team or a professional who can handle the investigation in a secure, sandboxed environment.

I’m interested in seeing more real-life examples. Do you have any notable cases to share?