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 all qualifier (-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.

Start Monitoring

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 ~all without delivery issues
  • You want maximum protection against spoofing
QualifierSyntaxProtection LevelRisk of Blocking Legit Email
-all (Hard Fail)v=spf1 ... -allHighestHigher — blocks unauthorized senders
~all (Soft Fail)v=spf1 ... ~allMediumLower — flags but doesn't reject
?all (Neutral)v=spf1 ... ?allNoneNone — 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.

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