Google Workspace (ex-G Suite) is the most deliverability-friendly environment an SMB can pick. Google signs the outgoing mail, hosts the infrastructure, and reports reputation in Postmaster Tools. Gmail-to-Gmail placement from a Workspace domain is essentially always Inbox. But Workspace doesn't make you immune to deliverability issues — it concentrates them. One misconfigured DKIM record or one overloaded IP pool in Postmaster and your entire company's outbound mail drops off a cliff simultaneously.
Workspace mail uses Google's shared IPs with Google's own DKIM by default, or your custom DKIM selector if you configured one. Gmail-to-Gmail is self-reinforcing (good or bad). External placement to Outlook, Yahoo, Mail.ru depends on your DKIM + DMARC setup and needs seed testing. Re-test after every DKIM rotation and DMARC policy change.
Workspace sending paths you should know
Even inside one Workspace tenant, mail can leave Google through several paths, and each one has different filter behaviour on the receiving side.
- User @domain sends from Gmail web / mobile. Standard outgoing SMTP through Google, signed with your domain's DKIM if enabled, otherwise with
gappssmtp.com. - SMTP relay via smtp-relay.gmail.com. Used by apps (CRMs, web apps, servers) to send as your Workspace domain. Requires an SMTP relay service configuration in the admin console and proper SPF.
- App-specific passwords through smtp.gmail.com. Legacy. Still works but strongly discouraged in favor of OAuth or SMTP relay.
- Routing / third-party sends as your domain. Marketing tools that use your Workspace as a gateway or via SMTP relay — these inherit your reputation. Be picky about who gets this access.
The DKIM rotation trap
The single most common Workspace outage we see: admin goes into the Gmail admin panel, starts DKIM setup, adds a new selector to DNS — and either publishes the wrong TXT or flips the switch before DNS has propagated. The result is mail going out signed with a key that doesn't resolve. DKIM fails. DMARC fails (if aligned). Gmail continues to accept your own mail because it's internal. But Outlook, Yahoo, Mail.ru, Proton all start dropping your messages immediately.
- Publish the new selector TXT first. Wait 15–30 min for DNS to propagate globally.
- Confirm
google._domainkey.yourdomain(or your chosen selector) resolves from multiple resolvers. - Then hit "Start authentication" in the admin panel.
- Run a seed test immediately. Verify
dkim=passacross external providers, not just Gmail. - Keep the old key in DNS for a grace period (24–48h) to cover in-flight messages.
Gmail-to-Gmail vs external delivery
Workspace creates a deceptive "everything is fine" signal. Your internal team can keep emailing each other all day with the wrong DKIM and never see a single bounce or filtering issue. Gmail trusts its own tenants. That's why the moment an external recipient complains, you should assume the fault has been quietly active for days.
The fix is to always test to external mailboxes, not just your own. Internal send tests tell you almost nothing about deliverability — they tell you Gmail trusts itself.
How to seed-test company-wide sending
- Pick a representative sender from your Workspace domain — the user you care about most (founder, support mailbox, system sender).
- In Inbox Check, collect seed addresses for Outlook.com, M365, Yahoo, Mail.ru, Yandex, Proton. Skip Gmail seeds for this check — you already know Gmail likes you.
- Send a plain text email from the Workspace sender to all seed addresses (separate sends or BCC).
- Within seconds you'll see placement per provider and authentication status.
spf=pass dkim=pass dmarc=passacross all of them means your config is healthy. Any failure pinpoints the root cause. - Save the report. Re-run the same test after every config change (DKIM, DMARC, SPF, relay settings).
A native Workspace-oriented monitor is in private beta. It schedules a daily send from a shadow mailbox on your tenant to 20+ seed providers and alerts the moment placement regresses — before your customers complain.
Workspace deliverability fundamentals
SPF
Your domain's SPF record should include _spf.google.com and nothing it doesn't need. Maximum 10 DNS lookups total. Any redundant include (ex-MailChimp, ex-Constant Contact) left in the record is technical debt that risks SPF fail on a busy day.
v=spf1 include:_spf.google.com ~allDKIM
Enable a 2048-bit DKIM key in the admin console. The default google selector is fine. Publish, propagate, enable, verify via seed test.
DMARC
Start with p=none; rua=mailto:dmarc@yourdomain to gather reports. After a month of clean aggregates, move to p=quarantine. Only move to p=reject when you're sure no legitimate third-party sender is spoofing your domain.
MTA-STS and TLS-RPT (bonus)
Workspace fully supports MTA-STS. Publish it on mta-sts.yourdomain plus a TLS-RPT record. You get a small but measurable bump in reputation on receiving providers that care (Microsoft especially).
Postmaster Tools: your early warning
Verify your domain in Google Postmaster Tools and check it weekly. It shows your domain and IP reputation as Gmail sees it, spam rate, authentication, delivery errors. If reputation drops from High to Medium, you have about a week before you see actual placement regression. Workspace tenants often ignore Postmaster until they're already in trouble — don't.
Troubleshooting checklist
"External clients stopped replying"
Seed-test external placement first. If multiple providers show Spam, verify DKIM/DMARC. If only one provider (e.g., Outlook) flags, check that provider's postmaster (SNDS for Microsoft) for complaints.
"Some users fine, some users in spam"
Per-user reputation matters. A user who sends lots of unsubscribed cold outreach builds their own bad reputation — while the domain stays mostly healthy. Find the specific senders dragging the domain down.
"After DKIM rotation, external providers reject"
DNS didn't propagate before you enabled the new key. Re-publish the selector, wait, verify globally, then retry. Keep old key in place during transition.