How do I troubleshoot spam placement in Google Workspace?
Published 22 Apr 2025
Updated 17 Oct 2026
13 min read
Summarize with
Updated on 17 Oct 2026: We added Email Log Search steps and clarified Gmail sender requirements, DKIM activation, and recipient-side spam checks.
When Google Workspace emails go to spam or junk, compare message headers, authentication results, sending reputation, recipient engagement, and message content. Start with a spam sample and an inbox sample so each change addresses an observed difference.
Start by proving whether the issue is sender-side or recipient-side. Google Workspace can place mail in spam because Gmail distrusts the sending pattern, because SPF, DKIM, or DMARC is not passing cleanly, because a link or template looks risky, or because an admin rule, quarantine policy, or user-level filter inside the receiving tenant is changing the result.
- Scope: Separate Gmail consumer recipients, Google Workspace recipients, and other mailbox providers.
- Headers: Collect full headers from spam and inbox samples before editing DNS records.
- Authentication: Check SPF and DKIM results, then verify that at least one passing domain matches the visible From domain under DMARC's domain-matching rules.
- Reputation: Review bounces, complaints, unsubscribes, cold traffic, and old recipient lists.
- Content: Test links, attachments, templates, tracking domains, and reply-to behavior in small batches.
What Google Workspace can and cannot tell you
Google Workspace gives you useful clues, but it does not give you a complete spam reason code. The practical sources are full message headers, Email Log Search, admin quarantine decisions, bounce messages, routing rules, compliance rules, and recipient-side spam settings. The official Google sender guidelines define the baseline for mail sent to personal Gmail accounts. Managed Google Workspace recipients can also have tenant-specific routing and spam controls, so check both paths.
For receiving-side issues, Google's own Google spam troubleshooting page points admins toward user feedback, personal contacts, spam bypass settings, authentication, and sender guidelines. That distinction matters: a sender reputation problem and a recipient tenant policy problem can look identical to the sender.
|
|
|
|---|---|---|
Headers | Original message | Authentication result and Google flags |
Email log | Admin console | Delivery path and policy actions |
Bounces | Sender records | Invalid recipients and blocks |
Complaints | Mailing data | Audience permission quality |
Blocklists (blacklists) | Reputation checks | Public listing status, not Gmail's internal reputation |
Useful evidence sources for a Google Workspace spam investigation.
Google Admin console Gmail routing, compliance, spam, and quarantine settings.
Trace spam placement with Email Log Search
Use Email Log Search (ELS) to trace an affected message through Workspace. Google's Email Log Search documentation covers delivery events and post-delivery status.
- Save the Message-ID, recipient address, and send time from an affected sample.
- In Admin console > Reporting > Email Log Search, use Custom Search with the Message-ID and recipient. The Gmail Settings administrator privilege is required.
- Open recipient details to distinguish acceptance, rejection, and quarantine. For users in your organization, inspect post-delivery status for message location, spam labels, or deletion.
- Compare with an inbox sample. For a group address, trace individual members separately because group search results do not show every member's delivery outcome.
Delivery to an external mail server does not prove inbox placement; ask the recipient for the received message. Save evidence promptly: delivery logs are unavailable after 30 days. Older-message searches require the recipient and Message-ID and return post-delivery status only. ELS does not display message contents.
Check Google's current sender requirements
Compliance does not guarantee inbox placement. These requirements cover mail sent to personal Gmail accounts, including mail sent through Google Workspace; they do not apply to inbound or internal Workspace mail. Google increased enforcement in November 2025. Check Google's sender FAQ before testing subject lines or templates.
- All senders: Use SPF or DKIM, valid forward and reverse DNS, TLS, RFC 5322 message formatting, and an honest From identity.
- Bulk senders: Google counts about 5,000 or more messages to personal Gmail accounts in 24 hours across a primary domain and its subdomains. Bulk status is permanent once assigned. Configure SPF and DKIM plus DMARC at p=none or stronger; direct mail must pass DMARC's domain-matching rules.
- Marketing and subscribed mail: For bulk marketing and subscribed mail, implement RFC 8058 one-click unsubscribe with List-Unsubscribe and List-Unsubscribe-Post headers and an HTTPS endpoint, plus a visible unsubscribe link in the body. Process unsubscribe requests within 48 hours.
- Spam rate: Keep Gmail's daily user-reported spam rate below 0.10% and prevent it from reaching 0.30% or higher.
Google manages reverse DNS and TLS for mail sent directly through Workspace. Check those settings separately on any external SMTP server or relay in the sending path.
Passing the checklist is the floor
SPF, DKIM, DMARC, TLS, and unsubscribe compliance remove common causes of filtering. Gmail can still place authenticated, compliant mail in spam when complaints, recipient permission, content, or sending patterns indicate unwanted mail.
Read the headers before changing DNS
Before changing SPF or DKIM, collect original headers from a spam sample and an inbox sample sent around the same time. In desktop Gmail, open the message, select More next to Reply, then Show original. Compare Authentication-Results, Return-Path, the visible From domain, the DKIM signing domain, and any Google-specific fields that are present.
Header clues to comparetext
X-Gm-Spam: 0 X-Gm-Phishy: 0 Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
How to read X-Gm-Spam and X-Gm-Phishy
Google Workspace can add X-Gm-Spam and X-Gm-Phishy when an administrator enables those headers on applicable routing rules. When present, 0 and 1 indicate status rather than a graduated quality score. Their absence does not prove that Google skipped spam or phishing checks.
If the required authentication checks pass, investigate content, audience quality, sending patterns, and recipient rules. SPF can fail after forwarding while a matching, valid DKIM signature still lets DMARC pass. Trace the failing hop before editing DNS, then retest with a fresh message because an existing message retains its original authentication results.
Google Workspace spam troubleshooting flowchart: collect headers, check authentication, review rules, test content, check reputation, and retest.
Prove authentication with a real sample
For Google Workspace, verify SPF against the envelope-sender domain, DKIM against the signing domain, and DMARC against the visible From domain. DMARC passes when at least one passing SPF or DKIM domain meets its domain-matching rules. Relaxed mode accepts the same organizational domain; strict mode requires an exact domain match. Inspect a received message as well as DNS.
Suped's domain health check catches missing or malformed SPF, DKIM, and DMARC records. After that, send a real test so you can compare what DNS says with what Google actually receives.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Example DNS records to verifytext
Host: example.com Type: TXT Value: v=spf1 include:_spf.google.com ~all Host: google._domainkey.example.com Type: TXT Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_GOOGLE Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
These are example values. The SPF example authorizes only Google's servers; publish one SPF record per envelope-sender domain with every authorized source and stay within SPF's 10 DNS-lookup limit, including nested includes. Use the actual DKIM selector and public key generated for the sending domain. For a new DMARC rollout, use p=none while inventorying sources, then move toward quarantine or reject after legitimate mail passes consistently. The example omits pct, which RFC 9989 marks as historic.
In Admin console > Apps > Google Workspace > Gmail > Authenticate email, select the sending domain, generate a 2048-bit key where supported, and publish the TXT record. After DNS is available, click Start authentication and verify a fresh message sent to a separate Gmail or Workspace recipient. Publishing the key alone does not activate signing. Follow Google's SPF and DKIM setup steps. If recipients see 'via google.com' or 'on behalf of', inspect the signing domain; the label alone does not prove a DKIM failure.
Suped's product supports this workflow by combining DMARC monitoring with SPF and DKIM diagnostics, alerts, and issue-specific repair steps. That makes it easier to identify the sending source behind a failure and verify the result after a DNS or sender change. DMARC aggregate reports show authentication results, not whether individual messages reached the inbox or spam folder.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Separate configuration problems from reputation problems
Once authentication is clean, the work becomes less about DNS and more about sending behavior. Google Workspace mail can still land in spam if the domain has poor recipient feedback, stale recipients, high complaint rates, suspicious links, sudden volume jumps, or shared sending infrastructure with a weak history.
Configuration issue
- Symptom: Headers show SPF, DKIM, or DMARC failing.
- Cause: DNS or sender settings are wrong, or a forwarding hop changed authentication.
- Fix: Identify the failing hop, correct the relevant record or sender configuration, and retest.
- Risk: Broad DNS edits can break senders that were already healthy.
Reputation or content issue
- Symptom: Authentication passes, but Gmail still places messages in spam.
- Cause: Audience quality, complaints, engagement, links, or volume changed.
- Fix: Reduce risky sends, isolate templates, clean lists, and warm volume.
- Risk: DNS changes waste time while reputation continues to decline.
Also check domain and IP listing status. A blocklist (blacklist) entry does not automatically explain Gmail spam placement, but it is supporting evidence when bounce text identifies the same listing. Suped's blocklist monitoring keeps public listing evidence near DMARC data for the same investigation.
When to suspect reputation
Use these operational thresholds as triage signals, not as fixed Google rules.
Low concern
Isolated
Authentication passes and only isolated recipients report spam.
Watch closely
Clustered
Spam reports cluster around one template, link, segment, or campaign.
High concern
Broad
Spam placement appears across many recipients after a volume or list change.
Inspect bounces, lists, links, and templates
If the traffic is cold outreach, fix the permission and targeting problem first. For permission-based mail, look for patterns in bounces, unsubscribes, complaints, replies, clicks, inactive recipients, suppressions, domains, and templates. Google does not track opens or verify third-party open-rate reports, so low opens alone do not diagnose spam placement.
- Bounce patterns: Group full SMTP responses by recipient domain and reason. Separate 4xx temporary deferrals from 5xx permanent rejections; Gmail's 5.7.26 error points to an authentication problem. A rejection differs from a message delivered to Spam.
- Suppression quality: Confirm unsubscribed, bounced, complained, and inactive recipients are not being mailed again.
- Engagement shifts: Compare replies, clicks, unsubscribes, and complaint patterns against the same audience and message type.
- Content tests: Send controlled variants that change one thing at a time, such as one link or one template block.
- Domain clues: Compare sibling domains, subdomains, and shared tracking domains for the same placement pattern.
Do not test five changes at once
Change one variable, send to a controlled segment, and wait for enough responses to compare. If you change the subject, link, audience, sender, and volume in the same test, you will not know which factor changed placement.
Bad links are easy to miss. A single compromised destination, aggressive redirect chain, file-sharing link, URL shortener, or mismatched tracking domain can pull a clean Google Workspace sender into spam. Test the same body with no links, then with each link added back one at a time.
Check recipient-side Workspace settings
If the affected recipients are inside a Google Workspace tenant you control, inspect receiving rules before blaming sender reputation. Admin-level allowlists, blocklists (blacklists), spam settings, compliance rules, attachment rules, routing rewrites, and quarantine settings can move a message after Gmail receives it.
For an isolated recipient, capture any spam warning before asking them to mark a legitimate message Not spam and add the trusted sender to Contacts. Review Settings > See all settings > Filters and blocked addresses for a conflicting user setting. These actions are part of Google's spam troubleshooting guidance and affect that recipient's handling of future messages.
|
|
|
|---|---|---|
Spam settings | Tenant policy | Masking sender issues |
Routing | Delivery path | Bypassing authentication |
Compliance | Policy checks | Bulk sender repair |
Quarantine | Admin review | Inbox placement proof |
Google Workspace controls to review before changing sender setup.
For internal mail, verify which app or SMTP relay actually sent the message; a shared From domain alone does not establish authenticated internal traffic. For group addresses, check Google Groups > Group settings > Posting policies > Spam message handling and Conversations > Pending. Google's group moderation instructions explain why messages can be held even with No moderation selected. A group rejection or moderation hold is separate from a member's Gmail Spam folder.
Allowlisting can be useful for a verified sender in a controlled workflow, but it does not repair broad Gmail placement. Google can still reject or route a suspicious message to spam even when the sender is allowlisted. An allowlist also leaves the sender reputation or content issue untouched everywhere else.
A practical troubleshooting workflow
When a Google Workspace sender has no useful reputation dashboard data, do not treat that as a dead end. Build a timeline of DNS changes, campaign sends, volume changes, template edits, link changes, complaint spikes, bounce spikes, and recipient reports.
- Collect samples: Save original headers from messages that reached spam and messages that reached inbox.
- Confirm auth: Verify SPF, DKIM, and DMARC using both DNS and received headers.
- Map changes: List every sending, content, audience, and DNS change made before placement shifted.
- Segment tests: Test one recipient group, one template, and one link set at a time.
- Reduce risk: Pause the worst segment, suppress inactive contacts, and lower volume while retesting.
- Measure again: Compare fresh samples after each change instead of relying on old message headers.
What usually fixes it
The most reliable fixes are usually boring: make authentication pass, remove stale recipients, stop mailing people who did not ask for mail, remove risky links, stabilize volume, and give Gmail cleaner recipient feedback over time.
For compliant bulk mail with persistent false positives and low user spam reports, use the Google sender contact form for a mitigation request. Include full headers from a misclassified message less than 12 days old, any SMTP rejection, affected sending IPs, and the changes already made. A submission does not guarantee mitigation. For low-volume or internal Workspace mail, contact Workspace support through Admin console with the Message-ID, recipient, timestamp, and Email Log Search results.
For deeper Gmail-specific recovery steps, the related pages on Gmail spam fixes and Gmail inbox placement are useful once you know whether the issue is authentication, audience, content, or reputation.
Views from the trenches
Best practices
Collect full headers from spam and inbox samples before changing DNS, content, or routing rules.
Compare bounces, suppressions, unsubscribes, complaints, and replies by sending segment.
Test links and templates in small batches so one weak URL does not taint every send.
Keep Google Workspace DKIM active and review DMARC reports after every sender change.
Common pitfalls
Treating missing reputation dashboard data as a dead end instead of using message evidence.
Assuming X-Gm-Spam appears in every header or exposes a graduated score for diagnosis.
Fixing DNS first when the real issue is cold mail, weak permission, or stale recipients.
Allowlisting a sender in one tenant and assuming the wider Gmail problem has been fixed.
Expert tips
Split tests by recipient group, template, and link set to isolate the smallest failing unit.
Review neighboring domains and shared sending paths when one domain has no direct clues.
Use DMARC reports to prove source identity before judging content or audience quality.
Record each change with the send date so inbox shifts have a clear cause to inspect.
Marketer view
Marketer from Email Geeks says IP and domain reputation, list quality, and complaint signals still matter when Google Workspace data is thin.
2024-03-11 - Email Geeks
Marketer view
Marketer from Email Geeks says missing reputation dashboards do not remove the need for bounce analysis, suppression checks, and segment review.
2024-03-11 - Email Geeks
