How to Set Up SPF Records: Complete Guide with Examples

An SPF record is a single line of text in your domain's DNS that lists every server allowed to send email on your behalf. If a server is not on the list, receiving mail servers can reject the message or route it to spam. Google requires SPF from all senders, Yahoo requires both SPF and DKIM, and Microsoft began rejecting unauthenticated bulk email in May 2025 (Google Workspace Help, 2024; Yahoo Sender Hub, 2024; Microsoft Tech Community, 2025).

This guide covers the full setup process: what SPF records look like, how every mechanism works, how to build a record for your specific sending setup, and how to avoid the mistakes that break authentication for most domains.

What SPF does (and what it cannot do)

SPF answers one specific question: "Is this server allowed to send email for this domain?" It checks the envelope sender (Return-Path), not the From: header that recipients see in their inbox. This is a critical distinction. An attacker can set the Return-Path to their own domain (passing SPF) while spoofing your domain in the visible From: field. Without DMARC, that spoofing works.

SPF also breaks when emails are forwarded. The forwarding server's IP is not in your SPF record, so SPF fails. This is why DKIM matters: its cryptographic signature travels with the message and survives forwarding.

For a broader overview of how SPF, DKIM, and DMARC work together, see our email authentication explained guide.

SPF record syntax: every mechanism explained

An SPF record always starts with v=spf1 and ends with an all mechanism. Everything in between is a list of authorized sources. Here is a real-world example:

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

This record says: "Google's mail servers, SendGrid's servers, and the IP address 203.0.113.5 are authorized to send email for this domain. Reject everything else."

Mechanisms

Key distinction: ip4 and ip6 do not consume DNS lookups. include, a, mx, exists, and redirect do. This distinction matters when you are trying to stay under the 10-lookup limit.

Qualifiers: what goes before the mechanism

Every mechanism can be prefixed with a qualifier that determines how to treat a match. If no qualifier is specified, + (pass) is the default.

Step-by-step: setting up your SPF record

The 10 DNS lookup limit

This is the constraint that catches most organizations off guard. RFC 7208, Section 4.6.4 limits SPF evaluation to a maximum of 10 DNS lookups. Every include:, a:, mx:, redirect=, and exists: mechanism counts as one lookup. Nested includes inside referenced records also count toward the total.

Here is how lookups add up quickly:

Using just four include: directives pushed the total to 11. At that point, SPF returns a PermError, and every single email from your domain fails SPF. Silently. You will not get an error notification from your DNS provider. The only way to catch it is to test.

Void lookups. RFC 7208 also limits void lookups (DNS queries returning NXDOMAIN or zero answers) to a maximum of 2. Stale includes pointing to domains that no longer exist count here. Exceeding the void lookup limit also triggers PermError.

How to fix: SPF flattening

SPF flattening resolves all include: chains into their underlying ip4: and ip6: entries, eliminating DNS lookups entirely. Since ip4 and ip6 do not count toward the 10-lookup limit, a flattened record can authorize dozens of sending services without hitting the cap.

The tradeoff: flattened records break when providers change their IP addresses. Manual flattening is a maintenance burden. Automated tools re-flatten on a schedule (typically daily) to keep records current.

Check your current lookup count and flatten if needed with our SPF Flattening Tool.

SPF record examples for common setups

Google Workspace only

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

Simple. One include, one lookup at the top level. Google's nested SPF adds about 3 more lookups internally.

Microsoft 365 only

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

Google Workspace + marketing + transactional

v=spf1 include:_spf.google.com include:spf.mandrillapp.com include:sendgrid.net -all

Three includes. Check nested lookup counts to confirm you are under 10.

Enterprise with a dedicated mail server

v=spf1 ip4:198.51.100.0/24 include:_spf.google.com include:spf.protection.outlook.com -all

The ip4: range costs zero lookups. The two includes cost 2 lookups plus their nested dependencies.

Domain that does not send email

v=spf1 -all

Publish this on any domain or subdomain that should never send email. It tells receivers to reject everything. This is important: attackers specifically target domains without SPF records for spoofing because there is no policy to fail against.

Common SPF mistakes (and how to fix them)

1. Multiple SPF records on the same domain

RFC 7208 Section 4.5 requires exactly one SPF TXT record per domain. Two records cause a PermError. This happens when a new email service instructs you to "add" an SPF record instead of modifying your existing one. The fix: merge all include: directives into a single record.

