SPF Record Example: The Easy Copy and Paste Templates Guide

SPF Record Example: Working Templates You Can Copy and Use Today

Meta title: SPF Record Example: Working Templates for Every Setup

Meta description (≤155 chars): Real SPF record examples you can copy and adapt, covering Microsoft 365, Google Workspace, multi-sender setups, subdomains, and domain lockdown.

Focus keyphrase: SPF record example

Slug: /information-security-guides/spf-record-example/

Suggested featured image alt text: "SPF record example templates on a DNS console screen, iO™ information security guide"

Sometimes the fastest way to understand something is to see it. That goes double for SPF records. You can read every RFC on the internet and still end up staring at a blank DNS form wondering what to type.

This guide fixes that. Below you will find real, working SPF record examples for the most common setups we see every day, from a simple Google Workspace configuration to an enterprise-grade record covering a dozen vendors. Each example includes a syntax breakdown so you know why it looks the way it does, not just what to copy.

Use these as starting points. Adapt them to your own sending stack. Verify with our SPF Checker before you tighten the policy. Then move on with your life.

Let's get into it.

Key Takeaways

• Every SPF record follows the same shape. It starts with v=spf1, lists authorized senders in the middle, and ends with an all mechanism. Once you recognize the pattern, reading any SPF record gets easy.

• Use the real provider values, not guesses. Microsoft 365, Google Workspace, Mailchimp, SendGrid, and the rest all publish official include: mechanisms. Using the official one is always safer than hand-listing IPs.

• Keep total DNS lookups at 10 or fewer. The include:, a, mx, ptr, and exists mechanisms all count, plus the lookups nested inside every include.

• Start with ~all during rollout, move to -all once clean. SoftFail while you discover senders, HardFail once your DMARC reports confirm everything authenticates.

• Non-sending domains still need an SPF record. The lockdown record v=spf1 -all tells receivers "no one is authorized to send from this domain," which shuts down a common spoofing vector.

• Always verify before you trust. A record that looks right can still fail on a subtle syntax issue. Our SPF Checkercatches those before your users do.

Table of Contents

1. Anatomy of an SPF Record

2. Example 1: Microsoft 365 Only

3. Example 2: Google Workspace Only

4. Example 3: Microsoft 365 with Mailchimp

5. Example 4: Google Workspace with Multiple Senders

6. Example 5: Enterprise Multi-Vendor Setup

7. Example 6: Subdomain-Specific Record

8. Example 7: Non-Sending Domain Lockdown

9. Example 8: Custom Mail Server with Specific IPs

10. Mechanism Reference Table

11. What a Bad SPF Record Looks Like

12. Copy-Paste Templates

13. FAQ

Anatomy of an SPF Record

Before we get to the examples, let's decode the parts. Every SPF record has three sections.

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.25 ~all
|-----| |-------- mechanisms --------------------------------| |--|
prefix   authorized senders                                    policy

1. The prefix. Always v=spf1. That is the SPF version identifier, and without it the record is not a valid SPF record. Some older records started with spf2.0, but that standard never gained traction and modern receivers expect v=spf1.

2. The mechanisms. The middle of the record lists every source authorized to send on behalf of your domain. Each mechanism tells receivers what to consider legitimate. The most common ones are:

• include: for delegating to another domain's SPF record, most often a vendor like Google or Microsoft

• ip4: and ip6: for raw IP addresses or CIDR ranges

• a to authorize the A record of the domain

• mx to authorize all IP addresses listed as mail exchangers

Mechanisms are separated by single spaces. No commas, no semicolons, no quotes inside the record.

3. The policy. The final all mechanism tells receivers what to do with anything not matched by the mechanisms above. Four qualifiers exist:

• +all means pass everything. Never use this. It negates the entire record.

• ?all is neutral. Testing only.

• ~all is SoftFail, used during rollout and monitoring.

• -all is HardFail, the right answer once the record is mature.

If you want the deep dive on those qualifiers, our SPF Hard Fail vs Soft Fail guide covers the differences in detail.

That is the whole structure. Now let's look at real records.

Suggested image: labeled diagram of an SPF record with prefix, mechanisms, and policy highlighted, alt text "SPF record syntax breakdown showing version prefix, include mechanisms, and policy qualifier"

Example 1: Microsoft 365 Only

The simplest real-world scenario. Your company runs email exclusively through Microsoft 365 and does not use any third-party sending platforms. This is the record you publish:

v=spf1 include:spf.protection.outlook.com ~all

