SPF Record Examples for Common Setups
Copy-paste SPF record examples for Google Workspace, Microsoft 365, SendGrid, Amazon SES, and multi-provider configurations with proper syntax.
The best way to learn SPF syntax is to see real examples. This page covers SPF records for every common scenario — single providers, multi-provider setups, self-hosted servers, and combinations you'll actually encounter in production.
Every example is a valid SPF record you can adapt for your own domain. Change the IPs and includes to match your actual sending sources. After publishing, verify your record with SPF Record Check.
Basic Structure
Every SPF record follows this format:
v=spf1 [mechanisms...] [all]
- Starts with
v=spf1 - Contains one or more mechanisms (include, ip4, ip6, mx, a)
- Ends with an
allqualifier (-all,~all, or?all)
Single Provider Examples
Google Workspace Only
v=spf1 include:_spf.google.com ~all
This is the simplest setup. If Google Workspace is your only email sender, this is all you need. The ~all softfail is what Google recommends during initial setup.
For stricter enforcement after confirming deliverability:
v=spf1 include:_spf.google.com -all
Microsoft 365 Only
v=spf1 include:spf.protection.outlook.com -all
Microsoft's SPF include covers Exchange Online, Outlook.com, and other Microsoft 365 sending infrastructure.
SendGrid Only
v=spf1 include:sendgrid.net -all
If you only use SendGrid for transactional or marketing email.
Amazon SES Only
v=spf1 include:amazonses.com -all
Amazon SES keeps it simple with a single include domain.
Mailchimp (Mandrill) Only
v=spf1 include:spf.mandrillapp.com -all
Mailchimp uses Mandrill for transactional email sending.
Postmark Only
v=spf1 include:spf.mtasv.net -all
Mailgun Only
v=spf1 include:mailgun.org -all
Always check your email provider's current documentation for the correct SPF include value. Providers occasionally change their include domains.
Multi-Provider Examples
Most organizations use more than one email service. Here's where SPF records get interesting — and where the 10 DNS lookup limit starts to matter.
Google Workspace + SendGrid
v=spf1 include:_spf.google.com include:sendgrid.net -all
A common setup: Google Workspace for employee email, SendGrid for transactional messages. This uses approximately 4 DNS lookups (Google ~3, SendGrid ~1).
Google Workspace + Mailchimp
v=spf1 include:_spf.google.com include:spf.mandrillapp.com -all
Employee email through Google, marketing campaigns through Mailchimp/Mandrill.
Microsoft 365 + SendGrid
v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all
Microsoft for corporate email, SendGrid for application email.
Google Workspace + SendGrid + Zendesk
v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com -all
Adding a helpdesk that sends email as your domain. This is around 5-6 DNS lookups.
Microsoft 365 + Amazon SES + HubSpot
v=spf1 include:spf.protection.outlook.com include:amazonses.com include:spf.hubspot.com -all
Corporate email, transactional email, and marketing automation. Watch your lookup count — this combination can approach 7-8 lookups depending on nested includes.
Every include mechanism triggers at least one DNS lookup, and the included records may contain their own includes. Google's _spf.google.com alone can use 2-3 lookups. Keep a running count to stay under 10.
Monitor your SPF record after publishing
Track your SPF, DKIM, DMARC, and MX records daily. Get alerted when something changes.
Examples with Custom IP Addresses
When you run your own mail servers or have dedicated sending IPs, use ip4 and ip6 mechanisms.
Single Server IP
v=spf1 ip4:203.0.113.50 -all
The simplest possible SPF record for a single self-hosted mail server.
Multiple Server IPs
v=spf1 ip4:203.0.113.50 ip4:203.0.113.51 ip4:198.51.100.25 -all
Three mail servers with individual IPs.
IP Range (CIDR)
v=spf1 ip4:203.0.113.0/24 -all
Authorizes an entire /24 subnet (256 addresses). Use this when your servers share a contiguous IP block.
Mixed IPs and Providers
v=spf1 ip4:203.0.113.50 ip4:198.51.100.0/28 include:_spf.google.com include:sendgrid.net -all
Your own servers plus third-party services. Note that ip4 mechanisms are listed first — they don't cost DNS lookups, so checking them first is more efficient.
IPv4 and IPv6
v=spf1 ip4:203.0.113.50 ip6:2001:db8::1 include:_spf.google.com -all
If your server sends over both IPv4 and IPv6, you need both mechanism types.
Self-Hosted Mail Server Examples
Using the mx Mechanism
v=spf1 mx -all
Authorizes whatever servers are listed in your domain's MX records. Simple, but costs DNS lookups (1 for the MX query, plus 1 per MX hostname to resolve to IPs).
Using the a Mechanism
v=spf1 a -all
Authorizes the IP address that your domain's A record points to. Useful when your web server and mail server are the same machine.
Combined Self-Hosted
v=spf1 mx a ip4:203.0.113.100 -all
Authorizes MX servers, the A record server, and a specific additional IP. This covers most self-hosted scenarios.
Prefer ip4 over mx when possible
If you know the exact IPs of your mail servers, use ip4 instead of mx. It saves DNS lookups and is more explicit about what's authorized.
Strict vs Soft Fail
The only difference between these records is the all qualifier:
Soft Fail (~all)
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Unauthorized IPs get a softfail result. Receiving servers will typically accept the message but may flag it. Use this when:
- You're still identifying all your sending sources
- You just set up SPF and want to monitor before enforcing
- You're concerned about blocking legitimate email from a source you forgot
Hard Fail (-all)
v=spf1 include:_spf.google.com include:sendgrid.net -all
Unauthorized IPs get a fail result. Receiving servers are more likely to reject the message. Use this when:
- You've confirmed all sending sources are in your record
- You've been running
~allwithout delivery issues - You want maximum protection against spoofing
| Qualifier | Syntax | Protection Level | Risk of Blocking Legit Email |
|---|---|---|---|
| -all (Hard Fail) | v=spf1 ... -all | Highest | Higher — blocks unauthorized senders |
| ~all (Soft Fail) | v=spf1 ... ~all | Medium | Lower — flags but doesn't reject |
| ?all (Neutral) | v=spf1 ... ?all | None | None — equivalent to no SPF |
Real-World Combination Examples
Startup SaaS Company
Google Workspace for team email, SendGrid for transactional, Mailchimp for marketing, Intercom for customer support:
v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mandrillapp.com include:intercom.io -all
Estimated lookups: ~8. Getting close to the limit.
Enterprise Organization
Microsoft 365 for corporate email, Amazon SES for application email, Salesforce for CRM email, custom mail relay:
v=spf1 ip4:203.0.113.0/24 include:spf.protection.outlook.com include:amazonses.com include:_spf.salesforce.com -all
Estimated lookups: ~7. The ip4 doesn't count toward the limit.
Small Business
Google Workspace and nothing else — maybe a contact form that sends through Google's SMTP relay:
v=spf1 include:_spf.google.com -all
Simple. ~3 lookups. Plenty of room.
E-Commerce Company
Shopify for storefront email, Google Workspace for team, Klaviyo for marketing:
v=spf1 include:_spf.google.com include:shops.shopify.com include:spf.klaviyo.com -all
Domain That Doesn't Send Email
If a domain never sends email (like a parked domain or redirect), publish this record to prevent spoofing:
v=spf1 -all
This tells every receiving server that no IP is authorized to send email from this domain. It's one of the most important SPF records you can set up — attackers love using parked domains for phishing. Pair it with a DMARC reject policy and a DKIM record for complete protection.
Protect all your domains
Every domain you own should have an SPF record, even domains that don't send email. A bare -all record prevents attackers from spoofing those domains.
Using the redirect Modifier
If multiple domains share the same SPF policy, use redirect to point them all at one record:
v=spf1 redirect=_spf.example.com
Then define your full policy at _spf.example.com:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.50 -all
This makes it easier to manage SPF across multiple domains — you update one record and all domains pick up the change.
Common Mistakes in SPF Records
Avoid these patterns you'll sometimes see in the wild:
# WRONG: Multiple SPF records (two TXT records starting with v=spf1)
v=spf1 include:_spf.google.com -all
v=spf1 include:sendgrid.net -all
These should be combined into one record. Having two SPF records causes a permerror.
# WRONG: Missing v=spf1 prefix
include:_spf.google.com -all
Without v=spf1, this isn't recognized as an SPF record.
# WRONG: Using +all
v=spf1 include:_spf.google.com +all
This authorizes every IP on the internet. It defeats the entire purpose of SPF.
Related Articles
Monitor Your New SPF Record
You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.
Never miss an SPF issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring