SPF Record Examples

This page provides copy-paste SPF record examples for the most common sender setups. Each example is ready to adapt: replace the domain in include mechanisms with your provider's exact hostname, and ensure you publish only one SPF record for your domain. These examples cover single-provider and hybrid configurations for Google Workspace, Microsoft 365, SendGrid, and similar services.

One-Minute Fix

Choose the example that matches your sending setup, adapt the include mechanisms if needed, and publish it as a single TXT record at the root of your domain.

Google Workspace only
DNS TXT
v=spf1 include:_spf.google.com ~all

This authorizes Google's mail servers to send for your domain. For Microsoft 365 only, use include:spf.protection.outlook.com. For both, merge the includes into one record.

Re-check

Wrong vs correct setup

Generic or incomplete example

Generic or incomplete example
DNS TXT
v=spf1 include:example.com ~all

This is wrong because example.com is a placeholder. The include hostname must be the exact value published by your provider, such as _spf.google.com or spf.protection.outlook.com.

Google + SendGrid hybrid

Google + SendGrid hybrid
DNS TXT
v=spf1 include:_spf.google.com include:sendgrid.net ~all

This pattern works when both Google Workspace and SendGrid send mail for your domain. Add one include per provider and end with ~all or -all.

Why examples matter

New teams often copy the wrong include hostname, publish multiple SPF records, or omit the final qualifier. Working examples reduce mistakes and show the correct structure for single-provider and hybrid setups.

Why getting the example wrong is a problem

  • Wrong include hostnames cause SPF to fail for legitimate senders.
  • Multiple records lead to permerror instead of pass or fail.
  • Missing or wrong qualifiers leave policy ambiguous for receivers.
  • Using a generic template without adapting it breaks authentication.

How correct examples help deliverability

Receivers expect SPF to authorise the actual sending IPs. When your record matches a proven pattern and uses the correct include hostnames, authentication passes consistently and DMARC alignment becomes easier to achieve.

Common mistakes with examples

  • Copying an example without replacing placeholder domains.
  • Adding a second SPF record instead of merging includes.
  • Using an outdated include that the provider no longer supports.
  • Ending with ?all or omitting the all mechanism entirely.

What we checked

We validated that these examples use valid SPF syntax and provider hostnames that are currently in use. Always confirm the exact include from your provider's documentation before publishing.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

Can I use these examples for any domain?

Yes, but replace any placeholder domain with your actual domain. The include hostnames (e.g. _spf.google.com) stay the same across domains.

What if I use more than two providers?

Add one include per provider, but stay under the 10-DNS-lookup limit. If you exceed it, consider flattening or consolidating providers.

Should I use ~all or -all?

Use ~all while validating all senders; -all when your record is complete and you want strict enforcement.

Next steps

  • List every service that sends email for your domain.
  • Choose the matching example or combine includes from several.
  • Publish one SPF TXT record at the root of your domain.
  • Run a live check to confirm the record is valid.
  • Re-check after adding or removing providers.
  • Review the full troubleshooting guidance in the SPF Hub.
  • Check signing and selector issues in the DKIM Hub.
  • Review alignment and policy issues in the DMARC Hub.

Related fixes

Explore more issues