What each part is doing:

• v=spf1 identifies this as an SPF version 1 record

• include:spf.protection.outlook.com authorizes Microsoft's Exchange Online infrastructure to send on behalf of your domain

• ~all tells receivers to treat anything else as a SoftFail, which is the right setting while you verify there are no other senders you have forgotten about

When to use it: Brand-new Microsoft 365 tenants, small businesses that only use Outlook for business email, and companies that have audited their senders and confirmed Microsoft is the only one.

What to do next: Run the domain through our SPF Checker to confirm it resolves cleanly, then monitor your DMARC reports for two to four weeks before tightening to -all.

Example 2: Google Workspace Only

Same scenario as above, but running on Google Workspace instead of Microsoft.

v=spf1 include:_spf.google.com ~all

What each part is doing:

• v=spf1 is the version prefix

• include:_spf.google.com is Google's official SPF mechanism, which resolves to the current list of Google-owned sending IPs

• ~all is SoftFail for the rollout phase

When to use it: Google Workspace tenants that do not use Mailchimp, HubSpot, Salesforce, or any other third-party sending services. If you send any marketing email, transactional email, or CRM email from a separate tool, this record is not enough and will cause failures.

Heads up: The _spf.google.com include resolves through several nested includes of its own. That counts as multiple lookups against the 10-lookup limit, so do not assume you have 9 lookups of headroom left after this one. You probably have around 5 or 6.

Example 3: Microsoft 365 with Mailchimp

A very common small-business setup. Exchange Online handles employee email, and Mailchimp (via Mandrill) handles marketing campaigns sent from the same domain.

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all

What each part is doing:

• include:spf.protection.outlook.com covers employee mail through Microsoft 365

• include:servers.mcsv.net covers Mailchimp/Mandrill campaign mail

• ~all stays as SoftFail through the monitoring phase

A note on ordering. The order of include: mechanisms does not affect how the record authenticates. Receivers evaluate all mechanisms until one matches. Organize them however makes sense to you. Alphabetical order works. Most-used-first works. Whatever you choose, keep it consistent so the next person who touches the record can read it quickly.

When to use it: Any business that sends newsletter or campaign email through Mailchimp while running day-to-day mail on Microsoft 365.

Example 4: Google Workspace with Multiple Senders

Now we stack a few services together. Say your company uses Google Workspace for employee email, HubSpot for marketing, and Zendesk for customer support tickets. Here is the record:

v=spf1 include:_spf.google.com include:_spf.hubspot.com include:mail.zendesk.com ~all

What each part is doing:

• include:_spf.google.com for Google Workspace

• include:_spf.hubspot.com for HubSpot sending infrastructure

• include:mail.zendesk.com for Zendesk support mail

• ~all for SoftFail monitoring

Watch the lookup count. You are now at roughly 10 to 14 total DNS lookups depending on what each include nests into. That is close to, or already over, the RFC 7208 limit of 10. If your SPF checker reports a permerror on this configuration, you have hit the ceiling and will need to flatten includes, remove a service, or delegate one of them to a subdomain.

Our SPF Failure Troubleshooting Guide walks through the 10-lookup fix in detail.

Example 5: Enterprise Multi-Vendor Setup

Larger companies typically route through many vendors. Here is a realistic enterprise record that uses SPF flattening to stay under the lookup limit:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/23 ip4:192.0.2.42 include:_spf.google.com include:_spf.salesforce.com ~all

What each part is doing:

• ip4:203.0.113.0/24 authorizes a /24 block, often used for on-premises mail relays or corporate SMTP gateways

• ip4:198.51.100.0/23 authorizes a larger /23 block for secondary infrastructure

• ip4:192.0.2.42 authorizes a single mail server IP

• include:_spf.google.com for Google Workspace employee mail

• include:_spf.salesforce.com for Salesforce-originated mail

• ~all for SoftFail

Why this works at scale. The ip4: mechanisms do not count against the 10-lookup limit. Only DNS-lookup-based mechanisms do. By flattening your heaviest third-party senders into explicit IP ranges (either manually or through an automated flattening service), you free up lookup headroom for the includes that truly benefit from staying dynamic.

A warning, though. Flattened IPs go stale when your upstream provider changes its infrastructure. Either use an automated flattening service that monitors upstream changes, or audit the record monthly. Stale flattened IPs are a quiet source of authentication failures.

If you need hands-on help standing up a clean enterprise SPF, DKIM, and DMARC posture, our Email Audit service is built for exactly that.

