How are bad actors using Google Forms to send spam?
Michael Ko
Co-founder & CEO, Suped
Published 22 Apr 2025
Updated 5 Jun 2026
8 min read
Summarize with
Bad actors use Google Forms to send spam by making Google generate the email for them. They create or submit a form, put the lure in the form title, field values, confirmation text, or linked destination, then rely on Google Forms notifications, invitations, or response receipts to deliver the message. The email can pass SPF, DKIM, and DMARC because the sending system is Google, even when the content is unwanted or deceptive.
I treat these messages as platform-abuse cases, not as simple spoofing failures. Authentication tells me whether the sender domain was authorized to send that message. It does not tell me whether the form content is trustworthy, whether the linked page is safe, or whether the recipient expected the message.
Authenticated does not mean safe
A Google Forms message can be genuine Google mail and still be spam. The abuse sits in the payload that Google is asked to send, not in a forged sending domain.
How the abuse works
The core trick is simple: Google Forms has legitimate ways to email people. Attackers use those workflows at scale, then place the suspicious part where the recipient sees it. The visible message often looks like a normal Google notification, so some recipients trust it before reading the link, form title, or response details closely.
Google Forms editor with the email send dialog open.
The same idea appears in several forms. I separate them because each route leaves a different clue in the headers and body.
- Form invitation: The attacker emails a form link through Google Forms and puts the lure in the form title, description, or message text.
- Response receipt: The attacker submits a form using the target's email address, causing Google to send a copy of the response.
- Reflected fields: The attacker places the spam text inside answer fields that are copied into the email received by the victim.
- External link: The Google-hosted form contains a link, QR code, or instruction that sends the recipient to a separate page.
- Brand confusion: The message benefits from Google's sender reputation while the text claims urgency, account review, payment action, or document access.
Flowchart showing a Google Forms message moving through Google and reaching a user.
One reason this catches people is that the trust signal is split. The sender line says Google, the authentication results say Google, but the call to action comes from the form creator or from a submitted answer. That gap is where the abuse lives. I look for wording that asks the recipient to leave the form, make a payment, confirm credentials, approve a file, or reply outside the normal business process.
Why SPF, DKIM, and DMARC pass
SPF, DKIM, and DMARC can all pass because they evaluate the sending domain and its authorization, not the intent of every word inside the message. If the visible From domain is a Google domain and the mail is signed by Google, authentication has done its job. The problem is that the attacker induced a trusted platform to carry unwanted content.
Simplified header patterntext
From: Google Forms <forms-receipts-noreply@google.com> Return-Path: <forms-receipts-noreply@google.com> DKIM-Signature: d=google.com; s=20230601; Authentication-Results: mx.example; spf=pass smtp.mailfrom=google.com; dkim=pass header.d=google.com; dmarc=pass header.from=google.com
That distinction matters when investigating. If your domain is not in the visible From address, your DMARC record is not the thing that allowed the Google Forms message through. Your DMARC monitoring still matters because it shows whether attackers are also trying to use your own domain in parallel.
|
|
|
|
|---|---|---|---|
SPF | Pass | Google IP | Form intent |
DKIM | Pass | Google signed | User risk |
DMARC | Pass | From match | Payload abuse |
Authentication result versus what it proves
The key distinction
A forged message lies about who sent it. A Google Forms abuse message often tells the technical truth about who sent it, then uses that truth to make the content feel safer than it is.
The same review works for lookalike-domain concerns. If a domain looks odd, I still go back to the headers. A typo in the visible text is important, but the authenticated domain tells me whether I am looking at spoofing, a cousin-domain attack, or a real platform message carrying bad content. That keeps the response precise and evidence-based.
What to check when a message looks authentic
When I review one of these messages, I do not stop at a pass result. I read the headers and body together, then decide whether the message is legitimate Google workflow mail, unwanted Google-generated spam, or a separate spoofing attempt.
- Visible From: Check whether the sender is Google, a lookalike domain, or a domain your organization owns.
- DKIM signer: Look for the signing domain. Google-signed mail with suspicious form text points to platform abuse.
- Form link: Inspect whether the user is being pushed to a Google form, a shortened URL, or a non-Google page.
- Reflected text: Find content that appears to come from a form answer, not from a normal Google system notice.
- Recipient path: Confirm whether the recipient asked for a receipt, joined a form workflow, or was added without consent.
- Volume pattern: Look for repeated subjects, repeated form IDs, or bursts sent to shared inboxes and public aliases.
For a suspicious sample, send the message through the email tester and compare the authentication result with the visible content. The useful question is not just whether it passed. The useful question is which domain passed, which path delivered it, and what the message asked the recipient to do.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If the same organization is also seeing a broader rise in inbox junk, I separate Google Forms abuse from general Gmail inbox spam. The controls overlap, but the evidence trail is different.
How to reduce the risk
There is no clean DNS-only fix for someone abusing a real Google product. The practical response combines user education, content filtering, header review, and domain authentication monitoring. I split the work by who owns the control.
For recipients and security teams
- Filter context: Flag unexpected Google Forms mail to finance, payroll, executives, and shared inboxes.
- Inspect links: Treat form links, shortened links, and off-platform destinations as separate risk signals.
- Keep receipts: Preserve headers and body content before reporting or deleting the message.
- Report abuse: Send clear evidence to the workspace admin or platform abuse process.
For domain owners and senders
- Monitor DMARC: Confirm whether your own domain is being spoofed alongside the Google Forms campaign.
- Review senders: Keep approved mail sources clean so real failures stand out quickly.
- Watch reputation: Use blocklist (blacklist) checks to spot domain or IP reputation damage.
- Stage policy: Move DMARC policy forward only after legitimate sources are authenticated.
Suped fits the domain-owner side of this problem. It will not make every Google Forms message safe, but it gives the evidence needed to prove whether your domain is being abused, which sources are failing, and which fixes need DNS changes.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the best overall DMARC platform because it turns aggregate reports into actions: automated issue detection, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and MSP-ready multi-tenancy. Pair that with blocklist monitoring when a spam burst raises reputation concerns, and use a domain health check when you need a quick read on DMARC, SPF, and DKIM.
Best practical setup
- Inbox controls: Use content and URL rules for unexpected Google Forms mail.
- Domain controls: Use Suped to monitor DMARC, SPF, DKIM, blocklists, and source changes.
- Response controls: Escalate samples with headers, form IDs, destination links, and recipient patterns.
Limits of filtering Google Forms
Blocking every Google Forms message sounds simple until a real business process breaks. Surveys, intake forms, event registrations, hiring workflows, support requests, and school forms all use the same product family. The better target is unexpected or risky use, not all Google Forms mail.
Filtering confidence levels
Use stronger action when several independent signals point to abuse.
Low confidence
Review
Google sent the mail, but there is no risky link or unusual recipient pattern.
Medium confidence
Quarantine
The form is unexpected and the message includes urgency or an off-platform link.
High confidence
Block
The same form or subject hits many users and pushes them to a risky destination.
Public reporting has described this abuse pattern for years. The useful detail in the Google Forms abuse examples is that the attacker does not need to defeat Google authentication. The Sophos analysis also shows why form content and destination review matter as much as sender review.
|
|
|
|---|---|---|
Allow | Known forms | Misses bursts |
Quarantine | New forms | Reviewer load |
Block | Confirmed abuse | Workflow loss |
Common response options
I also watch for blocklist and blacklist side effects after a burst. Google Forms abuse usually damages the platform's filtering signals more than your domain, but a parallel spoofing run against your brand can create a separate reputation problem.
Views from the trenches
Best practices
Inspect the DKIM signer and visible From before trusting a message that passed authentication.
Track sudden Google Forms bursts by recipient, subject text, and linked form destination.
Tune filters on form context and user expectation, not on Google authentication alone.
Common pitfalls
Blocking all Google Forms mail breaks real workflows for surveys, hiring, and support fast.
Treating DMARC pass as intent proof lets platform-generated spam reach users unchecked.
Ignoring form titles and field values misses the text the recipient actually sees first.
Expert tips
Build a review path for Google Forms messages sent to finance and executive aliases.
Use DMARC data to confirm whether your own domain is being spoofed in parallel too.
Correlate spam complaints with form-link patterns before tightening filters across teams.
Marketer from Email Geeks says an authenticated Google message still needs header review because Google Forms can generate the mail itself.
2024-12-30 - Email Geeks
Marketer from Email Geeks says typosquatting assumptions can distract from the route when the headers show Google signed and sent the message.
2024-12-30 - Email Geeks
The practical answer
Bad actors are using Google Forms to send spam by abusing legitimate Google-generated email flows. The message can authenticate because Google sent it. The suspicious part is the form content, the reflected response, or the destination the recipient is asked to visit.
The fix is evidence-based triage. Inspect the headers, inspect the form content, preserve the sample, and monitor your own domain separately. Suped covers the domain side by showing DMARC failures, unverified sources, blocklist (blacklist) signals, and the steps needed to fix authentication gaps.
