A New Crypto Phishing Campaign Abuses Google's Own Account Recovery Flow to Send Real System Emails That Pass SPF, DKIM, and DMARC—The Malicious Link Is Buried Below Pages of Blank Space, and Binance Says It Blocked 22.9 Million Scam Attempts in Q1 2026 Alone

Key Takeaways

• Attackers trigger Google's real account recovery contact request against a target, so the resulting notification is genuinely sent from Google's own mail servers rather than spoofed.
• Security researcher Jameson Lopp described the technique as packing a long message that contains a phishing link, with the true message shoved after several pages of blank space so the recipient scrolls past padding before reaching the bait.
• SPF, DKIM, and DMARC all pass because those protocols validate the sender's infrastructure, not the sender's intent—and the infrastructure here really is Google.
• Crypto exchange and DeFi users are the primary targets, because harvested passwords, session tokens, and two factor codes translate directly into emptied wallets and signed malicious approvals.
• Binance disclosed that its systems blocked 22.9 million scam and phishing attempts in Q1 2026, a 54 percent jump quarter over quarter, while protecting roughly 1.98 billion dollars in user funds.

How Does a Phishing Email Come From Google's Real Servers?

The attacker does not send the email at all—Google does, on the attacker's behalf. Google offers a recovery contact feature that lets an account holder designate a trusted person to help them regain access if they are ever locked out. Initiating or referencing that flow against a target address causes Google's infrastructure to generate and dispatch a system notification to the target, the same way it would for any legitimate recovery request.

The abuse lives in the free text and structure of the request. The attacker fills the request details with a very long body whose visible top resembles a routine Google security notice. As researcher Jameson Lopp documented, the real payload—the phishing link and its pretextual instructions—is pushed down by several pages of blank space. The recipient sees what looks like an authentic notification, scrolls, and eventually meets a link or a call to action that leads to a credential harvesting page styled to match Google or their exchange.

This is structurally similar to other campaigns that lean on trusted Google surfaces to launder their messages. We covered a parallel approach in the Facebook AccountDumpling campaign that routed through Google AppSheet, where attackers used a genuine Google product as the delivery vehicle so the mail inherited Google's sending reputation.

Why Do SPF, DKIM, and DMARC Pass?

They pass because all three protocols answer a narrower question than most people assume. They confirm that the email really was sent by the infrastructure it claims to come from. They do not, and cannot, judge whether the content is benign.

SPF checks whether the sending server's IP address is authorized to send mail for the domain. DKIM cryptographically signs the message with a key the domain owner controls, so a recipient can verify the message was not altered in transit and originated from that domain. DMARC ties the two together and tells receiving servers what to do when alignment fails. When the genuine google.com mail servers send the recovery notice, the IP is authorized, the DKIM signature is valid, and DMARC alignment holds. Every check returns a clean pass.

The Crypto Times framed the gap precisely: these checks validate the sender's infrastructure, not the sender's intent. That is the fundamental weakness the campaign exploits. The same blind spot drives a broader category of attacks that route malicious content through reputable platforms, including the BlueKit phishing as a service kit targeting Gmail, Outlook, and iCloud, which industrializes the production of mail that survives authentication while still carrying a hostile payload.

Who Is Being Targeted?

Crypto holders are the focus, because the path from a stolen credential to a stolen balance is short and irreversible. According to coverage from U.Today and Crypto Economy, the wave of official looking emails specifically hits exchange and DeFi users.

For exchange users, a fake login page reached through the buried link can capture the account password, an active session token, or a two factor code entered in real time. A session token in particular lets the attacker sidestep two factor authentication entirely, because a valid session has already cleared that gate. With access, the attacker initiates withdrawals before the victim notices. For DeFi users, the danger shifts to approval phishing, where the victim is coaxed into signing a transaction that grants the attacker spending permission over the victim's tokens—no password required, just a signature the victim did not understand.

The scale is not theoretical. Binance reported blocking 22.9 million scam and phishing attempts in Q1 2026, up 54 percent from the prior quarter, and protecting an estimated 1.98 billion dollars in user funds. The same disclosures noted that the platform's phishing success rate fell from 3.2 percent to 0.4 percent after it expanded AI driven defenses—evidence both of how relentless the volume has become and of how much of it still gets through somewhere in the chain.

How Do You Spot This Attack?

The tell is not the sender, because the sender is real. The tell is the mismatch between what the email claims and what you actually did.

Ask one question before anything else: did you request an account recovery, designate a recovery contact, or ask anyone to help you regain access? If the answer is no, an unsolicited Google recovery notification is suspicious by definition, regardless of how authentic it looks. A second signal is structure. A legitimate Google notice is concise. A message that opens normally and then runs into long stretches of empty space before presenting a link or an instruction has been padded deliberately to hide its purpose below the fold.

Be especially wary of any embedded link, including ones inside an email that genuinely came from Google. Attackers also lean on lookalike address tricks to make a fraudulent destination read as familiar—a pattern we broke down in the Robinhood phishing email flaw that abused the Gmail dot trick. Treat the link as untrusted and navigate to the service yourself.

What Should You Do Right Now?

Never act on a link inside a security or recovery email. Open a new tab and type the address yourself, or use a saved bookmark, then check the account's activity directly.

• Verify recovery state at the source. Go to your Google Account security page directly and review the recovery contacts, recovery phone, and recovery email listed there. Remove anything you did not add. Do the same on every exchange account, checking the device and session list and revoking anything unfamiliar.
• Move off SMS and shared codes. Use a hardware security key or a passkey for both your Google account and your exchange wherever it is supported. A phishing page cannot replay a hardware key the way it can replay a typed code, which closes the session token theft path.
• Read every signature request. For DeFi, slow down on token approvals and check exactly what permission a transaction grants before signing. Revoke stale or unlimited approvals you no longer need.
• Report and delete. Report the message as phishing so the provider can tune its filters, then delete it. Do not forward the link to anyone except a security team.

The deeper lesson is that a passing authentication result is not a verdict on safety. SPF, DKIM, and DMARC tell you who handed the mail to your inbox, not whether the contents were written to rob you. Until email security can reason about intent rather than infrastructure, the burden of the final check stays with the reader—which means treating an unrequested recovery notice, however genuine its headers, as a prompt to verify everything by hand.