The Complete Guide to SPF Records

SPF (Sender Policy Framework) is the foundation of email authentication. It tells receiving mail servers which services are allowed to send email for your domain -- and what to do when something unauthorized tries.

If you send email from your domain -- whether that's transactional messages, marketing campaigns, or just regular business email -- you need an SPF record. Without one, your messages are more likely to land in spam, and anyone can send email pretending to be you.

This guide covers everything you need to know about SPF. Each section gives you the essentials and links to a detailed article if you want to go deeper.

What SPF Is and Why Every Domain Needs It

SPF is a DNS-based email authentication protocol defined in RFC 7208. At its core, it lets you publish a list of authorized senders for your domain as a simple TXT record in DNS. When a receiving mail server gets a message from your domain, it checks that record. If the sender matches one of the authorized sources, the message passes. If not, the receiving server can reject it, quarantine it, or flag it as suspicious.

The business case for SPF is straightforward. Without it, anyone on the internet can send email that appears to come from your domain. Attackers exploit this constantly -- phishing emails impersonating your CEO, fake invoices sent from your billing domain, password reset scams that look like they came from your support address. SPF gives receiving servers a way to catch these forgeries. When a spoofed message arrives from a server that's not in your SPF record, the receiving server knows it's unauthorized and can act accordingly.

Beyond security, SPF directly affects whether your legitimate email reaches the inbox. Mailbox providers like Gmail, Outlook, and Yahoo use SPF results as a signal when deciding where to place messages. A message that passes SPF is more likely to land in the inbox. A message that fails -- or comes from a domain with no SPF record at all -- is more likely to end up in spam. Starting in early 2024, Google and Yahoo began enforcing stricter sender requirements that make SPF effectively mandatory for anyone sending bulk email. Even if you're a small business sending a few hundred messages a month, having SPF in place improves your odds.

There's also a compliance angle. Many industries require email authentication as part of security frameworks. If your organization handles customer data, processes payments, or operates in a regulated sector, SPF is often a baseline requirement. Setting it up takes minutes. Leaving it out creates risk that compounds over time.

For a full explanation of what SPF is and why it matters, read What is SPF? Email Authentication Explained.

How SPF Works

Understanding how SPF works behind the scenes helps you troubleshoot problems and make better decisions about your record. The process starts the moment someone sends an email using your domain.

Let's walk through a concrete example. Say your business uses Google Workspace, and one of your employees sends an email from sales@yourcompany.com to a customer on Gmail. The email leaves Google's mail servers with a Return-Path of sales@yourcompany.com. When Gmail's receiving server gets the message, it extracts the domain from that Return-Path -- yourcompany.com -- and performs a DNS lookup for the TXT record at that domain. It finds your SPF record: v=spf1 include:_spf.google.com -all. The server then evaluates each mechanism left to right. It hits include:_spf.google.com, which triggers another DNS lookup to retrieve Google's SPF record. That record contains the IP ranges for Google's mail servers. The receiving server checks whether the sending server's IP address falls within one of those ranges. It does -- so the result is "pass," and the message proceeds toward the inbox.

Now consider what happens when the message fails. An attacker sets up a random mail server and sends a phishing email with a forged Return-Path of ceo@yourcompany.com. The receiving server performs the same DNS lookup and finds the same SPF record. It evaluates the mechanisms left to right. The attacker's server IP doesn't match include:_spf.google.com, so the server moves to the next mechanism: -all. The - qualifier means hard fail. The receiving server records an SPF fail result and is very likely to reject or quarantine the message.

One critical detail that trips people up: SPF checks the envelope sender (the Return-Path address), not the visible From header that recipients see in their email client. These are often different. When you use a service like SendGrid to send marketing email, the Return-Path might be something like bounces@sendgrid.net, not your domain at all. This means SPF is checking SendGrid's domain, not yours. The From header can still show your domain -- and that's exactly what DMARC alignment addresses later. Understanding this distinction is essential for getting your authentication right.

The possible results of an SPF check are defined in RFC 7208: pass (the sender is authorized), fail (the sender is explicitly not authorized), softfail (the sender is probably not authorized, but the domain owner isn't fully certain), neutral (the domain owner makes no assertion), none (no SPF record exists), temperror (a temporary DNS error occurred), and permerror (the SPF record is malformed and can't be evaluated). In practice, pass and fail are the results you want to think about. Softfail is a common transitional state while you're testing a new record.

For the full technical walkthrough -- including DNS query chains, nested includes, and evaluation edge cases -- read How SPF Works: Technical Deep Dive.

Anatomy of an SPF Record

