Replay, Reuse, and Rob: How Attackers Exploit DKIM and Turn Google OAuth Alerts into Phishing Lures

Email authentication protocols like SPF, DKIM, and DMARC are intended to protect users from impersonation and fraud. But as this campaign shows, even these safeguards can be turned against the very people they’re meant to protect.

In a recent campaign observed in Abnormal’s environment that has also been heavily discussed on X/Twitter, threat actors leveraged a DKIM limitation to bypass authentication and deliver Google-branded phishing emails signed by legitimate domains, including those belonging to Google itself. The result? Phishing emails that passed security checks, landed in inboxes, and appeared completely legitimate to their recipients.

The technique is called a DKIM replay attack, and while this isn’t the first time DKIM has been exploited, it’s rare to see the technique used this effectively and with infrastructure from a company like Google. This campaign is a reminder that even strong authentication isn’t foolproof—and behavioral analysis is more important than ever.

DKIM (DomainKeys Identified Mail) is an email authentication protocol that allows the sending server to attach a digital signature to an email. When received, the recipient server uses the sending domain’s public key to verify that the email was genuinely sent from that domain and wasn’t altered in transit.

This attack takes advantage of a critical email security gap: DKIM-signed messages can be replayed as long as the body remains unchanged. So if a malicious actor gets access to a previously legitimate DKIM-signed email, they can resend that exact message at any time, and it will still pass authentication.

Rather than forging a message or mimicking a domain, the attackers created an OAuth app with a phishing lure embedded in the app name, triggered a legitimate DKIM-signed alert by granting the app access to their Google account, and then forwarded that message unaltered through a trusted mail forwarding service.

Because the body content remained intact, the original DKIM signature still aligned with the sending domain and public key. And since SPF and DMARC don’t override a valid DKIM result, the email passed all authentication layers, even though it came from a server unaffiliated with Google.

Here’s a step-by-step breakdown of the DKIM replay attack.

1. Attacker Creates Google Infrastructure

• Registers a Gmail account.

• Registers an OAuth app and sets the app name to a phishing lure, such as:

Google Legal: A subpoena has been issued. View the case:
https://sites.google.com/u/17918456/d/1W4M_jFajsC8YKeRJn6tt_b1Ja9Puh6_v/edit

2. Trigger the Signed Alert Email

• The attacker grants the OAuth app access to their Google account.

• Google sends a DKIM-signed alert from:

no-reply@accounts.google.com

• The phishing content is embedded in the body as part of the app name.

3. Replay the Message to the Target

• The attacker forwards the message unaltered through:

fwd-03.fwd.privateemail.com

4. Delivery and Authentication Passes

• SPF, DKIM, and DMARC pass during earlier ARC chain hops.

• Microsoft and downstream relays ultimately flag the final authentication as failed, but Google’s DKIM signature was valid earlier, and some SEGs may still accept it.

Should the target click the embedded button labeled “Check activity”, they are redirected to a phishing page hosted on sites.google[.]com that is crafted to appear as a portal for Support Cases, convincingly imitating the kind of UX an employee would expect from Google.

If the target clicks either "Upload additional documents" or "View case", they are redirected to an exact replica of the Google sign-in page designed to steal login credentials.

The only indicator that the page is fraudulent is the domain, which is, once more, sites.google[.]com instead of accounts.google[.]com.

To better understand how this attack made it past authentication checks, we examined the message headers at each stage of its journey. The results reveal how earlier hops preserved validation results, even after the message left Google’s infrastructure.

DKIM Validation (Early hop via Google):

dkim=pass header.i=@accounts.google.com
header.s=20230601

SPF Validation (Forwarder):

spf=pass (google.com: domain of SRS1=/pix=eforward.registrar-servers.com... designates 198.54.122.148 as permitted sender)

DMARC Alignment:

dmarc=pass (policy=reject) header.from=accounts.google.com

Later Microsoft ARC Authentication:

dkim=fail (signature did not verify) header.d=accounts.google.com;
dmarc=fail action=oreject header.from=accounts.google.com;

This means that by the time Microsoft validates it, the email is flagged as a spoof. However, upstream relays (like Google and PrivateEmail) accepted and relayed the email successfully, preserving the authentication results. Although Microsoft ultimately flags DKIM/DMARC as failed, the ARC (Authenticated Received Chain) preserves earlier authentication results, which some downstream systems may trust when making delivery decisions.

Several technical and behavioral elements contributed to the effectiveness of this campaign.

From the clever use of OAuth app naming to the exploitation of trusted infrastructure, each component played a role in helping the phishing email evade detection and earn the target’s trust.

The biggest challenge in detecting this attack is that it doesn’t rely on spoofing alone—it uses authenticated infrastructure to send malicious content.

By leveraging DKIM-signed headers from legitimate domains, the emails passed all authentication checks. Thus, traditional security tools that rely on authentication failures or domain reputation will struggle to detect this attack. In fact, they may interpret the message as more trustworthy because of the successful DKIM check.

Further, Google is one of the most recognized and trusted brands in the world. When a message looks and feels like a real notification from Google—and passes authentication—it’s far more likely to succeed. Plus, it was Google’s own authenticated domains that were exploited as the apparent source of the messages.

The body content was also carefully crafted to stay within the bounds of what the original DKIM signature would allow. This required a deep understanding of how DKIM works and how much leeway a signature provides for message modification.

Finally, by embedding the phishing link within the body of a replayed, signed message, the attackers sidestepped common detection rules that look for suspicious URLs in unauthenticated emails.

This is a classic example of what makes email security so hard: the very signals defenders are trained to trust can be exploited to deliver attacks that are nearly impossible to distinguish from the real thing.

This campaign underscores a difficult truth: attackers don’t need to break authentication—they can just abuse it.

Stopping attacks like this requires moving beyond static signals and signature-based detection. It requires understanding what is normal—who typically sends alerts, what those alerts look like, and how employees usually engage with them.

Abnormal’s behavioral AI identifies threats by baselining known-good behavior across your organization and flagging deviations, regardless of whether the email passes DKIM or not. That means it can detect malicious messages that look legitimate on the surface but deviate from normal sender behavior, language patterns, or intent.

As attackers get smarter, security must too. Because when email authentication is no longer enough, behavior is the only signal that truly matters.

For even more insights into the threat landscape and predictions for where it’s headed, download our report, Inbox Under Siege: 5 Email Attacks You Need to Know for 2025.