How to maintain SPF for Google Workspace
Keep Workspace authorization maintainable, check the correct sending domain, and avoid duplicate SPF records.
Before adding Google's SPF include, establish whether Google Workspace actually sends mail for the domain you are configuring. The recipient being a Gmail user is not a reason to authorize Google as your sender.
Start with the supported include
Google documents this SPF record for a domain whose mail is sent only through Google Workspace:
v=spf1 include:_spf.google.com ~allIf other services also send for the same SPF identity, the record needs to account for them. Build that inventory before replacing an existing record with the Google-only example. Source: Google Workspace SPF setup.
For each route, note its owner, purpose and envelope sender domain. Include employee mail, application notifications, support software and marketing platforms. A service may use its own return-path domain or a dedicated subdomain, so check an actual message before deciding which DNS record needs editing.
Keep one SPF policy at each name
SPF evaluates the envelope identity, which can differ from the visible From address. The standard does not allow multiple SPF records at the same DNS name. It also limits the DNS-querying mechanisms and modifiers evaluated during a check to ten, including nested evaluations. This is not simply a count of top-level includes. Source: RFC 7208, sections 2.4, 3.2 and 4.6.4.
When onboarding another sender, review the existing policy with the domain owner. Do not paste a second v=spf1 record beside the first one. Other TXT records, such as verification tokens, are separate from this restriction.
Avoid maintaining Google's internal list yourself
My recommendation is to retain Google's documented include rather than replacing it with the IP addresses or internal include names returned by a one-time DNS lookup. A copied snapshot creates an extra maintenance task: someone must keep it synchronized when the provider changes its infrastructure.
If a managed SPF service is involved, ask who tracks upstream changes and how failed updates are reported. Do not remove an unfamiliar authorization until the sending inventory establishes whether it is still needed.
Verify the route after changing DNS
Save the previous record and the reason for the change. Query the exact DNS name you edited, then send a fresh example from each affected workflow.
Record the observed SPF identity and result from the received message. If the identity differs from the domain you edited, investigate the platform's return-path configuration before making another DNS change.
Keep the existing SPF, DKIM and DMARC guide alongside this checklist. This maintenance task covers one part of authentication; the final message checks should still cover the full sending setup.