What Is SPF? How It Works, Provider Setup & Alignment [2026]

What Is SPF (Sender Policy Framework)?

SPF (Sender Policy Framework) is an email authentication protocol that lets you declare which mail servers are authorized to send email on behalf of your domain. When a receiver gets an email claiming to be from your domain, it checks your SPF record to verify the sending server is on your approved list. As our scan of 5.5 million domains shows, SPF adoption continues to grow but misconfiguration remains a leading cause of delivery failures.

Published as a DNS TXT record, SPF helps prevent email spoofing by giving receivers a way to verify that an email’s sending server is legitimate. The protocol is defined in RFC 7208.

SPF answers one critical question: Is this mail server allowed to send email for this domain?

How SPF Works

Here’s what happens when an email is sent from your domain:

1. You publish an SPF record as a DNS TXT record on your domain (e.g., v=spf1 ip4:203.0.113.5 -all)
2. A receiver gets an email claiming to be from your domain
3. The receiver extracts the envelope sender (the MAIL FROM address, also called Return-Path)
4. The receiver looks up your SPF record by querying DNS for a TXT record at your domain
5. The receiver checks the sending server’s IP against the authorized IPs/mechanisms in your SPF record
6. SPF returns a result: pass, fail, softfail, neutral, none, temperror, or permerror

SPF validates the envelope sender (MAIL FROM), not the visible From: header users see. This is why SPF must be used with DMARC to fully prevent spoofing.

What an SPF Record Looks Like

Every SPF record is one DNS TXT record that starts with v=spf1, followed by space-separated mechanisms and a final all:

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

Read left to right: include:_spf.google.com authorizes Google Workspace’s servers, ip4:203.0.113.5 authorizes one server of your own, and -all fails everything else. Each mechanism can carry a qualifier — + pass (the default), - fail, ~ softfail, ? neutral — and receivers stop at the first mechanism that matches. The choice between ~all and -all has its own trade-offs; SPF softfail vs hardfail covers them. mx authorizes every host in your MX records — the MX record lookup shows which hosts that is today.

That is all the syntax most domains need. Every mechanism, qualifier, modifier and macro — with the RFC 7208 section that defines it, evaluation order, placement rules, and four annotated example records — lives in the SPF record syntax reference. To build a record from your providers, use the SPF record generator; to break an existing record down term by term, use the SPF syntax inspector.

SPF for Google Workspace

Google Workspace requires you to add an SPF record that includes _spf.google.com. Google’s official SPF setup guide recommends:

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

Google recommends using ~all (softfail) initially, then switching to -all (hardfail) once you’ve confirmed all legitimate senders are authorized. If you send email from other services (e.g., a CRM or marketing platform), their include: mechanisms go in the same record before the all. The Google Workspace SPF record guide covers what the include expands to, how to merge third-party senders into it, and the ~all vs -all question in depth.

SPF is only one of the records Google expects — Workspace domains that send bulk mail also need DMARC. The step-by-step DMARC setup for Google Workspace walks through the full rollout, from the exact TXT record to p=reject.

Google Workspace SPF setup reference: https://knowledge.workspace.google.com/admin/security/set-up-spf

SPF for Microsoft 365

Microsoft 365 requires you to include spf.protection.outlook.com in your SPF record:

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

If you send email from other services, add their include: mechanisms:

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

For Microsoft 365 domains, Microsoft recommends -all (hard fail) — its setup doc pairs that recommendation with deploying DKIM and DMARC alongside SPF. Starting with ~all and moving to -all once reports confirm every legitimate sender is listed is our discovery-phase advice, not Microsoft’s recommendation.

Microsoft 365 SPF setup reference: https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure

SPF at your DNS host (GoDaddy, Namecheap, Cloudflare)

DNS-hosting providers each have their own admin-UI quirks for adding an SPF TXT record. For a step-by-step walkthrough with screenshots and common mistakes, see the GoDaddy SPF setup guide — additional providers ship in the same provider-guides format.

