Phishing emails from Google's own servers pass SPF, DKIM an…

Q: What should an end user do to spot one of these messages?

Treat 'who sent this' as a separate question from 'did I ask for this'. A real Google security email arrives because you initiated an action — added a recovery contact, signed in from a new device, changed a password. If a Google-branded email arrives unprompted, scroll the full message before clicking anything: the recovery-contact variant hides its phishing link far below the visible content using whitespace. When in doubt, open accounts.google.com directly in a new tab and verify the security state from there rather than from any email link.

Security researcher Jameson Lopp publicly disclosed on May 17, 2026 a phishing technique that abuses Google’s own account-recovery contact request to send phishing emails directly from Google’s servers. Because the message genuinely originates inside Google’s infrastructure, every check that Gmail, Outlook, Yahoo and the rest of the industry rely on — SPF, DKIM, DMARC — comes back valid. The technique is the second documented case this month after the AccountDumpling AppSheet campaign that Guardio Labs tied to roughly 30,000 stolen Facebook business accounts. Two different abuse paths, the same structural gap: authentication confirms the sender is Google, it cannot confirm what’s inside.

How the recovery-contact attack works

The attacker initiates a Google account-recovery contact request naming the victim’s email address. Google’s recovery pipeline then sends a real notification email from its own servers — addressed to the victim — explaining that someone has nominated them as a recovery contact. The attacker controls the free-text “message to the contact” field in that request, and stuffs it with a long block of whitespace followed by a fake security alert and a phishing link. The victim sees a genuine-looking Google security email; scrolling past the visible content reveals the payload. (Source: Crypto Times, May 18, 2026.)

Lopp’s own framing on Twitter was direct: the attack is “abusing an actual google recovery contact request form and stuffing it with a really long message that contains a phishing link. The true message is shoved after several pages of blank space at the bottom.” The crypto-investor angle in the original write-up reflects the initial victim cohort, but the mechanism is provider-agnostic — anyone with a Gmail address can be targeted, and the same family of techniques applies to other large providers whose product surfaces accept user-generated outbound copy.

Why SPF, DKIM and DMARC don’t catch it

SPF, DKIM and DMARC verify infrastructure, not intent. SPF asks whether the sending IP is allowed to send for the From: domain. DKIM cryptographically signs the message body with the sending domain’s key. DMARC requires that the authenticated domain align with the visible From: header. When Google’s own servers send the email, all three checks pass by definition — the IP is Google’s, the signature is Google’s, the alignment is exact. The protocols were designed to stop forgery; they were not designed to judge whether content that a third party can inject into a Google product is safe. (Source: Field Effect — Valid, signed Google emails used in new sophisticated phishing campaign.)

The AccountDumpling campaign documented by Malwarebytes Labs on May 4 illustrates the same pattern from a different angle: phishing messages arrived “via legitimate Google infrastructure, appearing as noreply@appsheet.com delivered via appsheet.bounces.google.com,” which let them “pass the usual technical checks” and bypass authentication-driven spam filters. (Source: Malwarebytes Labs, May 4, 2026.) Guardio Labs counted roughly 30,000 compromised Facebook business accounts across the United States, Italy, Canada, the Philippines, India, Spain, Australia, the United Kingdom, Brazil and Mexico before the operation was disclosed. (Source: The Hacker News, May 2026.) The recovery-contact disclosure is not a one-off — it is the second instance this month of attackers industrialising a known structural gap.

What to do this week

Add one rule to your inbox triage: treat “did I initiate this?” as a separate question from “is the sender authentic?” Authentication tells you Google sent the email — it cannot tell you whether you asked for it. Any unprompted Google security email should be verified by opening accounts.google.com directly in a new tab rather than by clicking links in the message. Scroll the full message before acting: the recovery-contact variant hides its phishing link far below the visible content. For accounts that hold money or business assets, replace SMS or app-code 2FA with a passkey or a hardware security key — passkeys resist the adversary-in-the-middle proxying that defeats one-time codes.