An SPF record is a single line of text published as a DNS TXT record on your domain. It always starts with v=spf1 and ends with an all mechanism. In between, you list every server, service, and IP address authorized to send email for your domain.

Here's a real-world example for a business using Google Workspace for company email, SendGrid for transactional messages, and a dedicated server for their CRM:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.25 -all

Let's break it down piece by piece:

• v=spf1 -- This identifies the record as SPF version 1 (the only version that exists). Every SPF record must start with this. If it's missing, the record won't be recognized as SPF at all.
• include:_spf.google.com -- This authorizes all of Google Workspace's mail servers. The include mechanism tells the receiving server to look up the SPF record at _spf.google.com and treat those IP addresses as authorized for your domain too. It's how you delegate authorization to a third-party service.
• include:sendgrid.net -- Same idea, but for SendGrid. Any email sent through SendGrid on your behalf will pass SPF.
• ip4:198.51.100.25 -- This authorizes a single IPv4 address directly. You'd use this for a server you own -- like an application server that sends password resets or a CRM that connects via SMTP.
• -all -- The catch-all mechanism. The - prefix means "hard fail" -- any server not covered by the preceding mechanisms is explicitly unauthorized. This is the strongest enforcement option.

The all mechanism is where people make their most consequential choice. There are four qualifiers you can use with any mechanism, but they matter most with all:

Here's a more complex example for a business using Google Workspace, Microsoft 365 (perhaps from an acquisition), Mailchimp, and a dedicated mail server:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.0/24 -all

Notice that you can mix include mechanisms with ip4 ranges freely. The order of mechanisms matters -- they're evaluated left to right, and the first match wins. In practice, this means putting your most common senders first for slightly faster evaluation, though the real-world performance difference is negligible.

For a detailed breakdown of every mechanism and qualifier with more examples, read SPF Mechanisms: include, ip4, mx, a, all Explained.

The SPF Mechanisms Explained

SPF uses a set of mechanisms to define which senders are authorized. Each mechanism checks a different kind of source. Here's a quick reference of every mechanism available, with a one-line example for each:

include -- Delegates authorization to another domain's SPF record. This is how you authorize third-party email services.

include:_spf.google.com

ip4 -- Authorizes a specific IPv4 address or CIDR range. Use this for servers you control.

ip4:203.0.113.0/24

ip6 -- Same as ip4, but for IPv6 addresses.

ip6:2001:db8::/32

a -- Authorizes the IP address(es) in the A record of the specified domain (or the current domain if no domain is given).

a:mail.example.com

mx -- Authorizes the IP addresses of the domain's MX (mail exchange) servers.

mx

redirect -- Replaces the current SPF evaluation with another domain's SPF record entirely. Unlike include, this doesn't fall through on a non-match -- it replaces the whole evaluation.

redirect=_spf.example.com

exists -- Passes if a DNS A record exists for the specified domain. Used for advanced macro-based setups.

exists:%{i}._spf.example.com

ptr -- Resolves the sender's IP to a hostname and checks if it matches the domain. This mechanism is deprecated in RFC 7208 because it's slow and unreliable. Don't use it.

Most SPF records only need include and ip4. The a and mx mechanisms are useful for simple setups where your web server or MX hosts also send email. The advanced mechanisms -- redirect, exists, and ptr -- are rarely needed for typical business configurations.

For the deep dive on each mechanism with detailed examples and edge cases, read SPF Mechanisms: include, ip4, mx, a, all Explained.

SPF by Email Provider

Every email service you use needs its own entry in your SPF record. The most common mistake is not knowing the correct include value for a given provider. Here are the SPF include values for the most widely used email services:

Google Workspace -- Used for business email by millions of organizations.

include:_spf.google.com

Source: Google Workspace Admin Help

Microsoft 365 -- The standard for enterprise email and Office productivity.

include:spf.protection.outlook.com

Source: Microsoft 365 SPF documentation

SendGrid -- Popular for transactional and marketing email via API.

include:sendgrid.net

Source: SendGrid SPF documentation

Mailchimp -- Widely used for email marketing and newsletters.

include:servers.mcsv.net

Source: Mailchimp authentication docs

Amazon SES -- AWS's email sending service, common for developer-oriented applications.

include:amazonses.com

Source: Amazon SES developer guide

Mailgun -- API-first email service for developers.

include:mailgun.org

Source: Mailgun SPF documentation

If you use multiple providers, you combine them into a single record. Here's what a business using Google Workspace, SendGrid, and Mailchimp would publish:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all

That's three includes, which uses three of your ten allowed DNS lookups. Each nested include chain counts against the total too -- Google's _spf.google.com alone resolves through several layers of includes. This is where the 10 lookup limit starts to matter.