Example 6: Subdomain-Specific Record

SPF records are per-hostname. Subdomains do not inherit from the apex. That sounds restrictive, and it is, but it can also work in your favor. A common pattern is to use a subdomain for marketing mail so the apex domain stays uncluttered.

At the apex (yourdomain.com) for day-to-day business email:

v=spf1 include:spf.protection.outlook.com ~all

At the subdomain (mail.yourdomain.com) for marketing:

v=spf1 include:servers.mcsv.net include:sendgrid.net ~all

Why split them? Two reasons. First, you keep lookup budget available at each level, which matters if you have a lot of tools stacked. Second, if a marketing vendor ever gets compromised or has a reputation problem, the fallout is limited to the subdomain, not your primary sending identity.

Host field gotcha. When you publish the subdomain record, the host field in your DNS UI is usually mail on its own (not mail.yourdomain.com). Your DNS provider appends the apex automatically. Read the confirmation screen before you save, every DNS provider displays the resolved full hostname as you edit.

We walk through the full setup flow in How to Setup SPF.

Example 7: Non-Sending Domain Lockdown

If you own a domain that never sends email, publish this:

v=spf1 -all

That is the entire record. It says "no IP is authorized to send on behalf of this domain, reject anything that tries." It is a defensive measure that prevents a spammer from using your parked or marketing-only domain to spoof mail.

When to use it:

• Parked domains you own but do not use for email

• Brand protection registrations (the common misspellings of your main domain)

• Legacy domains from past mergers or rebrands

• Subdomains that are used only for web or app traffic, never mail

Pair it with DMARC. For maximum protection, also publish a DMARC record on the same domain with p=reject:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

That combination, v=spf1 -all plus p=reject, closes the door on spoofing from non-sending domains. Our iO™ DMARCplatform will ingest the rua reports so you can see if anyone is trying.

Example 8: Custom Mail Server with Specific IPs

If you run your own mail server (or a small set of them) instead of routing through a hosted provider, your record lists the IPs directly.

v=spf1 ip4:203.0.113.25 ip4:203.0.113.26 ip6:2001:db8::1 mx ~all

What each part is doing:

• ip4:203.0.113.25 and ip4:203.0.113.26 authorize two specific IPv4 addresses

• ip6:2001:db8::1 authorizes a single IPv6 address

• mx authorizes every IP address published as an MX record for the domain

• ~all is SoftFail during the verification phase

Avoid listing the same server twice. If your mail server is already the MX host, the mx mechanism covers it. Do not alsolist its IP with ip4:. Redundant authorization is not harmful, but it makes the record harder to read and harder to change later.

A common mistake with mx. The mx mechanism counts as one DNS lookup, plus one additional lookup for each unique MX host. If you have a lot of MX records, consider using explicit ip4: entries instead to conserve lookup budget.

Mechanism Reference Table

A quick-scan reference so you can decode any SPF record you come across.

MechanismWhat it doesCounts against 10-lookup limit?v=spf1Required prefix, identifies the record as SPF v1Noip4:x.x.x.xAuthorizes a single IPv4 addressNoip4:x.x.x.x/24Authorizes an IPv4 CIDR rangeNoip6:xxxx::1Authorizes a single IPv6 addressNoip6:xxxx::/64Authorizes an IPv6 CIDR rangeNoaAuthorizes the A record of the current domainYes (1)a:other.comAuthorizes the A record of another domainYes (1)mxAuthorizes every IP in the MX recordsYes (1 plus each MX)include:other.comDelegates to another domain's SPF recordYes (1 plus everything nested)exists:macro.comAuthorizes if a DNS A query returns a resultYes (1)redirect=other.comReplaces the current record with another domain'sYes (1 plus everything nested)+allPass anything, do not use thisNo?allNeutral, testing onlyNo~allSoftFail, recommended for rolloutNo-allHardFail, recommended for enforcementNo

The ptr mechanism also exists in the RFC, but it is deprecated and most receivers ignore it. Do not use it.

What a Bad SPF Record Looks Like

Worth looking at too. Here are three records that will cause problems, and why.

Broken example 1: Multiple records on the same domain

v=spf1 include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com ~all

Two v=spf1 records on the same hostname. RFC 7208 allows exactly one. Receivers return permerror, and every message authenticates as though SPF did not exist. Merge them into one.

Broken example 2: Plus-all at the end

v=spf1 include:spf.protection.outlook.com +all