SPF for Common Email Services (SendGrid, Mailgun, Amazon SES)

Most third-party email services publish their sending IPs in an SPF record you can include in your own record.

Example combining Google Workspace + SendGrid + custom server:

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

Not every service needs an include at your apex domain: Mailchimp and Amazon SES bounce through their own Return-Path domain, so an include: at your apex never aligns with your From: header and only spends a lookup — the budget those lookups come out of is the subject of the next section.

The 10-DNS-Lookup Limit

RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS-querying terms — include:, a, mx, ptr, exists: and redirect= each cost one, walked through every nested include, while ip4:, ip6: and all cost nothing. Exceed the cap and the result is permerror: SPF fails for every message the domain sends. This is not a rare edge case — our supply-chain study found 148,655 domains exceed the 10-lookup limit in the wild.

Includes nest, so the count is rarely what the record looks like: v=spf1 include:_spf.google.com include:sendgrid.net -all costs 3 lookups, because sendgrid.net nests a second include and costs 2 on its own. Provider lookup costs are not constant — Google simplified _spf.google.com from 4 lookups to 1 in December 2025, and between April and September 2026 Mimecast’s global include grew from 8 lookups to 9 — so count against live DNS, never against a number carried forward from an article. The SPF record checker walks every include chain and reports the total. When you are over budget, the SPF flattening and too-many-lookups guide covers the second cap on void lookups, which includes to remove, subdomain delegation, and when the SPF flattener is worth its maintenance cost.

SPF Macros: When You Need Them

Macros are %{...} placeholders that receivers expand at evaluation time — %{i} becomes the connecting IP address, %{d} the domain being checked, %{h} the HELO/EHLO name. Paired with exists:, one macro mechanism can authorize an entire fleet of sending IPs in a single lookup, which is how Salesforce’s _spf.salesforce.com record works. Most domains never need one. The full table of all eleven macro letters, the transformers, and the RFC’s worked example are in the SPF record syntax reference; before publishing a macro, expand it against a real client IP in the SPF macro debugger.

SPF Alignment and DMARC

SPF alone doesn’t prevent spoofing because it only checks the envelope sender (MAIL FROM), not the visible From: header that users see. Attackers can spoof the From: header while using their own domain in the envelope.

DMARC solves this by requiring SPF alignment: the domain in the MAIL FROM address must match the domain in the From: header.

Relaxed vs Strict Alignment

• Relaxed alignment (default): The organizational domain must match. For example, mail.example.com aligns with example.com.
• Strict alignment: The domains must match exactly. mail.example.com does not align with example.com.

DMARC uses relaxed alignment by default (aspf=r). You can enforce strict alignment with aspf=s in your DMARC record.

v=DMARC1; p=quarantine; aspf=s; rua=mailto:reports@example.com

SPF vs DKIM

SPF and DKIM are complementary email authentication protocols. Both are recommended for comprehensive protection.

SPF is simpler to set up but breaks when email is forwarded (because the forwarding server’s IP won’t match your SPF record). DKIM requires key pair generation and signing configuration but survives forwarding because the signature travels with the message.

Use both. SPF catches spoofing from unauthorized IPs, and DKIM verifies message integrity and survives forwarding.

Common SPF Failures and How to Fix Them

Use our SPF record checker to validate your record and catch these issues before they affect delivery. Each failure below names the fix; the linked guides walk through the diagnosis. For failures that cascade into DMARC problems, see our DMARC failure troubleshooting guide.

PermError (Permanent Error)

Cause: You exceeded the 10-lookup limit, have multiple SPF records, or have a syntax error.

Fix: Flatten your SPF record to reduce lookups, ensure you have exactly one SPF TXT record, and validate your syntax. The SPF PermError guide walks through telling the three causes apart and fixing each one.

TempError (Temporary Error)

Cause: A DNS lookup failed during SPF evaluation (network issue, DNS server down).

