Unmasking the DKIM Replay Attack: How Phishers Spoofed Google and What It Means for Email Security

In April 2025, a sophisticated phishing campaign targeting Google users exposed vulnerabilities in Google’s infrastructure and the DomainKeys Identified Mail (DKIM) protocol. Known as a DKIM replay attack, this scheme allowed attackers to send emails that appeared to originate from Google’s legitimate [email protected] address, complete with valid DKIM signatures. These emails bypassed standard email authentication mechanisms, deceiving users into visiting fraudulent Google Sites pages to harvest their credentials. This blog post provides a detailed technical analysis of the attack, the weaknesses it exploited, and its implications for email authentication protocols like SPF, DKIM, and DMARC. Optimized for tech-savvy readers, it includes diagrams, RFC citations, and actionable recommendations.

What is a DKIM Replay Attack?

A DKIM replay attack involves an attacker reusing a legitimate DKIM-signed email to send or forward messages that appear authentic to receiving mail servers. To understand this, let’s first examine how DKIM works, as defined in RFC 6376.

DKIM allows a sender to sign an email with a private key, associating it with their domain. The signature, included in the DKIM-Signature header, covers specific email headers (e.g., From, To, Subject) and the body. The recipient verifies the signature using the sender’s public key, published in a DNS TXT record under a selector (e.g., selector._domainkey.example.com). The h= tag in the DKIM-Signature specifies which headers are signed, while the bh= tag contains a hash of the body. Canonicalization algorithms (c= tag) normalize headers and body to account for minor formatting changes during transit.

In a DKIM replay attack, an attacker intercepts a signed email and reuses it—either by resending it directly or forwarding it—while preserving the original signature. If the signed headers and body remain unchanged, the signature remains valid, making the email appear legitimate. In the Google attack, attackers forwarded a legitimate Google security alert email, which retained its DKIM signature, to deliver a phishing payload.

Diagram: DKIM Signing and Verification Process

[Sender] --> Signs email with private key --> Adds DKIM-Signature header
          --> Sends email
[Recipient] --> Retrieves public key from DNS
            --> Verifies signature against signed headers and body
            --> Pass/Fail

Timeline and Discovery

The DKIM replay attack targeting Google gained attention in April 2025 through multiple sources:

• April 16, 2025: Nick Johnson (nick.eth) shared a detailed X post (X Post by nick.eth), describing a phishing email posing as a Google security alert. The email, signed by accounts.google.com, passed DKIM checks and linked to a fake Google Sites page.
• April 22, 2025: The Hacker News published an article (Phishers Exploit Google Sites), outlining how attackers used Google Sites and DKIM to bypass email security.
• EasyDMARC Analysis: EasyDMARC provided a technical breakdown (DKIM Replay Attack Breakdown), explaining the forwarding mechanism and DKIM preservation.
• DMARC Report Insights: DMARC Report defined DKIM replay attacks and offered prevention strategies (DKIM Replay Prevention).

These reports highlighted the attack’s sophistication and the urgent need for enhanced email security measures.

Technical Deep Dive

The attack exploited specific features of Google’s infrastructure and DKIM’s behavior in forwarding scenarios. Here’s a step-by-step breakdown:

Attack Mechanics

1. Domain and Account Setup:
   • Attackers registered a domain (e.g., googil-mail-smtp-out-198-142-125-38-prod.net) and created a Google account with an email like [email protected]. The username me was chosen to exploit Gmail’s display logic, which shows emails addressed to the user’s own address as “me.”
   • They set up a Google Workspace account and verified it via DNS TXT records.
2. OAuth Application Creation:
   • Attackers created a Google OAuth application, naming it with the phishing message (e.g., “A SUBPOENA WAS SERVED ON GOOGLE LLC…”), followed by whitespace and a legitimate-sounding suffix like “Google Legal Support.”
   • The app was configured to request access to the attacker’s Google account.
3. Triggering the Security Alert:
   • By granting the OAuth app access to [email protected], Google generated a security alert email from [email protected].
   • The email’s body included the app’s name, embedding the phishing message. It was signed with a DKIM signature (e.g., d=accounts.google.com; s=20230601; h=from:to:subject…).
4. Forwarding the Email:
   • Attackers forwarded the email from an Outlook account (e.g., [email protected]) through relays like Jellyfish SMTP (asp-relay-pe.jellyfish.systems) and Namecheap’s PrivateEmail (fwd-04-1.fwd.privateemail.com).
   • The forwarding preserved the original headers and body, keeping the DKIM signature valid.
