Most Google Workspace admins know how to add users and set up MX records. Fewer know about the Workspace Admin Console settings that directly affect whether outgoing email from their organisation reaches inboxes or gets filtered.
This matters most for organisations that send significant volume from Google Workspace accounts: sales teams running cold outreach, marketing operations sending newsletters via SMTP relay, and product teams sending transactional email through Workspace infrastructure.
The controls exist. They are not in the main navigation. This guide covers the specific Admin Console settings that affect deliverability, how to configure them correctly, and what they interact with in your broader email programme.
How Does Google Workspace Handle Outgoing Email Differently from Free Gmail?
Google Workspace and free Gmail share infrastructure but behave differently for email senders in several important ways.
Free Gmail accounts are consumer accounts. They send from Google’s shared IP pool. The sending domain is gmail.com, which has Google’s own reputation. Individual users do not control authentication or sending infrastructure.
Google Workspace accounts send from your organisation’s custom domain. Your domain’s reputation is what inbox providers assess when deciding where to deliver your email. You control the authentication records, the sending configuration, and, through the Admin Console, additional settings that affect outgoing email behaviour.
This is both a capability and a responsibility. Workspace gives you professional sending infrastructure. It also means that the deliverability of your organisation’s email is determined by how you configure and manage that infrastructure.
The Admin Console Settings That Affect Deliverability
Access the Google Workspace Admin Console at admin.google.com. The relevant settings are primarily under Apps > Google Workspace > Gmail.
The sections that matter for deliverability are:
- Authenticate email (SPF, DKIM, DMARC)
- Advanced settings > Outbound gateway
- Compliance > Spam
- Routing
Each section controls a different aspect of how outgoing email behaves. Most organisations leave several of these at default which means they are missing configuration opportunities that would improve deliverability.
SPF Configuration for Workspace Domains
SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are authorised to send email on behalf of your domain.
Google provides a specific SPF include for Workspace senders:
`v=spf1 include:_spf.google.com ~all`
This should be published as a TXT record on your domain. If you are also sending email from other sources — an ESP like Mailchimp or Klaviyo, a CRM like HubSpot, or a transactional email service like SendGrid — you must add their include values to your SPF record.
The SPF Lookup Limit Problem
SPF records may contain a maximum of 10 DNS lookup operations (include, a, mx, ptr, and exists mechanisms each count as one lookup). Every include statement triggers at least one additional lookup. Many organisations accumulate SPF includes from multiple tools over time and exceed the 10-lookup limit.
When the lookup limit is exceeded, SPF evaluation fails with a “permerror” result — which receiving servers may treat as an SPF failure. This directly affects deliverability for any emails sent from your Workspace accounts through tools that rely on SPF alignment.
Check your current SPF record and lookup count using MX Toolbox’s SPF lookup tool (mxtoolbox.com/spf.aspx). If you exceed 10 lookups, use an SPF flattening service to convert dynamic include references to static IP ranges, keeping the lookup count within limits.
DKIM Signing in the Admin Console
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email that receiving servers verify to confirm the message is authentic and unmodified.
Google Workspace generates and manages your DKIM keys through the Admin Console under Authenticate email > Generate new record.
Configuring DKIM in Workspace
1. In the Admin Console, go to Apps > Google Workspace > Gmail > Authenticate email
2. Select your domain
3. Click “Generate new record”
4. Choose a 2048-bit key (this is the recommended standard — 1024-bit is no longer sufficient for modern deliverability requirements)
5. Google provides a TXT record value to publish in your DNS
6. Publish the record and return to the Admin Console to start authentication
Allow 24–48 hours for DNS propagation, then verify DKIM is functioning by sending a test email and checking the DKIM-Signature header in the email source.
DKIM and Third-Party Sending Tools
When you send email through a third-party tool (your ESP, a CRM, a support platform) using your Workspace domain in the From address, that tool must sign the email with DKIM for your domain — not its own DKIM key — for DMARC alignment to work correctly.
Most major ESPs support custom DKIM signing for your domain. This requires generating a separate DKIM key pair for the ESP and publishing the public key in your DNS. Without this, emails from third-party tools using your domain in the From address will fail DMARC alignment even if Google’s DKIM signing is correctly configured.
DMARC Policy and Alignment for Workspace Senders
DMARC tells inbox providers what to do with email that fails SPF or DKIM authentication checks. It also provides reporting that shows you which sources are sending email on behalf of your domain.
DMARC is configured as a TXT record at `_dmarc.yourdomain.com`.
Starting Configuration
Begin with a monitoring-only policy:
`v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com`
This collects aggregate reports from inbox providers without affecting email delivery. Aggregate reports (RUA) are XML files that show which IP addresses sent email claiming to be from your domain, and whether SPF and DKIM passed or failed for those senders.
Review aggregate reports weekly for 4–6 weeks. This reveals:
- Which of your tools are passing authentication correctly
- Which tools are sending email under your domain name without proper authentication
- Whether any unauthorised senders are using your domain
Once you have confirmed all legitimate sending sources pass authentication, move to:
`v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com`
Then, after 2–4 more weeks of clean reporting:
`v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com`
A p=reject policy provides the strongest protection against domain spoofing and is the target configuration for all Workspace senders who have completed the full authentication setup.
Outbound SMTP Gateway Configuration
Google Workspace allows you to route outgoing mail through a third-party SMTP relay or gateway. This is used by organisations that want to:
- Route outbound email through a dedicated IP address
- Apply content filtering before delivery
- Send high-volume transactional email through an ESP’s infrastructure while keeping Workspace as the sending identity.
Find this setting under Apps > Google Workspace > Gmail > Hosts and Advanced settings > Outbound gateway.
When Outbound Gateway Affects Deliverability
If your organisation uses an SMTP relay or gateway, ensure the relay’s IP addresses are included in your SPF record. Email sent through a relay that is not in your SPF record will fail SPF authentication.
Additionally, if the relay provider signs email with their DKIM key rather than your domain’s key, verify that the DKIM signing domain aligns with your From header domain for DMARC purposes. Misalignment here is a common cause of DMARC failures on relay-routed email.
Spam and Content Compliance Settings That Affect Reputation
Under Apps > Google Workspace > Gmail > Spam, phishing and malware, Workspace admins can configure inbound spam settings. These settings do not directly affect outbound deliverability.
However, the Compliance section contains settings that do have outbound implications:
Content Compliance Rules
Content compliance rules can modify outgoing email — adding headers, routing to specific servers, or quarantining messages that match defined patterns. If you have content compliance rules configured from a previous administrator or a security implementation, verify that they are not unintentionally modifying your authentication headers or altering email content in ways that would cause DKIM signature failures.
DKIM signatures hash the email content. Any modification to the email after signing — including header additions from content compliance rules — invalidates the DKIM signature. Review your content compliance rules and confirm that any modifications occur before DKIM signing, not after.
Email Routing and Its Deliverability Implications
Google Workspace’s email routing settings allow you to split or redirect email flow based on various conditions. Routing configurations that send outbound email to an SMTP relay or an alternate MX have authentication implications identical to those described in the Outbound Gateway section above.
A common routing misconfiguration: setting up a split delivery arrangement where some outbound email goes through Workspace’s own infrastructure and some goes through a relay, with SPF configured only for one path. Email taking the unconfigured path fails SPF.
Review your routing configurations under Apps > Google Workspace > Gmail > Routing. Map every outbound email path and confirm that SPF and DKIM authentication are configured correctly for each path.
Key Takeaways
- Google Workspace gives you control over authentication and sending configuration that free Gmail does not. This is a capability that requires active management to deliver its benefits.
- SPF must include all authorised senders, Google, and every third-party tool using your domain. Watch the 10-lookup limit and use SPF flattening if exceeded.
- DKIM should be configured with a 2048-bit key in the Admin Console. Third-party tools using your domain in the From address need their own DKIM configuration with your domain’s keys for DMARC alignment.
- DMARC should progress from p=none (monitoring) to p=quarantine to p=reject as you confirm all legitimate sending sources pass authentication. A p=reject policy is the target for all production Workspace senders.
- Content compliance rules and email routing configurations can invalidate DKIM signatures if they modify email content after signing. Audit these configurations if DKIM pass rates are below 95% in Postmaster Tools.
- Outbound SMTP gateway and relay configurations require SPF record updates and relay-specific DKIM configuration to maintain authentication across all outbound email paths.
Frequently Asked Questions
Workspace provides the infrastructure for better deliverability with a custom domain and proper authentication controls. But the configuration work is yours. An unconfigured Workspace domain with no DKIM, a broken SPF, and no DMARC will perform worse than a well-configured programme using a different platform, because the custom domain has no reputation benefit without authentication.
Use Google’s Admin Toolbox at toolbox.googleapps.com — specifically the Check MX tool. Also review the Authentication section in Postmaster Tools (postmaster.google.com) for live SPF, DKIM, and DMARC pass rates on email actually received by Gmail users.
Yes. DKIM configuration is per domain. If your organisation sends email from primary.com and subsidiary.com through the same Workspace account, both domains need separate DKIM key generation and DNS configuration. Postmaster Tools also tracks reputation separately per domain.
Yes, if the cold email is sent using your primary business domain in the From address. Best practice for cold outreach is to use separate domains (alternate domains purchased specifically for outreach) rather than your primary business domain. This isolates any reputation impact from outreach to the outreach domain, keeping your primary domain’s reputation clean for transactional and marketing email.
Conclusion
Google Workspace’s deliverability controls are mature and effective,e but they are not self-configuring. The default Workspace setup does not include DKIM, does not enforce a DMARC policy, and does not validate that all outbound email paths are authenticated.
The configuration work described in this guide takes a few hours to complete properly. The result is a sending infrastructure where authentication passes for all outbound email, DMARC reports provide ongoing visibility into your sending ecosystem, and inbox providers receive consistent authenticated signals that build your domain’s trust over time.
That trust is what delivers your email to the inbox, consistently, campaign after campaign.