Fix: This is usually temporary. Ensure your DNS provider is reliable.

None

Cause: No SPF record was found for your domain.

Fix: Publish an SPF record as a DNS TXT record at your domain.

Neutral

Cause: Your SPF record ends with ?all (neutral).

Fix: Replace ?all with ~all (softfail) or -all (hardfail) for stronger protection.

Softfail

Cause: The sending IP didn’t match any mechanism, and your SPF record ends with ~all.

Meaning: The receiver should accept the email but mark it as suspicious. This is normal during testing.

Fix: Once you’ve verified all legitimate senders are authorized, change ~all to -all. SPF softfail vs hardfail covers how receivers treat each and when to make the switch.

Fail (Hardfail)

Cause: The sending IP didn’t match any mechanism, and your SPF record ends with -all.

Meaning: The receiver should reject the email.

Fix: Add the legitimate sender’s IP or include: mechanism to your SPF record.

Multiple SPF Records

Cause: You have more than one SPF TXT record at your domain.

Fix: Combine all mechanisms into a single SPF record. Only one SPF record is allowed per domain.

Missing Terminating Mechanism

Cause: Your SPF record doesn’t end with all (e.g., v=spf1 include:_spf.google.com).

Fix: Add ~all or -all at the end. Without a terminating mechanism, SPF defaults to neutral, which provides weak protection.

Frequently Asked Questions

What is an SPF record?

An SPF record is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. Receivers use it to verify that incoming email claiming to be from your domain actually came from an approved server.

How do I create an SPF record?

Create an SPF record by adding a DNS TXT record to your domain with the syntax: v=spf1 [mechanisms] [qualifier]. Include your sending mail servers using ip4:/ip6: for specific IPs or include: for third-party services. Always end with -all or ~all. Use a generator tool or your DNS provider’s interface to publish the record.

What is the SPF 10-lookup limit?

SPF has a strict limit of 10 DNS lookups during evaluation. Each include:, a, mx, and redirect mechanism counts as a lookup. Exceeding this limit causes a PermError, which makes SPF evaluation fail completely. Flatten your SPF record by replacing include: statements with direct ip4:/ip6: entries to stay under the limit.

What is the difference between SPF and DKIM?

SPF checks the sending server’s IP address against a DNS record, while DKIM uses cryptographic signatures to verify the message content and sender. SPF validates the MAIL FROM envelope address; DKIM validates the message body and headers. Both are recommended for comprehensive email authentication.

Why is my SPF record failing?

Common SPF failures include: exceeding the 10-lookup limit (PermError), having multiple SPF records (only one is allowed), forgetting the terminating -all or ~all mechanism, or sending from IPs not listed in the record. Check your SPF syntax and ensure all legitimate sending sources are authorized.

Can I have multiple SPF records?

No. A domain must have exactly one SPF TXT record. If multiple SPF records exist, receivers will treat SPF evaluation as failed (PermError). If you need to authorize multiple services, combine them into a single SPF record using include: mechanisms or direct IP entries.

What does ‘spf softfail’ mean?

A softfail occurs when an SPF record ends with ~all (tilde all). It means the sending server is not authorized, but the receiver should accept the email anyway and mark it as suspicious. Softfail is used during SPF testing or when you’re unsure if all legitimate senders are listed. Use -all (hardfail) for stricter enforcement.

Does SPF alone prevent spoofing?

No. SPF alone does not prevent spoofing because it only checks the envelope sender (MAIL FROM), not the visible From: header that users see. Attackers can spoof the From: header while using their own domain in the envelope. DMARC is required to enforce alignment between the two and prevent header-based spoofing.

Related Protocols

• DMARC — Uses SPF results (with alignment) to enforce email policy and prevent spoofing
• DKIM — Complements SPF by signing message content and surviving forwarding
• ARC — Preserves SPF results through forwarding chains, solving SPF’s forwarding problem