SPF Record: What It Is, How It Works, and How to Set One Up
Email fraud costs organizations billions of dollars every year — and the majority of it starts with a spoofed "From" address. Sender Policy Framework (SPF) is one of the three foundational email authentication protocols, alongside DKIM and DMARC, that stops unauthorized senders from sending email using your domain.
Key Takeaways
- SPF is one of the three foundational email authentication protocols, alongside DKIM and DMARC. It's a DNS TXT record that lists every IP address and mail server authorized to send mail for your domain — without one, any server on the internet can impersonate your domain.
- SPF only validates the Return-Path (envelope) domain, not the visible "From:" address, so it can't stop display-name spoofing on its own. It has to be aligned under DMARC to fully protect your domain.
- The closing qualifier sets enforcement: -all (hard fail) rejects every unlisted sender, while ~all (softfail) only flags them. Move to -all once you've audited all of your legitimate sending sources.
- Every include, a, mx, redirect, and exists mechanism counts toward SPF's 10 DNS lookup limit — exceed it and the whole record returns PermError. Keep the record lean (or use automatic flattening) to stay under the cap.
PowerDMARC Resource Centre
This guide covers everything: what SPF is, exactly how it works, how to build and validate a record, what every mechanism and qualifier means, how to fix the most common errors, and how SPF fits into a full DMARC strategy. Bookmark it — you'll refer back to it.
Step-by-step SPF setup guides
Complete implementation walkthroughs
Troubleshoot errors
Fix lookups, softfails & alignment
SPF & DMARC alignment
Make SPF count toward DMARC
Free SPF tools
Check, generate, and validate records
Table of Contents
What is SPF?
SPF (Sender Policy Framework) is one of the three core email authentication protocols, alongside DKIM and DMARC, that prevents unauthorized servers from sending email using your domain. An SPF record is a DNS TXT record that lists every IP address and mail server authorized to send on your behalf. Without one, any server on the internet can impersonate your domain, and receiving servers have no way to tell the difference.
What This Guide Covers
Jump to any section, or read straight through for the full picture:
How SPF Works
When a receiving mail server gets an email, it extracts the domain from the Return-Path (envelope sender), queries DNS for a TXT record starting with v=spf1, and checks whether the sending server's IP matches the authorized list. If it matches, SPF passes. If not, the result is a fail, softfail, or error, and what happens next depends on your DMARC policy.
SPF validates the Return-Path domain (the technical envelope address), not the visible "From:" address. This means SPF alone can't prevent display-name spoofing. That's why DMARC alignment exists to bridge this gap.
| SPF Result | What It Means |
|---|---|
| Pass | Sending IP is authorized. |
| Fail (-all) | Not authorized. Should be rejected. |
| SoftFail (~all) | Probably not authorized. Accept but flag. |
| PermError | Record is broken (syntax error, too many lookups). Treated as failure. |
SPF Record Syntax: Mechanisms and Qualifiers
An SPF record starts with v=spf1, lists authorized senders using mechanisms like ip4:, ip6:, and include:, and ends with a qualifier that tells receivers what to do with unlisted senders. Here's an example:
v=spf1 ip4:192.168.1.1 include:_spf.google.com include:sendgrid.net -all
-all and ~all signal different levels of enforcement in SPF. -all (hard fail) tells receiving servers that only listed senders are authorized and everything else should be rejected. ~all (softfail) is more lenient and flags all unauthorized senders as suspicious, but still accepts them. Use -all once your senders are fully audited.
Each include:, a, mx, redirect=, and exists: mechanism counts toward the 10 DNS lookup limit. Exceeding it triggers a PermError that breaks authentication entirely. The ptr: mechanism is deprecated, avoid using.
How to Create an SPF Record
Start by listing every service that sends email from your domain, like:
- Your primary mail server
- Google Workspace or Microsoft 365
- Marketing tools (Mailchimp, HubSpot, Klaviyo)
- Transactional services (SendGrid, Mailgun, Amazon SES), and any CRM or helpdesk that sends on your behalf.
Each provider publishes an include: value in their documentation. Build a single record combining all senders (you can only have one SPF record per domain), publish it as a TXT record in your DNS provider, and validate it with an SPF checker. DNS propagation typically takes a few hours but can take up to 48.
Provider-specific setup guides
How to Check and Validate Your SPF Record
Use an SPF checker tool to validate that your record is syntactically correct, within the 10-lookup limit, and resolving to the right IP addresses. PowerDMARC's SPF Lookup tool performs all of these checks instantly.
What a good SPF check should verify:
- Record starts with
v=spf1 - Only one SPF record exists for the domain
- Total DNS lookups are 10 or fewer
- No syntax errors or unresolvable
include:domains - The
allqualifier is present and appropriate - No deprecated mechanisms (e.g.,
ptr:)
Command-line check (Linux/Mac):
dig TXT yourdomain.com +short | grep "v=spf1"
Using PowerDMARC's SPF Lookup: Enter your domain at PowerDMARC SPF Checker for an instant diagnostic report showing lookup count, mechanism breakdown, and any errors.
Common SPF Errors and How to Fix Them
Most SPF failures come from configuration drift, not the protocol itself. Here are the errors we see most often and where to fix each one:
| Error | What's Happening | Fix Guide |
|---|---|---|
| PermError: Too many DNS lookups | Record exceeds 10-lookup limit | Fix SPF PermError |
| Multiple SPF records | Two v=spf1 records on same domain | Fix multiple SPF records |
| SPF passes but DMARC fails | Return-Path doesn't align with From: | Fix SPF alignment |
| SoftFail. Domain does not designate sender | Sending IP not in SPF record | Fix SPF SoftFail |
| 550 SPF check failed | Hard rejection at receiving server | Fix 550 SPF error |
| No SPF record found | Missing or unpublished record | Fix no SPF record |
| SPF fails on forwarded email | Forwarding server IP not authorized | Email forwarding guide |
| SPF validation error | Syntax or formatting issue | Fix SPF validation errors |
| Email rejected per SPF policy | Receiving server enforcing strict SPF | Fix SPF rejection |
| SPF record exceeds character limit | Record too long for single DNS TXT entry | Fix SPF character limit |
SPF and DMARC: Understanding Alignment
SPF can pass while DMARC still fails. This happens because SPF validates the Return-Path domain, but DMARC requires that domain to align with the visible "From:" address. When you send through a third-party service that uses their own Return-Path, SPF authenticates against their domain, not yours, and DMARC fails the alignment check.
The fix is to either configure a custom Return-Path on your domain with each provider, or rely on DKIM alignment instead (DKIM signatures survive forwarding and aren't tied to the sending IP). Set alignment mode with the aspf= tag in your DMARC record: aspf=r (relaxed, subdomains OK) or aspf=s (strict, exact match).
SPF vs. DKIM vs. DMARC: How They Work Together
These three protocols are complementary, not interchangeable. SPF verifies the sending server, while DKIM verifies message integrity with a cryptographic signature. DMARC ties both together, enforces a policy (none / quarantine / reject), and generates aggregate and forensic reports. An email passes DMARC if it passes either SPF alignment or DKIM alignment, you need both configured so one can compensate when the other breaks (e.g., SPF fails on forwarded mail, but DKIM survives).
Hosted SPF: Solving the Scalability Problem
Every SaaS tool you add to your SPF record consumes DNS lookups. Once you hit the 10-lookup limit, the entire record breaks and all SPF checks return PermError. Manual SPF flattening (replacing includes with raw IPs) works short-term but goes stale when vendors rotate their IP ranges, and they do, without warning.
PowerDMARC's automatic SPF flattening solves this by dynamically resolving include: chains into optimized records, monitoring vendor IP changes, and keeping your record under the lookup limit without manual DNS edits. For organizations using SPF macros or managing SPF across multiple domains and subdomains, hosted SPF eliminates the maintenance overhead entirely.
SPF Best Practices Checklist
Set Up SPF the Right Way
If you're setting up SPF for the first time, start with the provider-specific guides above and validate your record with PowerDMARC's free SPF checker. If you're already running SPF and hitting lookup limits or PermErrors, automated SPF flattening eliminates the maintenance overhead. And if you haven't set up DMARC yet, that's the single most impactful next step — SPF without DMARC is a lock without a door.
PowerDMARC's Free Tools
Take control of your email authentication with PowerDMARC's free SPF tools. Instantly check your domain, generate new records, or explore the full platform. No signup required.
SPF Record Checker
Check your domain's SPF record instantly, expand the full lookup chain, and identify any configuration issues.
Key Features:
- Instant lookup chain expansion: see every IP and include your record resolves to.
- Lookup counter: flags the 10-DNS-lookup limit before mail breaks.
- Error detection: catches PermError, TempError, and syntax issues.
- Unlimited and free: run unlimited checks with no signup required.
SPF Record Generator
Generate a valid SPF record tailored to your domain's senders without writing the syntax manually.
Key Features:
- Guided builder: add senders and mechanisms in a few simple steps.
- Single-record output: combines all your senders into one compliant record.
- Error-free output: produces correctly formatted SPF every time.
- Beginner-friendly: simple interface designed for quick, hassle-free setup.
PowerDMARC Toolbox
A comprehensive platform to monitor, enforce, and analyse email authentication across multiple domains.
Key Features:
- All-in-one lookup: check SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, MX, and NS records from one dashboard.
- Reputation insights: view WHOIS details, blocklist status, PTR, and FCrDNS to spot deliverability risks.
Protect and Monitor Your Domain
Generate authentication records, verify DNS configuration, and monitor your domain's email activity from a single platform. Stop spoofing, improve deliverability, and gain full visibility into who's sending email on your behalf.
Trusted by enterprises, MSPs, and security teams responsible for maintaining domain reputation and preventing spoofing.
"PowerDMARC is a very powerful and comprehensive tool that greatly simplifies the daily work of monitoring email authentication and security features. It provides visibility and clarity that would otherwise be difficult to achieve. I can genuinely recommend PowerDMARC to anyone looking to strengthen their email security posture!"
Frequently Asked Questions
My SPF record is valid but emails still go to spam. Why?
SPF is one signal among many. Email deliverability also depends on domain reputation, IP reputation, content quality, engagement history, and whether DKIM and DMARC are also configured. A passing SPF check doesn't guarantee inbox placement. Why emails go to spam and how to fix it →
Do I need SPF if I already have DKIM?
Yes. They cover different failure modes. DKIM survives forwarding but doesn't verify the sending server. SPF verifies the server but breaks on forwarding. DMARC needs at least one to pass with alignment, having both means if one fails, the other can still authenticate the message. Can you use DMARC without DKIM? →
Will switching from ~all to -all break my email?
Only if you have legitimate senders not yet listed in your record. Before switching, monitor DMARC aggregate reports for at least 2–4 weeks to identify every sending service. Once you're confident the record covers all legitimate sources, -all is the correct choice. SPF softfail vs hardfail: when to switch →
How often do SPF records need to be updated?
Every time you add or remove an email sending service. In practice, audit quarterly. Vendors change IPs, teams add tools without telling IT, and include: domains occasionally go dead. Hosted SPF handles this automatically; manual records require scheduled reviews.
Can attackers bypass SPF?
SPF has known limitations. Shared-IP services (like Mailchimp) mean any customer on the same IP range passes your SPF check. Display-name spoofing bypasses SPF entirely since it doesn't touch the Return-Path. And the BreakSPF attack demonstrated how overly permissive records with broad IP ranges can be exploited. DMARC with strict alignment mitigates these risks.
What's the difference between SPF delegation and SPF redirect?
SPF delegation lets you manage SPF for a subdomain from a different DNS zone. The redirect= modifier tells receivers to use another domain's SPF record entirely. It replaces your record rather than supplementing it. Use redirect when one domain's SPF policy should apply to another domain identically.
How long does it take for SPF changes to take effect?
DNS propagation depends on the TTL of your existing record and caching by intermediate resolvers. Typical propagation is 1–4 hours. The worst case is 48 hours. Lower your TTL to 300 seconds before making changes, then raise it back after propagation confirms.
