To truly understand the Sender Policy Framework (SPF) , you must first understand the environment it was built to protect. When the Simple Mail Transfer Protocol (SMTP) was developed in the early 1980s, the internet was a small, academic, and highly trusted network. SMTP was designed simply to route messages efficiently from point A to point B. It was not designed to verify the identity of the person or machine sending the message.
Because of this architectural oversight, SMTP allows anyone to claim they are anyone else. Just as you can write a fake return address on a physical envelope and drop it in a public mailbox, a malicious actor can connect to a mail server and send an email claiming to be ceo@yourcompany.com.
This practice, known as email spoofing , became the foundation for global spam operations, targeted phishing campaigns, and devastating Business Email Compromise (BEC) attacks. As the internet exploded in commercial popularity, the lack of authentication became a critical vulnerability. The industry desperately needed a mechanism to verify that an email claiming to come from a specific domain was actually authorized by the true owner of that domain.
Enter SPF, standardized by the Internet Engineering Task Force (IETF) in RFC 7208. SPF provides a public, verifiable list of authorized sending servers for any given domain, turning the “honor system” of early email into a strict, cryptographic security checkpoint.
SPF (Sender Policy Framework) is an open-standard email authentication protocol. It allows a domain owner to specify exactly which mail servers, IP addresses, or third-party hostnames are authorized to send email on behalf of their domain.
It operates entirely using the Domain Name System (DNS) . The domain owner publishes an SPF record , which is a specifically formatted line of text added to their DNS settings as a TXT record. When an email is sent across the internet, the receiving mail server looks up this DNS record and checks if the server attempting to deliver the email is on the approved list.
In the modern email landscape, implementing SPF is no longer an optional “best practice”—it is a mandatory baseline requirement for any business that relies on digital communication.
To understand how SPF validates an email, we have to look “under the hood” at how servers communicate during an SMTP transaction. This technical process is crucial for troubleshooting deliverability issues later.
When you send an email, there are actually two different “From” addresses involved in the transaction:
An SPF record is a single, unbroken string of text. It consists of three primary components: the Version Tag, the Mechanisms, and the Qualifiers.
Every SPF record must begin with v=spf1. This explicitly identifies the TXT record to the parsing server as an SPF protocol record. If a record starts with v=spf2 (which was associated with the deprecated Sender ID framework) or lacks the prefix entirely, receiving servers will ignore it completely.
Mechanisms are the building blocks that define exactly who is authorized. The server reads these from left to right until it finds a match.
Modifiers provide additional instructions but do not directly authorize IP addresses themselves.
The qualifier is the symbol placed at the very end of the record, directly attached to the all mechanism. It dictates the strictness of your policy for senders who fail the check.
| Qualifier | Name | Action | Security Posture |
| — | — | — | — |
| -all | Hard Fail | Reject the email. Only explicitly listed senders are authorized. | Maximum Security |
| ~all | Soft Fail | Accept the message but mark it as suspicious (sends to spam). | Moderate / Testing |
| ?all | Neutral | No policy regarding unlisted senders. Treats mail as if there is no SPF record. | Zero Security |
| +all | Pass | Authorizes every IP address on earth to send on your behalf. | Dangerously Insecure |
Let’s dissect a typical corporate SPF record:
v=spf1 ip4:203.0.113.5 include:spf.protection.outlook.com include:servers.mcsv.net -all
When an MTA evaluates an SPF record, the result is more granular than a simple “yes” or “no.” The server generates a specific status code that dictates the email’s fate.
SPF is an incredibly powerful protocol, but it was purposefully designed with strict limitations to prevent abuse and protect the global DNS infrastructure from being overwhelmed by infinite loops. Violating these limits is the number one cause of broken email authentication.
This is the most infamous and frequently violated rule in email administration. RFC 7208 dictates that evaluating an SPF record cannot require more than 10 DNS lookups .
The “Nested Include” Trap:
The 10-lookup limit includes *recursive* lookups. If you add include:_spf.google.com to your record, that counts as one lookup. However, if Google’s SPF record contains three include statements of its own, evaluating Google’s record takes three more lookups. You have now consumed 4 of your 10 available lookups just by adding Google Workspace.
In a modern enterprise utilizing Google Workspace, Salesforce, Zendesk, Mailchimp, and a payroll tool, you will easily exceed 10 lookups without realizing it, instantly breaking your email authentication and generating a PermError.
A single string within a DNS TXT record cannot technically exceed 255 characters. If your SPF record is very long due to multiple IP ranges, you cannot simply paste it as one giant block in some older DNS managers.
To prevent malicious actors from tying up DNS servers by pointing to domains that don’t exist, SPF limits “void” lookups (DNS queries that return an empty response or a timeout error) to a maximum of two. If your include statements point to defunct companies, legacy vendors, or dead domains, your entire record will fail.
When large organizations hit the constraints of SPF, they cannot simply delete vendors. They must employ advanced architectural strategies.
The cleanest, most secure way to avoid the 10-lookup limit is to stop sending all mail from your root domain (@company.com). Instead, delegate specific software functions to dedicated subdomains.
Because DNS evaluates SPF strictly based on the exact domain found in the Return-Path, each subdomain gets its own independent 10-lookup limit , entirely solving the congestion problem.
If subdomain partitioning is impossible due to branding guidelines, IT administrators turn to SPF Flattening. This is the process of resolving all include domains down to their base ip4 and ip6 addresses, and listing those raw IPs directly in the SPF record.
For massive enterprises or ISPs hosting thousands of domains, static SPF records are insufficient. SPF Macros allow the creation of dynamic records using variables.
When an IP connects, the receiving server reconstructs the query using the macro to ask a specific question to the enterprise DNS server, allowing for real-time, dynamic IP authorization based on internal threat intelligence.
If you use major cloud providers, setting up SPF requires specific syntax. Here are the exact include statements for the most popular platforms.
Google Workspace (G Suite)
If you use Gmail for your business, you only need one mechanism.
Microsoft 365 (Office 365)
Microsoft routes all outbound mail through a specific protection domain.
Mailchimp
Mailchimp recommends utilizing subdomains, but if you must use your root domain:
Shopify
To ensure order confirmations and receipts land in the inbox:
*(Note: Always merge these into a single record. If you use both Google and Shopify, your record is:* *v=spf1 include:_spf.google.com include:shops.shopify.com ~all* *)*
While SPF is an excellent foundational security measure, it has a fatal flaw: it breaks when emails are auto-forwarded.
Imagine Alice (alice@example.com) sends an email to Bob (bob@university.edu). Bob has set up his university account to automatically forward everything to his personal Gmail account (bob@gmail.com).
To fix this, intermediate forwarding servers must implement SRS (Sender Rewriting Scheme) . SRS actively alters the Envelope “From” address during the forward. Instead of passing along alice@example.com, the University server rewrites the Envelope “From” to something like SRS0=abc=example.com=alice@university.edu.
When Gmail receives this, it checks the SPF record for university.edu. Because the University server is obviously authorized to send for its own domain, SPF passes.
*While SRS fixes the technical SPF failure, you cannot control whether a forwarding server uses SRS. This highlights exactly why SPF alone is not enough, bringing us to DKIM and DMARC.*
SPF is powerful, but because it relies on the hidden Return-Path and routinely breaks during forwarding, it must be paired with DKIM and DMARC to achieve true security and deliverability.
Where SPF validates the *server* using IP lists, DKIM validates the *content* using cryptography. The sending server attaches a digital “wax seal” (a cryptographic signature) to the email headers. The receiving server uses a public key found in the sender’s DNS to verify the signature.
DMARC is the master policy layer that unites SPF and DKIM. It does two critical things:
Can I have multiple SPF records on one domain?
No. You can only have one TXT record that begins with v=spf1. If you have multiple services, you must combine their mechanisms into a single, unified string. Having multiple records will result in a PermError and authentication failure.
Does SPF check the “From” address I see in my email app?
No. SPF only checks the Envelope “From” (Return-Path) address, which is hidden in the email headers and used for routing bounces. This is why DMARC is necessary—to force the visible “From” address to align with the authenticated Envelope “From”.
How long does it take for a new SPF record to work?
Because SPF relies on DNS, changes are subject to DNS propagation. Depending on the TTL (Time to Live) set on your previous TXT record, it can take anywhere from 15 minutes to 48 hours for the global internet to recognize your new SPF policy.
What is the difference between ~all and -all ?
~all is a Soft Fail. It tells receiving servers that unlisted IPs are suspicious but should still be accepted (usually routed to spam). It is used during setup to prevent accidentally blocking legitimate mail. -all is a Hard Fail, instructing servers to strictly reject any unlisted IP. -all is the ultimate goal for maximum security.
You should never transition your SPF record from a SoftFail (~all) to a HardFail (-all) blindly. You must implement DMARC in “report-only” mode (p=none) first.
Major mail providers (Google, Yahoo, Microsoft) will send you daily XML reports showing every single IP address that sent an email claiming to be from your domain. By analyzing these reports, you can discover forgotten internal servers, rogue marketing tools purchased by other departments, and active phishing campaigns. Once your reports prove that 100% of your legitimate mail is correctly passing SPF, you can safely lock down your domain with -all.
Scenario 1: “My new marketing tool’s emails are going straight to spam.”
Scenario 2: “MxToolbox says I have a PermError: Too many lookups.”
Scenario 3: “My SPF record is perfectly valid, but emails forwarded to Gmail are failing.”
The Sender Policy Framework is the absolute bedrock of modern email security. While the internet has evolved drastically since the inception of SMTP, the core need to verify digital identity remains paramount.
Mastering SPF requires far more than just pasting a line of text into your DNS panel. It requires a holistic understanding of your organization’s digital footprint, a deliberate strategy for managing DNS lookup limits, and a commitment to pairing SPF with DKIM and DMARC. By adhering to the technical specifications and architectural best practices outlined in this guide, you can eliminate domain spoofing, fiercely protect your brand’s reputation, and ensure that your legitimate business communications always find their way to the inbox.
Learn how to set up SPF, DKIM, and DMARC for Salesforce Sales Cloud, Marketing Cloud, and Pardot. Fix the SPF alignment problem and reach full DMARC compliance.
Hitting SPF PermError: too many DNS lookups? Learn exactly what causes it, how it breaks DMARC, and the practical steps to fix your SPF record for good.
Tell us where your domains stand today and we will take it from there.