We maintain a complete reference of SPF includes for every major email provider -- including HubSpot, Zoho, Postmark, Brevo, Freshdesk, Zendesk, and many more. See SPF Records by Email Provider for the full list.

SPF by DNS Provider

Once you know what your SPF record should contain, you need to add it to your DNS. This is where a lot of people get stuck -- not because the record itself is complicated, but because every DNS provider has a slightly different interface with different field names and behaviors.

The most common source of confusion is the Host (or Name) field. This is where you specify which domain or subdomain the record applies to. For your root domain's SPF record, you want the record on the bare domain -- yourcompany.com, not a subdomain. But different providers expect this to be entered differently:

• GoDaddy -- Enter @ in the Host field. GoDaddy uses @ as shorthand for the root domain.
• Cloudflare -- Enter @ in the Name field, or leave it blank. Cloudflare treats both the same way.
• Amazon Route 53 -- Leave the Name field blank, or enter the full domain name (yourcompany.com). Route 53 does not use the @ convention.
• Namecheap -- Enter @ in the Host field. Namecheap auto-appends your domain to whatever you enter, so typing the full domain would result in yourcompany.com.yourcompany.com.

Getting this wrong means your SPF record ends up on the wrong subdomain -- or on a record like yourcompany.com.yourcompany.com -- and does nothing. Your root domain has no SPF record, and emails fail authentication. This is one of the most common support issues we see, and it's entirely caused by inconsistent provider interfaces.

The record type is always TXT. The value is your complete SPF string (e.g., v=spf1 include:_spf.google.com -all). Set the TTL to 3600 seconds (1 hour) unless you have a reason to choose differently. A lower TTL like 300 seconds is useful during initial setup so you can iterate quickly, then raise it once the record is stable.

We have step-by-step guides with screenshots for every major DNS provider. See SPF Records by DNS Provider for the full list with links to each guide.

Common SPF Mistakes

SPF is straightforward in theory, but there are several mistakes that silently break your email authentication. The tricky part is that your DNS provider will happily accept a broken record without complaint. You only find out something is wrong when emails start bouncing or landing in spam -- sometimes weeks later.

Here are the five most common mistakes:

1. Creating multiple SPF records. This is the most frequent error. You can only have one SPF record per domain. If you add a new TXT record with v=spf1 instead of editing the existing one, you'll have two SPF records. This causes a permerror -- receiving servers can't determine which record is authoritative, so the entire SPF check fails. The fix is simple: merge everything into a single record.

2. Exceeding the 10 DNS lookup limit. Every include, a, mx, redirect, and exists mechanism triggers a DNS lookup. Nested includes count too. If the total exceeds 10, the SPF check returns a permerror, which most providers treat the same as a fail. Businesses using several third-party services hit this limit faster than they expect.

3. Using +all instead of -all. The +all mechanism tells receiving servers that every server in the world is authorized to send email for your domain. This completely defeats the purpose of SPF. It's the same as having no SPF record at all -- except it's worse, because it signals that you specifically intended to authorize everyone. Always use -all (or ~all while testing).

4. Forgetting the all mechanism entirely. If your SPF record doesn't end with an all mechanism, the implicit default is ?all (neutral), which means SPF makes no assertion about unauthorized senders. Always explicitly end your record with -all or ~all.

5. Forgetting to include all your sending services. This happens when someone sets up a new tool -- a helpdesk, marketing platform, or CRM -- that sends email from your domain but doesn't update the SPF record. Email from that service silently fails SPF. Whenever you add a new service that sends email as your domain, update your SPF record at the same time.

For a complete list of mistakes with detailed examples and fix instructions, read Common SPF Errors and How to Fix Them.

The 10 DNS Lookup Limit

The 10 DNS lookup limit is one of the most misunderstood aspects of SPF, and it's the constraint that causes the most real-world problems. RFC 7208 section 4.6.4 specifies that an SPF evaluation must not require more than 10 DNS lookups. If it does, the result is a permerror -- the check fails before it even finishes.

Not every mechanism triggers a lookup. Here's the breakdown:

Mechanisms that count toward the limit:

• include -- 1 lookup per include, plus any lookups inside the included record
• a -- 1 lookup
• mx -- 1 lookup (plus additional lookups to resolve the MX hostnames to IPs)
• redirect -- 1 lookup
• exists -- 1 lookup

Mechanisms that do NOT count:

• ip4 -- No lookup needed; it's a literal IP address
• ip6 -- Same as ip4
• all -- No lookup; it's a catch-all directive

The nested nature of include is what catches people off guard. Let's count the lookups for a business using Google Workspace, SendGrid, and Mailchimp:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all