The +all at the end negates everything before it. It tells every receiver that every IP on the internet is authorized to send from your domain. Spoofers love this. If you see a record ending in +all, change it today.

Broken example 3: Syntax errors everywhere

"v=spf1 include: spf.protection.outlook.com, ip4=203.0.113.25 all"

Three separate problems. A space after the colon in include:. A comma between mechanisms. An equals sign instead of a colon in ip4. And an all without a qualifier, which receivers do not know how to interpret. This record will fail to parse.

Compare to a correct version of the same intent:

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.25 ~all

Small differences, very different outcomes.

If any of these look familiar, the SPF Failure Troubleshooting Guide has the full fix for each.

Copy-Paste Templates

Bookmark this section. These are the templates we hand to clients most often. Replace the example values with your own, validate with our SPF Checker, and publish.

Small business, Microsoft 365 only:

v=spf1 include:spf.protection.outlook.com ~all

Small business, Google Workspace only:

v=spf1 include:_spf.google.com ~all

Microsoft 365 plus Mailchimp:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all

Google Workspace plus HubSpot plus Zendesk:

v=spf1 include:_spf.google.com include:_spf.hubspot.com include:mail.zendesk.com ~all

Microsoft 365 plus SendGrid plus Salesforce:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com ~all

Parked or non-sending domain:

v=spf1 -all

Self-hosted mail server with two IPs:

v=spf1 ip4:203.0.113.25 ip4:203.0.113.26 ~all

Enterprise with flattened IPs plus two includes:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.salesforce.com ~all

For a refresher on the "no SPF record found" scenario specifically, see No SPF Record Found Fix Guide. For the full picture on how SPF fits alongside DKIM and DMARC, see What is SPF Email, DKIM, and DMARC?.

Frequently Asked Questions

1. What does a valid SPF record look like? A valid SPF record is a DNS TXT record that starts with v=spf1, lists authorized senders with mechanisms like include:, ip4:, or mx, and ends with an all mechanism such as ~all or -all. A simple valid example is v=spf1 include:spf.protection.outlook.com ~all.

2. Can I see examples of SPF records for specific providers? Yes. Microsoft 365 uses include:spf.protection.outlook.com. Google Workspace uses include:_spf.google.com. Mailchimp uses include:servers.mcsv.net. SendGrid uses include:sendgrid.net. HubSpot uses include:_spf.hubspot.com. Each provider publishes its own official mechanism in its documentation.

3. How do I know if my SPF record is working? Run it through the iO™ SPF Checker for an instant read. You can also query your DNS with dig TXT yourdomain.com or nslookup -type=TXT yourdomain.com to see the published record directly. To see how it is actually behaving in the wild, ingest DMARC aggregate reports through iO™ DMARC.

4. Do I need a different SPF record for each subdomain? Yes, if those subdomains send email. Subdomains do not inherit the apex SPF record. If mail.yourdomain.com sends mail, it needs its own SPF record at that hostname.

5. How many IP addresses can I put in one SPF record? Practically speaking, as many as will fit inside the 512-character UDP DNS response, which is around 10 to 15 IP addresses depending on how many other mechanisms you use. For larger lists, split across multiple mechanisms or use SPF flattening services.

6. Should I use ~all or -all at the end of my SPF record? Use ~all (SoftFail) during the monitoring phase, usually two to four weeks. Once every legitimate sender is authenticating cleanly in your DMARC reports, tighten to -all (HardFail) for full enforcement. Never use +all.

7. What happens if I have no SPF record at all? Receivers return spf=none, which means they cannot verify the sending IP. Over time, your deliverability will suffer, your domain becomes an easier target for spoofing, and any DMARC policy you publish will have to rely entirely on DKIM. Our No SPF Record Found guide walks through fixing that.

8. Is v=spf1 +all ever a valid record? No. It is syntactically valid, but semantically it is the opposite of what SPF is for. It authorizes every IP on the internet. If you see it, replace it immediately.

Keep Your SPF Clean

An SPF record is not a "set it and forget it" artifact. New services get adopted, old ones get dropped, and infrastructure changes in ways that quietly invalidate assumptions. The companies whose SPF records stay clean are the ones that treat them like living documents.

If you want a second set of eyes on your record, or a complete audit of your SPF, DKIM, and DMARC posture together, reach out at 844-InputOut (467-8868) or through inputoutput.com. Our Email Audit service pulls the full picture into one report, and our iO™ DMARC platform keeps you watching the results in real time.

Get the record right. Keep it monitored. Your email does the rest.

BE BETTER. BE iO.™