Google Workspace SPF Setup: Authorize Every Real Sender

Overview

SPF evaluates the envelope domain against the connecting IP. It does not read the visible From address directly and does not sign the message. Google Workspace's include authorizes Google's current sending infrastructure, but it says nothing about another provider unless that provider is also represented in the same SPF policy.

The safe setup process begins with an inventory. Identify Google Workspace, website forms, transactional applications, support desks, CRM systems, marketing providers, relays and appliances. Use each provider's current official SPF instruction; do not invent include domains from brand names or copy values from an unrelated tenant.

Why it happens

A domain often adds Google first and later adopts more sending systems. Publishing a second v=spf1 TXT record seems simple but makes SPF invalid. Adding every possible include is also unsafe because it expands authorization and can exceed SPF's DNS-lookup limit. The record must represent actual sources only.

How to fix it

Search the public DNS for every v=spf1 value and consolidate to one policy. Keep Google's include when Google Workspace sends mail. Add only the exact mechanisms documented by other active providers, remove retired sources after verifying they no longer send, and test recursive lookup count and syntax. Then send a real message from each platform and inspect Authentication-Results; SPF pass alone is not enough for DMARC unless the envelope domain aligns with From.

DNS record example

Examples

Google-only example from current official documentation: v=spf1 include:_spf.google.com ~all. A multi-provider policy must be assembled from the exact current documentation of the other active platforms. This guide intentionally does not guess or prescribe their include values.

Common mistakes

Common mistakes include publishing multiple SPF records, replacing Google's include with guessed IPs, forgetting a CRM or website sender, leaving retired platforms authorized indefinitely, exceeding the DNS-lookup limit, or assuming SPF pass guarantees DMARC alignment or inbox placement.

Checklist

• List every service that sends using the domain.
• Confirm whether Google Workspace actually sends outbound mail for the domain.
• Publish exactly one v=spf1 TXT policy at the intended hostname.
• Use Google's documented include:_spf.google.com value for Google Workspace mail.
• Add other senders only from their current official setup documentation.
• Check syntax and the recursive DNS-lookup budget before publishing.
• Verify SPF and DMARC alignment from a real message sent by every platform.

When the Google-only policy is sufficient

The documented Google-only value is appropriate only when every message using that SPF domain is sent through Google-authorized infrastructure. Receiving mail in Google Workspace does not by itself prove that every outbound application also sends through Google.

Adding other sending platforms safely

Keep one SPF record. Add the other service's documented mechanism to that policy, validate the expanded record, and remove it when the service is retired. If a provider offers DKIM, enable it as well so DMARC does not depend on one fragile authentication path.

SPF pass versus DMARC alignment

SPF can pass for an envelope domain that differs from the visible From domain. DMARC uses aligned SPF or aligned DKIM. Inspect the Authentication-Results and Return-Path of real messages rather than relying only on a DNS lookup.