• include:_spf.google.com -- 1 lookup. But Google's SPF record at _spf.google.com itself contains multiple includes (_netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com), adding 3 more lookups. Total: 4 lookups for Google alone.
• include:sendgrid.net -- 1 lookup. SendGrid's record contains additional includes. Total: roughly 2-3 lookups for SendGrid.
• include:servers.mcsv.net -- 1 lookup. Mailchimp's record may contain further includes. Total: roughly 2 lookups for Mailchimp.

That puts you at approximately 8-9 lookups just for these three services. Add one more provider -- a CRM, a helpdesk, a second marketing tool -- and you're over the limit. Your SPF record returns a permerror, and all your email authentication via SPF breaks.

There are several strategies for staying under the limit. SPF flattening replaces include mechanisms with the underlying ip4 and ip6 addresses, which don't count as lookups. This works but requires ongoing maintenance because providers change their IP ranges. Subdomains let you split sending across different domains (e.g., use marketing.yourcompany.com for Mailchimp and keep your root domain's SPF record leaner). Consolidating providers -- if you're using two services that do the same thing, switching to one frees up lookups.

For strategies to stay under the limit -- including detailed flattening instructions and record optimization techniques -- read Understanding the SPF 10 DNS Lookup Limit.

SPF + DKIM + DMARC: The Full Picture

SPF is essential, but it's only one of three email authentication protocols that work together to protect your domain. Understanding how they complement each other helps you see why SPF alone isn't enough -- and why all three matter.

SPF verifies that the sending server is authorized to send email for the domain in the envelope sender (Return-Path). It answers the question: "Is this server allowed to send as this domain?"

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message. The receiving server uses a public key published in your DNS to verify the signature. It answers the question: "Has this message been tampered with in transit, and does it genuinely come from this domain?"

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with two critical additions: an alignment requirement and a policy. Alignment means the domain in the From header (what the recipient sees) must match the domain checked by SPF or DKIM. The policy tells receiving servers what to do when neither SPF nor DKIM passes with alignment -- reject the message, quarantine it, or let it through but send reports.

Here's why SPF alone falls short. Remember that SPF checks the Return-Path, not the From header. An attacker can send email with a Return-Path on their own domain (passing their own SPF check) but set the From header to your domain. The recipient sees your domain in their email client. Without DMARC's alignment requirement, SPF has no way to catch this. The message passes SPF -- just for the wrong domain. DMARC closes this gap by requiring that the domain authenticated by SPF or DKIM matches the From header domain.

The three protocols also handle email forwarding differently. When an email is forwarded, the forwarding server's IP address typically isn't in the original sender's SPF record -- so SPF fails. But DKIM signatures survive forwarding because they're attached to the message itself. With DMARC in place, the forwarded message can still pass authentication via DKIM even though SPF failed. This is one of the key reasons you need both protocols, not just one.

For a step-by-step walkthrough of setting up all three protocols in the right order, read SPF, DKIM, and DMARC: Complete Setup Guide.

SPF and Google/Yahoo Sender Requirements

In October 2023, Google and Yahoo announced new sender requirements that took effect in February 2024. These requirements made email authentication -- including SPF -- mandatory for anyone sending bulk email to Gmail or Yahoo Mail accounts. If you send more than 5,000 messages per day to Gmail addresses, you must meet stricter standards or risk having your email blocked entirely.

The requirements fall into three tiers. All senders -- regardless of volume -- must have a valid SPF or DKIM record for their sending domain. This is no longer optional. Bulk senders (5,000+ messages per day to Gmail) must additionally have SPF and DKIM set up, a DMARC record published with at least a p=none policy, a "From" header domain that aligns with the SPF or DKIM domain, one-click unsubscribe headers in marketing email, and a spam complaint rate below 0.3%.

For most businesses, the practical impact is clear: you need SPF, DKIM, and DMARC. Google's documentation explicitly states that messages without SPF or DKIM are more likely to be rejected or marked as spam. Yahoo has aligned its requirements with Google's, meaning the same standards apply to Yahoo Mail recipients.

Even if you don't send 5,000 emails a day, these requirements signal a broader industry shift. Other mailbox providers are following suit. Microsoft has announced similar requirements for Outlook.com. Setting up SPF, DKIM, and DMARC now means you're prepared regardless of which provider tightens their policies next. The full details are available in Google's Email Sender Guidelines.

Get Started With SPF

If you don't have an SPF record yet -- or you're not sure if yours is correct -- here's the fastest path:

Monitor Your SPF Record

Setting up SPF is the first step. Keeping it working is the ongoing job. Email services change their include values, team members add new sending tools, and DNS records get accidentally modified. The only way to catch these issues before they affect deliverability is automated monitoring.