I tested the verification path on my own Gmail account this morning: opening accounts.google.com → Security → “Your devices and sign-in events” surfaces every legitimate recovery-contact addition Google would notify me about, with no need to trust any email link. The whole check took under thirty seconds and is the single most reliable counter to this class of attack — the page is served from Google’s actual authentication surface, not from any inbox content. The structural fix lives with the platforms, not the recipients. Google needs to constrain the free-text field on recovery-contact requests, and the AppSheet outbound-email surface needs a content-classification pass before messages leave Google’s IPs. Until that happens, individual users carry the load — and the answer is not to distrust SPF, DKIM and DMARC. They still block forgery, and they remain the table-stakes hygiene that publishers like GMX and web.de now enforce on inbound mail. The answer is to read authentication results as one signal among several, alongside “did I expect this?”, “what is it asking me to do?”, and “does the action match the channel?” The same logic underpins the Microsoft Exchange OWA zero-day patched in May and the Outlook zero-click RCE — different bug class, same takeaway: in 2026, trusting that a Gmail-coloured envelope is safe to open is no longer a defensible posture. Readers weighing whether their primary mailbox should still live inside the major providers may want to revisit Proton Mail’s post-quantum rollout or Mozilla’s recently launched Thundermail the next time they reconsider their setup.

Alexis Dollé

Founder & Editor

Alexis Dollé, email expert for 10+ years. Founder of Email Tools. I test every email client and utility myself, then write about them the way I’d explain them to a friend — no marketing fluff, no sponsored rankings, every claim sourced.

Frequently asked questions

What is the Google recovery-contact phishing scam disclosed on May 17, 2026? — phishing email sent through Google’s own recovery pipeline

Security researcher Jameson Lopp publicly described a technique that abuses Google’s account-recovery contact request feature. The attacker initiates a recovery-contact request to the target, then stuffs the request’s free-text field with a long block of whitespace followed by a phishing link. Google sends the resulting email from its own servers, so it carries a valid SPF result, a valid DKIM signature, and lands aligned with Google’s DMARC policy. The victim sees a genuine Google security email that scrolls into a phishing payload at the bottom.

Why do SPF, DKIM and DMARC fail to block these emails? — they verify infrastructure, not content

SPF authorises sending IPs, DKIM signs message content with the domain’s key, and DMARC enforces alignment between the visible From: domain and the authenticated domain. All three protocols verify the sender’s infrastructure, not the sender’s intent. When the attacker triggers a legitimate Google system to send the email, every check passes because the email genuinely originates from Google. The authentication layer confirms “Google sent this” — it cannot judge whether the content inside is benign or hostile.

How is the May 17 attack different from the AccountDumpling / Google AppSheet campaign? — different abuse path, same structural weakness

Different abuse path, same structural weakness. The AccountDumpling operation disclosed by Guardio Labs in early May routed phishing through Google AppSheet — emails arrived from noreply@appsheet.com via appsheet.bounces.google.com and impersonated Meta support, harvesting Facebook business credentials. Approximately 30,000 accounts were compromised. The May 17 recovery-contact technique uses Google’s account-recovery pipeline instead of AppSheet. Both bypass SPF, DKIM and DMARC for the same reason: the email is genuinely from Google.

What should an end user do to spot one of these messages? — verify intent independently of authentication

Treat “who sent this” as a separate question from “did I ask for this”. A real Google security email arrives because you initiated an action — added a recovery contact, signed in from a new device, changed a password. If a Google-branded email arrives unprompted, scroll the full message before clicking anything: the recovery-contact variant hides its phishing link far below the visible content using whitespace. When in doubt, open accounts.google.com directly in a new tab and verify the security state from there rather than from any email link.

Does enabling two-factor authentication help against this attack? — partially, and only if it’s a passkey or hardware key

Partially. Strong 2FA — ideally a passkey or a hardware security key, not SMS — prevents the credential half of an account takeover even if you do hand over your password to a phishing page. It does not prevent the phishing page from also asking for a one-time 2FA code and replaying it in real time. The Microsoft Defender team has documented adversary-in-the-middle (AiTM) toolkits that proxy 2FA codes within seconds of capture. Passkeys resist that proxying because the cryptographic challenge is bound to the legitimate domain — the phishing page cannot satisfy it.

Has Google responded to the recovery-contact disclosure? — no formal advisory yet

As of the public disclosure on May 17, 2026, Google has not issued a formal advisory specific to the recovery-contact variant. Google did acknowledge the AccountDumpling AppSheet campaign in early May and took down the abusive AppSheet projects identified by Guardio Labs. The structural issue — Google-owned domains and infrastructure routing user-controlled content — is broader than either incident and will likely require product-level guardrails on the recovery-contact free-text field and AppSheet’s outbound email surface.

Sources