5. Delivery to Victim:
   • The email reached the victim’s Gmail inbox, passing SPF, DKIM, and DMARC checks.
   • Gmail displayed it as sent to “me,” and the phishing message appeared as an official Google communication.
   • A link to a Google Sites page (e.g., https://sites.google.com/u/34961821/d/1XMIxkFiq54WpH2tKqay2EPnhN0Ukovet/edit) directed victims to a fake login portal.

DKIM Signature Validity

DKIM signatures remain valid in forwarding if the signed headers and body are unchanged. In this case:

• Signed Headers: Google likely signed headers like From, To, Subject, and Date. The To header, addressed to [email protected], was preserved in forwarding.
• Body: The email body, including the phishing message in the OAuth app’s name, was not modified.
• Canonicalization: DKIM’s relaxed canonicalization (c=relaxed/relaxed) allows minor formatting changes, ensuring the signature survived forwarding.

Table: Email Authentication Results

Check	Result	Reason
SPF	Fail	Sending IP (e.g., 66.29.159.58) not in Google’s SPF record.
DKIM	Pass	Original Google signature (d=accounts.google.com) valid.
DMARC	Pass	DKIM alignment with From: accounts.google.com.

Google’s DKIM Policy Weaknesses

• Long-Lived Keys: Google’s DKIM keys, identified by selectors like 20230601, may have long validity periods, allowing signatures to remain valid for extended periods.
• No Body Length Limits: The absence of the l= tag meant the entire body was signed, including the attacker-controlled app name.
• Permissive Selectors: Google’s DKIM configuration didn’t restrict selectors to prevent reuse in forwarded emails.

Spoofed Elements

• Brand Abuse: The email mimicked Google’s branding, using [email protected] and official formatting.
• Phishing Payload: The message claimed a subpoena required Google to share the victim’s account data, urging them to click a link to “examine case materials.”
• Exploit Path: The Google Sites link leveraged a trusted domain, and the OAuth app’s name allowed attackers to inject malicious content into a legitimate email.

Implications for Email Security

This attack reveals critical gaps in email authentication protocols:

Limitations of SPF and DKIM

• SPF: Only verifies the sending server’s IP against the sender’s DNS record. In this attack, SPF failed because the email was sent from non-Google servers, but this didn’t matter since DKIM passed.
• DKIM: Ensures message integrity but doesn’t prevent reuse of legitimate signatures in forwarding scenarios.

DMARC’s Failure

DMARC requires either SPF or DKIM to pass with domain alignment. Here, DKIM passed, aligning the From domain (accounts.google.com) with the DKIM domain, so DMARC didn’t block the email. This highlights DMARC’s reliance on the integrity of signed emails, which can be exploited when legitimate emails are repurposed.

Role of BIMI and ARC

• BIMI (Brand Indicators for Message Identification): Displays verified brand logos in emails but requires DMARC compliance. It wouldn’t have prevented this attack, as DMARC passed, but could confuse users by showing Google’s logo on phishing emails.
• ARC (Authenticated Received Chain): Preserves authentication results through forwarding by adding headers to track the email’s path. While ARC could indicate the email was forwarded, its limited adoption and lack of enforcement by receivers reduced its impact here.

The attack also underscores the risks of hosting user-generated content on trusted domains like sites.google.com, which attackers exploited to create convincing phishing pages.

Best Practices & Mitigations

To counter DKIM replay attacks, organizations and email providers can adopt the following measures:

For Senders

1. Oversigning Headers: Sign multiple headers (e.g., From, To, Subject, Date, Message-ID) to reduce the risk of undetected modifications (DKIM Signature Guide).
2. Shorten DKIM Key TTLs: Use the x= tag to set short expiration times for signatures, limiting their reuse window.
3. Body Length Limits: Apply the l= tag to sign only a portion of the body, though this must be used cautiously to avoid enabling attackers to append malicious content.
4. Stricter Canonicalization: Use simple/simple canonicalization to reduce tolerance for formatting changes.
5. Key Rotation: Rotate DKIM keys quarterly to minimize the impact of compromised or reused signatures (DKIM Key Rotation).

For Receivers

1. Rate Limiting: Limit emails from a single sender to detect mass replay attacks.
2. User Education: Train users to verify email authenticity and avoid clicking suspicious links (Google 2FA Guide).
3. Advanced Filtering: Implement content-based filtering and machine learning to identify phishing patterns.

For Service Providers

1. Restrict User Content: Disable scripts and embeds in platforms like Google Sites to prevent phishing page hosting.
2. Sanitize Email Content: Limit or sanitize user-inputted fields, such as OAuth app names, to prevent malicious content injection.
3. Adopt ARC: Promote ARC adoption to track authentication results in forwarded emails.

Table: Mitigation Strategies

Strategy	Description	Impact
Oversigning Headers	Sign multiple headers to ensure integrity.	Reduces header manipulation risk.
Short TTLs (x= tag)	Set signature expiration times.	Limits replay window.
Key Rotation	Update DKIM keys regularly.	Mitigates long-term signature reuse.
ARC Adoption	Track authentication through forwarding.	Improves visibility of email path.

Conclusion

The DKIM replay attack on Google highlights the evolving sophistication of phishing campaigns and the limitations of current email authentication protocols. While SPF, DKIM, and DMARC provide robust defenses against spoofing, they struggle with scenarios where legitimate emails are repurposed for malicious ends. Google’s vulnerabilities—particularly in OAuth app naming and Google Sites—enabled attackers to craft convincing phishing emails hosted on trusted domains.

Google has begun addressing the OAuth vulnerability, as noted in Nick Johnson’s X post, but further action is needed. Providers must tighten controls on user-generated content, enhance email content validation, and promote protocols like ARC. The industry may also consider emerging standards like DANE, which uses DNSSEC for secure key distribution, or MTA-STS, which enforces TLS for email transport, though these address different aspects of email security.

For users, vigilance remains key. Always verify email links, enable two-factor authentication, and report suspicious emails. As cyber threats evolve, so must our defenses, ensuring email remains a trusted communication channel.

Key Citations

• Phishers Exploit Google Sites and DKIM to Bypass Security
• Google Spoofed via DKIM Replay Attack: Technical Breakdown
• What is a DKIM Replay Attack and How to Prevent It
• X Post by nick.eth on DKIM Replay Attack
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• What is a DKIM Signature? EasyDMARC Guide
• How Often Should You Rotate Your DKIM Keys?
• Google Two-Factor Authentication Setup Guide