InboxRatio
Check your domain

Google Workspace emails going to spam: fixing your own domain's mail, step by step

It feels like it shouldn't be possible: mail from your own company domain, sent through Google's own servers, filed into Gmail's spam folder by Google's own filter. But Workspace tenancy buys you infrastructure, not trust. The filter evaluates your domain, its authentication records, its sending history, its recipients' reactions, exactly as it would evaluate anyone else's, and a Workspace domain with unfinished DNS or bulk-sending habits gets filtered like any other weak sender. The repair sequence is short and almost entirely DNS and admin-console work; here it is in order.

Step one: finish the authentication triad

Workspace handles delivery, but the DNS that vouches for your domain is yours to publish, and each piece has a Workspace-specific gotcha:

  • SPF. Your domain's SPF record must include Google's documented sender range (include:_spf.google.com). The common failures are a missing record, a second vendor's include pushing you past the 10-lookup limit, or two SPF records published at once, which is a permerror. Validate with the SPF checker.
  • DKIM. Until you generate and activate a DKIM key in the Admin console and publish it in DNS, Workspace signs mail with a default identity rather than your domain, which cannot give DMARC an aligned pass. Generating the key takes minutes; forgetting it is the single most common Workspace authentication gap.
  • DMARC. Publish a record, starting at monitoring mode from the DMARC generator and staged upward per how to set up DMARC, reading the reports before tightening.

Confirm the whole stack from outside with the email authentication checker, then send a message to an external mailbox you control and read Authentication-Results in the email header analyzer. All three passes, with your domain in the DKIM d=, is the target.

Step two: find the other senders wearing your domain

Workspace mail is rarely a domain's only mail. Billing systems, CRMs, marketing platforms and website plugins all send "from" the same domain, and any of them failing authentication drags the domain's reputation down for everyone, including your one-to-one Workspace mail. The domain's reputation is a single shared account, and every service drawing on it either makes deposits or withdrawals; the census below shows you who is doing which. DMARC aggregate reports are the census: they show every source claiming your domain and whether each passes. Two structural fixes follow: get every legitimate service authenticated and aligned, and move bulk streams onto their own subdomains so a campaign problem cannot contaminate the root domain your staff mails from, the separation argument made throughout email deliverability best practices.

Step three: respect what Workspace is for

Google documents sending limits for Workspace accounts (on the order of 2,000 messages per account per day) and positions the product for correspondence, not campaigns. Newsletter blasts from a Workspace mailbox via BCC or mail-merge tooling produce exactly the signals filters penalize: bursty volume from a correspondence identity, no unsubscribe headers, no bounce processing, no suppression machinery. If your "Workspace spam problem" is really a bulk-mail-through-Workspace problem, the fix is structural: move the bulk stream to purpose-built sending infrastructure on its own subdomain, meet the bulk-sender requirements there, and warm the new identity before real volume. (Choosing that infrastructure is a ranking question; our benchmark's methodology covers dedicated email services, which is where the measured comparisons live.)

Step four: the behavioral layer

With DNS finished and streams separated, what remains is ordinary sender behavior, and it applies to one-to-one mail more than most people expect:

  • Recipient reactions accumulate. Even correspondence gets marked as spam when it is unwanted, and sales outreach from rep mailboxes is the usual source. Watch your domain's reputation and user-reported spam rate in Google Postmaster Tools against the published 0.3% complaint-rate ceiling.
  • Bounces tell on your address sources. Persistent hard bounces from mailing stale or prospected addresses mark the domain; the mechanics are in why emails bounce.
  • Compromise is a reputation event. A phished account quietly relaying spam will fold the whole domain's mail; unusual outbound volume in the admin reports deserves immediate attention, and the cleanup includes rotating credentials on any app passwords and third-party integrations with send-as rights, since those survive a password reset. Recovery afterward follows the usual curve: weeks of demonstrably clean sending, not a support ticket.

The forwarding wrinkle

One Workspace-specific pattern deserves its own note: mail that authenticates perfectly when sent directly but fails when it passes through forwarding, mailing lists or a migration-era relay. Forwarding re-delivers your message from the forwarder's server, which your SPF record naturally does not authorize, so SPF breaks in transit; DKIM usually survives unless the intermediary modifies the message, as mailing lists often do. This is why DMARC needs only one aligned pass, and why Google's own systems record ARC headers to preserve the original authentication verdict across hops. Practically: judge your setup by directly delivered test messages, expect some forwarded mail to show SPF failures that are the forwarder's geometry rather than your error, and keep DKIM signing healthy, because it is the mechanism that survives the trip.

If placement stays poor after all four steps, run the general diagnostic in why emails go to spam and check the domain and any dedicated infrastructure against blocklists with the blacklist checker; a full sending-side sweep with the email deliverability score makes a good closing gate.

Related guides

About this guide

Written by InboxRatio Editorial. Workspace behavior described (Admin console DKIM setup, sending limits, product positioning) follows Google's own Workspace documentation, and filtering thresholds come from Google's published sender guidelines. This guide covers legitimate correspondence and properly separated bulk streams; it offers no filter-evasion techniques. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on provider documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

27 September 2026. Provider documentation and limits reviewed quarterly.

Frequently asked questions

Why are my Google Workspace emails going to spam? Most often: SPF or DKIM never finished for the domain (especially the Admin console DKIM step), no DMARC, other services sending as the same domain and failing authentication, bulk mail pushed through a correspondence product, or accumulated recipient complaints. Work the four steps in this guide in order.

Does Google whitelist its own Workspace customers? No. Gmail's filter evaluates the sending domain's authentication, reputation and engagement regardless of whether delivery came through Google infrastructure. Workspace tenancy is hosting, not endorsement.

How do I set up DKIM in Google Workspace? In the Admin console, generate a DKIM key for your domain, publish the TXT record it issues at your DNS host, then activate signing. Confirm with a live header test that messages sign with your domain rather than a default identity.

Can I send newsletters from Google Workspace? Not at meaningful scale. Google documents per-account sending limits around 2,000 messages a day and positions Workspace for correspondence; bulk mail lacks unsubscribe and bounce machinery there and damages the domain everyone's mail depends on. Put campaigns on dedicated sending infrastructure on a subdomain.

Why does mail from one employee go to spam when everyone else's arrives? Per-message filtering weighs content and recipient reaction too: one mailbox doing high-volume outreach, mailing bought prospect lists, or having been compromised can be filtered while the domain's other mail passes. Compare headers from an affected and an unaffected message; the difference usually points at the cause.

Do I need DMARC if I only send one-to-one email? Yes, at minimum in monitoring mode. Google's requirements push all senders toward authentication, DMARC reports reveal who else is using your domain, and a policy protects your brand from spoofing that would poison the reputation your ordinary mail depends on.

Google's servers deliver your mail; only your domain's record can make Google's filter trust it. Publish the triad, separate the streams, and let the email authentication checker confirm the work is finished.