2. Exceeding the 10-lookup limit

Every include: counts, and so do the nested includes inside those referenced records. Adding five or six services can quietly push you over 10. The fix: audit your lookup count with our SPF Record Checker, then flatten or consolidate.

3. Using +all or ?all

+all authorizes the entire internet. ?all is neutral, which effectively means no policy. Both defeat the purpose of SPF. Use ~all during testing, then switch to -all for production.

4. Forgetting subdomains

Each subdomain needs its own SPF record. If marketing.example.com sends email but has no SPF record, those emails have no SPF protection. For subdomains that do not send email, publish v=spf1 -all to prevent spoofing.

5. SPF record exceeding 255 characters per DNS string

The DNS protocol limits each TXT string to 255 characters. For long SPF records, split the value into multiple strings within a single TXT record. Most DNS providers handle this automatically, but some require manual splitting. The record remains one TXT record containing multiple strings, not multiple TXT records.

6. Stale includes

If you switch email providers but leave the old include: in your SPF record, it wastes DNS lookups. Worse, if the old provider's domain no longer resolves, it counts as a void lookup. Two void lookups trigger PermError. Clean up your record when you change providers.

SPF and email forwarding

SPF checks the sending server's IP against the envelope-from domain's authorized list. When an email is forwarded, the forwarding server's IP replaces the original, but the envelope-from domain stays the same. The forwarding server is not in your SPF record, so SPF fails.

Two mechanisms help:

• SRS (Sender Rewriting Scheme): The forwarding server rewrites the envelope-from to its own domain, making SPF check against the forwarder's SPF instead of yours. The email still passes SPF, just under a different domain.
• DKIM: Because DKIM signs the message content (not the sending IP), the signature survives forwarding. With DMARC alignment, a passing DKIM check is sufficient even if SPF fails. This is why you should always configure both SPF and DKIM.

For a comprehensive domain audit covering SPF, DKIM, DMARC, blacklists, and overall sending reputation, run our free Domain Email Health Score.

How to verify your SPF record

1. Check the record exists and is valid: SPF Record Checker retrieves your record, validates syntax, counts DNS lookups, and flags errors.
2. Verify you are under 10 lookups: The checker shows both direct and nested lookup counts. If you are over 10, use the SPF Flattening Tool to resolve includes into IP addresses.
3. Test with a real email: Send a test message to a Gmail account and check the original message headers (three-dot menu, "Show original"). Look for spf=pass in the Authentication-Results header.
4. Full authentication check: Run the Domain Email Health Score to verify SPF, DKIM, and DMARC together.

If your emails are landing in spam despite passing SPF, the issue may be elsewhere in your authentication chain or sender reputation. See our guide to fixing emails going to spam for the full troubleshooting checklist.

Frequently asked questions

What is an SPF record and why do I need one?

An SPF (Sender Policy Framework) record is a DNS TXT record that lists which servers are authorized to send email on behalf of your domain. Without one, any server on the internet can send email pretending to be from your domain. Google, Yahoo, and Microsoft all require SPF for email delivery. If your domain lacks an SPF record, your emails may land in spam or be rejected outright.

What does the SPF 10 DNS lookup limit mean?

RFC 7208 limits SPF evaluation to 10 DNS lookups. Every include, a, mx, redirect, and exists mechanism counts as one lookup. Nested includes in referenced records also count toward the total. If your record exceeds 10 lookups, SPF returns a permanent error (PermError) and every email fails SPF. The ip4 and ip6 mechanisms do not count because they require no DNS query. Organizations using many third-party services frequently hit this limit.

Should I use -all or ~all in my SPF record?

Use -all (hard fail) for production domains where you have identified all legitimate sending sources. It tells receiving servers to reject email from unauthorized servers. Use ~all (soft fail) during initial setup or testing, as it flags unauthorized email but does not reject it. Never use +all, which authorizes the entire internet to send as your domain.

Can I have multiple SPF records on the same domain?

No. RFC 7208 Section 4.5 requires exactly one SPF TXT record per domain. If you publish two SPF records, the result is a PermError and SPF fails for every email. This is one of the most common configuration mistakes. It typically happens when a new email service instructs you to "add" an SPF record rather than modify your existing one. You must merge all authorized sources into a single SPF record.