SPF is an acronym for Sender Policy Framework. It outlines a form of authentication used by ISPs for detecting fake sender addresses while receiving emails. DNS TXT records for the sending domain are used to determine if the sending IP address is a legitimate one. This is the very first step you can take to prevent spoofing of your sending domains. The purpose of SPF is to rectify a vulnerability in the SMTP protocol wherein the sender address is not validated.
Since February 2024, Google and Yahoo have enforced sender authentication requirements for bulk senders, and Sender Policy Framework is no longer just an early, optional step.
It is now a baseline requirement for reaching the inbox. Mail from domains without a properly configured SPF record is far more likely to be filtered to spam or rejected outright in 2026, regardless of how clean the message content looks.
A Brief History of SPF
The very first time SPF was mentioned was way back in the year 2000, but it went mostly unnoticed. A second attempt was made later in the year 2002, and that was the genesis of the Sender Policy Framework that we know today.
The original experimental specification was published as RFC 4408 in 2006, and that early standard was later refined and replaced by RFC 7208, published in 2014, which remains the current SPF standard used today.
How Does Sender Policy Framework (SPF) Work
SPF allows you to specify which email servers are authorized to send emails on your behalf. This is accomplished using DNS records. Receiving email servers will verify the SPF information included in the DNS records of the sending domain and will accordingly either flag the email as SPF pass or fail. In most cases, the mail that does not pass the SPF test is rejected.
Most receiving servers today do not rely on the SPF result alone to make a final decision. Instead, the SPF outcome typically feeds into a DMARC policy, which then determines whether the message is accepted, quarantined, or rejected based on the combined result of SPF and DKIM together.
What is an SPF Record
An SPF record is a DNS TXT record that specifies the servers that are allowed to send mail on behalf of your domain. In most cases, there should be just a single SPF record per domain.
An example of an SPF record is a TXT record like the one given below.
yourdomain.com, TXT, “v=spf1 a mx include:anotherdomain.com ~all”
In this example, the valid senders are the servers in the “A” and “MX” record for “yourdomain.com” and the servers described in the SPF TXT records for “anotherdomain.com”.
How Do We Verify Our SPF Records?
The first thing you might want to do is check if you have published your DNS TXT record for SPF correctly. Going back to the example we looked at earlier.
yourdomain.com, TXT, “v=spf1 a mx include:anotherdomain.com ~all”
You can see that it ends with “~all”. Now there are a few other options for the qualifier “~”. It can be any of the four values given below.
- “+” Pass
- “-” Fail
- “~” SoftFail
- “?” Neutral
Evaluation of the SPF record has the following results based on the four qualifiers:
| Result | Explanation | Intended Action |
| Pass | The record indicates that this host can send email on behalf of the domain | Accept |
| Fail | The record indicates that the host should not be allowed to send | Reject |
| SoftFail | The record indicates that the host should not be allowed to send but is in transition | Accept but mark |
| Neutral | The record indicates that nothing can be said about validity | Accept |
| None | The domain does not have a valid SPF record | Accept |
| PermError | The record is poorly formatted, which has led to a permanent error | Unspecified |
| TempError | A transient error has occurred | Accept or reject |
Fortunately, there are a few good online tools that can verify that you have set up your SPF records correctly.
- Scott Kitterman’s SPF tools: https://www.kitterman.com/spf/validate.html
- Mxtoolbox’s SPF lookup: https://mxtoolbox.com/spf.aspx
- Dmarcanalyzer: https://www.dmarcanalyzer.com/spf/checker/
Always recheck the record after any DNS or mail server change before sending at volume. A small unverified change can quietly break authentication for an entire campaign.
Limitations of SPF (Sender Policy Framework)
The SPF policy clearly states that you cannot have more than 10 DNS lookups to resolve a single SPF record. So when you are allowing another service to send on your behalf, make sure that their SPF records do not go further back.
Every time you change your mail servers, you will need to modify the SPF records with the new information.
SPF records refer to the return-path header in your emails. They are unfortunately not connected to the readable “From” address that shows up in the content. Most people never look at the return path, and that becomes a problem.
The 10-DNS-lookup limit is one of the most common failure points in 2026, since most businesses now rely on several third-party senders, marketing platforms, CRMs, and support tools that each add their own lookups to the chain.
SPF flattening or consolidation is often needed to stay under the limit. And because SPF alone never protects the visible “From” address that the recipient actually sees, it must be paired with DKIM and DMARC for real protection against spoofing.
How This Benefits You
Even though it is not mandatory for you to publish an SPF record for your domain, having one enables your email recipients to authenticate against it. SPF in itself does not guarantee that your domain will be unspoofable, but when used in conjunction with DKIM and DMARC, it can be very effective.
SPF is only one leg of the modern authentication stack. A complete setup in 2026 includes SPF, DKIM, and DMARC together, with BIMI layered on top for brands that want their verified logo to display directly in the recipient’s inbox.
For a closer look at how the signature side of this stack works, see our full DKIM guide. SpiceSend handles this authentication setup for you, so your domain is configured correctly from the very start instead of being pieced together after deliverability problems show up.
SPF, DKIM and DMARC: How They Fit Together
Sender Policy Framework does not work in isolation. It is one piece of a three-part authentication stack that inbox providers now expect every sender to have configured correctly.
SPF authorizes which sending servers are allowed to send mail on behalf of a domain. DKIM adds a cryptographic signature that proves a message’s content was not altered in transit.
DMARC sits above both, setting the policy for what receiving servers should do when SPF or DKIM checks fail, reject, quarantine, or allow through, while also providing reporting so a domain owner can see exactly who is sending mail using their name.
Heading into 2026, major inbox providers including Gmail, Yahoo, and Outlook expect all three protocols working together, not just one. SPF on its own leaves the visible “From” address completely unprotected, which is exactly the gap DKIM and DMARC are built to close. For the full picture of how the signing side works, read our companion guide on DKIM.
Common SPF Mistakes (and How to Fix Them)
A handful of recurring mistakes account for most SPF failures.
Exceeding the 10-DNS-lookup limit is the most frequent issue as businesses add more third-party senders over time. Audit your record regularly and consolidate or flatten includes to stay under the limit.
Publishing more than one SPF record for the same domain causes validation to fail entirely, since the standard only allows a single record. Merge all authorized senders into one record instead.
Using “+all” instead of a stricter qualifier tells receiving servers to accept mail from anywhere, which defeats the entire purpose of SPF. Use “~all” or “-all” instead.
Forgetting to add a new third-party sender, such as a new marketing platform or invoicing tool, causes their legitimate mail to fail SPF. Update the record every time a new sending service is added.
Not updating the record after a mail-server change leaves the SPF record pointing to outdated infrastructure. Treat SPF updates as a required step in any mail-server migration, not an afterthought.
Frequently Asked Questions
What is Sender Policy Framework (SPF) and how does it work?
Sender Policy Framework is an email authentication standard that lets a domain owner specify exactly which mail servers are authorized to send email on the domain’s behalf.
The authorization is published as a DNS TXT record. When an email arrives, the receiving server checks the sending server against that published record and returns a pass, fail, or one of several other defined results, which then informs how the message is handled.
What does an SPF record look like?
An SPF record is a DNS TXT record that typically begins with “v=spf1” followed by a list of authorized servers and domains, ending with a qualifier such as “~all” or “-all”.
A simple example reads “v=spf1 a mx include:anotherdomain.com ~all”, which authorizes the domain’s own A and MX records along with any servers listed in anotherdomain.com’s own SPF record.
What is the difference between SPF, DKIM and DMARC?
SPF authorizes which servers can send mail for a domain. DKIM adds a digital signature that verifies a message was not altered in transit. DMARC builds on both, telling receiving servers what action to take when SPF or DKIM checks fail, and provides reporting visibility into the domain’s email traffic. The three protocols are designed to work together, not as standalone substitutes for one another.
Is SPF required for email delivery in 2026?
Yes, in practical terms. While SPF is not legally mandated, Google and Yahoo have required it alongside DKIM and DMARC for any bulk sender since February 2024, and Microsoft introduced comparable requirements for Outlook and Hotmail in 2025.
In 2026, sending meaningful volume without a properly configured SPF record significantly increases the risk of messages landing in spam or being rejected entirely.
