SummaryStart with Google’s SPF guidance, identify each service’s envelope-sender domain, and change only the relevant policy. A service sending from its own domain may need no addition to your root SPF record.
In this guide
Start with the Google Workspace baseline
If Google Workspace is the only service sending for the relevant domain, Google’s documented SPF value is:
v=spf1 include:_spf.google.com ~allSPF is published as a TXT record at your DNS host. There is no SPF switch in the Google Admin console that replaces this DNS step. Follow Google’s current setup instructions for the basic configuration.
The more useful question for a business with several services is: which domain does each service ask the recipient to check? That determines whether it belongs in the same SPF policy as Gmail.
Make a sender map, not just an app list
A fictional studio uses Gmail, an invoicing platform and a newsletter service. All three display an address ending in @studio.example, but their envelope senders differ:
| Workflow | Envelope-sender domain | Policy to investigate |
|---|---|---|
| Gmail mailbox | studio.example | The studio’s root SPF policy. |
| Invoice notification | bounce.studio.example | The return-path subdomain’s setup. |
| Newsletter | mailer.example | The provider-owned policy; check custom DKIM for alignment with the studio. |
In this example, adding both third-party providers to the root policy would not change the SPF policy evaluated for those messages. Use their actual setup instructions and received headers to establish the right DNS names.
This distinction exists in real products. Amazon SES, for example, documents a provider-owned default MAIL FROM domain and a separate setup for a custom MAIL FROM domain. That illustrates the identity decision; it is not a claim that SES is supported by Emailmetry. See Amazon’s SPF explanation.
When another service really needs the same SPF record
Suppose a website delivery service uses studio.example as its envelope-sender domain and gives the owner a required include. The combined policy might have this shape:
v=spf1 include:_spf.google.com include:forms.example ~allforms.example is a placeholder. Replace it with the real service’s required value only when it belongs at this name.Keep one SPF TXT record. Do not paste a second complete v=spf1 policy alongside Google’s record. Before publishing, check nested dependencies and the lookup limit; the number of visible includes is not the complete count.
Keep the final qualifier deliberate. The example uses Google’s documented ~all. If your existing policy uses -all, investigate why it was chosen instead of changing it incidentally while adding a service. The receiving system decides what to do with a softfail or fail result.
Google Workspace and Microsoft 365 during a migration
If both services genuinely send using the same envelope-sender domain during a transition, the policy can include both. For a commercial Microsoft 365 environment, an illustrative transition policy is:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~allSPF does not route incoming email. Adding Google’s include does not move mailboxes, and removing an old provider’s MX record does not prove that it has stopped sending. Check scheduled jobs, application credentials and queues before withdrawing an old authorisation.
Keep both providers configured for DKIM as needed, and send external tests from each before and after the cutover. Use the provider-change checklist to capture the transition and eventual retirement.
Website forms need a real sending identity
A form that puts a visitor’s address in From can create an authentication problem unrelated to your Google SPF record. Your website cannot authorise itself to send as every visitor’s domain. Configure the delivery service to use an authenticated address you control for From, with the visitor’s address in Reply-To when a reply is appropriate.
Then verify how the form is delivered. It might submit through Google, use a separate SMTP provider or send directly from a web server. The web server’s public IP is not automatically an SPF requirement when another service performs the actual delivery.
Publish and verify the complete setup
- Save the baseline. Keep the current policy, its DNS name and TTL, and your sender map.
- Update the correct TXT record. Follow your DNS host’s naming convention. Check that a subdomain or domain suffix has not been added twice.
- Inspect public DNS. Confirm one policy at each intended sending name and review its dependencies with the SPF checker.
- Send fresh messages. Test Gmail, forms, invoices and newsletters separately at an external mailbox you control.
- Inspect authentication and alignment. In Gmail’s web interface, open the received message’s More menu and use Show original. Keep the SPF, DKIM and DMARC results and their associated domains.
If publication looks correct but authentication still fails, investigate the actual route and diagnostic result using Google’s SPF troubleshooting guidance. Do not interpret a single Gmail success as evidence that every other service works.
Google Workspace is included in Emailmetry’s launch plans. You still configure DKIM and DMARC with your sending services. For ongoing management of compatible SPF policies, see how Emailmetry works and register interest.