Google spoofed via DKIM replay attack: A technical breakdown

How the attack actually works

• Attacker creates a Google OAuth app with a very long “App name” containing phishing text and a URL.
• Google sends a legitimate notification email (from its own domain) containing that app name to the attacker.
• The attacker or a forwarding service then re-sends that unchanged message to victims, preserving body and signed headers, so DKIM/DMARC/SPF all pass.
• The To: header remains the original one; SMTP RCPT TO determines actual delivery, so the recipient can differ from what’s shown.
• This is fundamentally a DKIM replay/forwarding issue plus Google allowing arbitrary user text to be echoed in high‑trust system emails.

Limits of DKIM / DMARC / SPF

• Commenters stress DKIM is explicitly designed to survive forwarding; it signs body and selected headers, not the SMTP envelope.
• Google does sign the To: header; changing it would break DKIM. But nothing prevents delivering that same message to someone else.
• DMARC is described as more of a server reputation/consistency scheme than strong sender authorization.
• SPF alignment tweaks (e.g., strict mode) wouldn’t stop this, since the original Envelope From and Header From are both Google’s.

Google Sites and domain design

• Many see the bigger problem as Google hosting user content on subdomains of google.com (e.g., Sites, possibly Drive).
• This makes phishing URLs look “official” and is compared to GitHub’s move of Pages to github.io to isolate user content.
• There’s discussion of cookie isolation, HttpOnly cookies, and other historic reasons for separate content domains.

Critique of the article and risk framing

• Several commenters find the post confusing and “marketing-y”: it initially implies body manipulation, omits full headers, and crops screenshots to hide the rest of Google’s template.
• Once read to the end, it becomes clear Google sent the scary text as part of the app name, and the mail was just forwarded.
• Some argue the attack is less novel than the “DKIM replay attack” branding suggests, though still effective against non-technical users.
• Others note Google has already limited OAuth app name length, reducing this specific vector.

User behavior and tooling

• Some technically inclined users rely on Received: headers and From paths, but acknowledge this is unrealistic for most people.
• Mainstream clients are criticized for hiding headers and over-emphasizing trust badges.
• Practical advice offered: don’t click action links in emails; instead navigate directly to the service, and read the full message.

Future mitigation work

• A participant references ongoing “DKIM2” work to cryptographically bind SMTP FROM/TO and track message modifications, while still supporting mailing lists and forwarders, to reduce replay-style abuse.