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.
What is SPF?
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.
- Pass: If the delivering server’s IP address is on the list, the email passes the SPF check, signaling it is a legitimate communication.
- Fail: If the IP address is not on the list, the email fails the check. Depending on the domain’s policy, the receiving server will flag the message as spam, quarantine it, or reject it outright before it ever reaches the user’s inbox.
Why SPF is Non-Negotiable in Modern Business
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.
- Guarding Domain Reputation: Major Internet Service Providers (ISPs) and mailbox providers like Google, Microsoft, Yahoo, and Apple track the sending reputation of your domain. If spammers spoof your domain to send malicious content, your reputation drops. SPF stops unauthorized use, protecting your standing.
- Strict Sender Requirements (2024 Updates): In early 2024, Google and Yahoo implemented strict new sender requirements aimed at bulk senders. If you send mail to Gmail or Yahoo accounts without a valid SPF record (and DKIM), your emails will be actively blocked or routed straight to the spam folder.
- Foundation for Advanced Security (DMARC & BIMI): SPF is the foundational layer upon which DMARC (Domain-based Message Authentication, Reporting, and Conformance) and BIMI (Brand Indicators for Message Identification) are built. You cannot achieve full email security, nor can you display your brand logo in the inbox, without a perfectly configured SPF record.
How SPF Works
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:
- The Header “From” (Visible): This is the address that the human recipient sees in their email client (like Microsoft Outlook or Apple Mail). It is incredibly easy to forge and is not what SPF checks.
- The Envelope “From” (Hidden): Also known as the Return-Path or mfrom (Mail From), this is the address used by the mail servers to route bounce messages and delivery errors. This is the exact address that SPF checks.
The Step-by-Step Validation Process
- The Connection: The Sending Mail Transfer Agent (MTA) opens an SMTP connection with the Receiving MTA.
- The Envelope Delivery: The Sending MTA issues the MAIL FROM: command, providing the hidden Envelope “From” address (e.g., MAIL FROM:<billing@example.com>).
- The IP Capture: The Receiving MTA immediately records the public IP address of the Sending MTA that is currently connected to it.
- The DNS Query: The Receiving MTA extracts the domain (example.com) from the Envelope “From” address. It then queries the DNS records of example.com, specifically looking for a TXT record that begins with the string v=spf1.
- The Evaluation: Once found, the Receiving MTA parses the SPF record from left to right. It evaluates the captured IP address against the mechanisms and rules defined in the record.
- The Verdict: Based on the evaluation, the Receiving MTA generates an official SPF result and applies that result to its internal spam-filtering algorithms to decide the fate of the message.
Anatomy of an SPF Record
An SPF record is a single, unbroken string of text. It consists of three primary components: the Version Tag, the Mechanisms, and the Qualifiers.
1. The Version Tag (v=spf1)
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.
2. Mechanisms (The “Who”)
Mechanisms are the building blocks that define exactly who is authorized. The server reads these from left to right until it finds a match.
- ip4: Authorizes a specific IPv4 address or an IP network range using CIDR notation. This is highly efficient because it requires no additional DNS lookups. (Example: ip4:192.168.0.1 or ip4:10.0.0.0/24)
- ip6: Authorizes a specific IPv6 address or network range. (Example: ip6:2001:db8::/32)
- include: The most heavily used mechanism for third-party cloud services. It tells the receiving server to pause, look at the SPF record for another specified domain, and apply its rules as if they were your own. (Example: include:_spf.google.com)
- a: Authorizes the IP address found in the domain’s primary “A” record (usually the IP address of your main website).
- mx: Authorizes the IP addresses of the servers listed in the domain’s MX (Mail Exchange) records.
- ptr (DEPRECATED): Performs a reverse DNS lookup to see if the IP address resolves back to the domain. It is painfully slow, resource-heavy, and officially discouraged by RFC 7208. Do not use this under any circumstances.
- exists: A highly advanced mechanism used to check if an A record exists for a given domain. It is almost exclusively used in complex enterprise environments utilizing dynamic SPF Macros.
3. Modifiers (The “Extras”)
Modifiers provide additional instructions but do not directly authorize IP addresses themselves.
- redirect=: Tells the receiving server to ignore the current record entirely and go evaluate the SPF record found at another domain. This is incredibly useful if a parent company manages hundreds of subdomains and wants them all to point to one master policy. (Example: v=spf1 redirect=_spf.masterdomain.com)
- exp=: Provides a custom explanation error message to the sender if their email is rejected. This is largely obsolete in modern email environments.
4. Qualifiers
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 |
A Complete Real-World Example
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
- v=spf1: Declares this as an SPF record.
- ip4:203.0.113.5: Explicitly authorizes a specific on-premise private server to send mail.
- include:spf.protection.outlook.com: Authorizes Microsoft 365 Exchange servers to send corporate email.
- include:servers.mcsv.net: Authorizes Mailchimp servers to send marketing newsletters.
- -all: Instructs receiving servers to flatly reject any email claiming to be from this domain if it did not originate from the IP, Microsoft, or Mailchimp.
Understanding SPF Evaluation Results
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.
- Pass: The sender’s IP matched an authorized mechanism. The email safely moves to the next security checkpoint (like DKIM verification and content filtering).
- Fail: The IP did not match any mechanism, and the record ended in -all. The email is typically rejected outright at the gateway and never reaches the user.
- SoftFail: The IP did not match, and the record ended in ~all. The email is accepted but heavily penalized in internal spam scoring algorithms, usually resulting in spam folder placement.
- Neutral: The IP did not match, and the record ended in ?all. No penalty or reward is applied based on SPF.
- None: The receiving server could not find any valid SPF TXT record in the domain’s DNS.
- TempError (Temporary Error): The receiving server encountered a temporary DNS timeout or network issue while trying to look up the SPF record. The server will usually return a 4xx SMTP error code and try again later.
- PermError (Permanent Error): The SPF record exists but is fundamentally broken and cannot be interpreted. This happens due to syntax errors, multiple v=spf1 records, or exceeding lookup limits. A PermError is treated identically to a Fail.
The Technical Limits of SPF (Avoiding PermErrors)
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.
1. The 10-DNS-Lookup Limit
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.
- Mechanisms that COUNT as a lookup: include, a, mx, ptr, exists, redirect.
- Mechanisms that DO NOT count: ip4, ip6, all.
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.
2. The 255-Character String Limit
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.
- The Workaround: You must split the record into multiple contiguous strings enclosed in quotes within the same TXT record (e.g., “v=spf1 ip4:1.2.3.4…” ” include:_spf.google.com ~all”). The receiving server will seamlessly concatenate them back together.
- Warning: Do not create multiple separate TXT records. Multiple strings inside one record are fine; multiple SPF records on one domain will cause a PermError.
3. The Void Lookup Limit
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.
Solving the 10-Lookup Limit
When large organizations hit the constraints of SPF, they cannot simply delete vendors. They must employ advanced architectural strategies.
Strategy 1: Subdomain Partitioning (The Best Practice)
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.
- Root Domain (@company.com): Used only for corporate, human-to-human email (Google Workspace/Microsoft 365).
- Marketing (@news.company.com): Used for Mailchimp, Marketo, or HubSpot.
- Support (@help.company.com): Used exclusively for Zendesk, Intercom, or Salesforce Service Cloud.
- Transactional (@receipts.company.com): Used for SendGrid or Postmark.
Strategy 2: SPF Flattening
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.
- Before Flattening: v=spf1 include:salesforce.com include:zendesk.com ~all (Consumes 8+ lookups).
- After Flattening: v=spf1 ip4:13.108.0.0/14 ip4:192.161.144.0/20 ~all (Consumes 0 lookups).
- The Danger of Flattening: Cloud providers frequently change and expand their IP addresses. If Salesforce adds a new IP range and your flattened record isn’t updated, your Salesforce emails will suddenly fail SPF. Therefore, flattening must never be done manually; it requires automated vendor software that dynamically monitors and updates your DNS via API.
Strategy 3: SPF Macros (Dynamic SPF)
For massive enterprises or ISPs hosting thousands of domains, static SPF records are insufficient. SPF Macros allow the creation of dynamic records using variables.
- %{i}: Represents the sender’s IP address.
- %{s}: Represents the sender’s email address.
- %{d}: Represents the sender’s domain.
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.
Quick-Start Guides: Platform-Specific SPF Setup
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.
- Record: v=spf1 include:_spf.google.com ~all
Microsoft 365 (Office 365)
Microsoft routes all outbound mail through a specific protection domain.
- Record: v=spf1 include:spf.protection.outlook.com ~all
Mailchimp
Mailchimp recommends utilizing subdomains, but if you must use your root domain:
- Record: v=spf1 include:servers.mcsv.net ~all
Shopify
To ensure order confirmations and receipts land in the inbox:
- Record: v=spf1 include:shops.shopify.com ~all
(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)
The Great SPF Weakness: The Forwarding Problem
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).
- Alice’s server sends the message to the University. (SPF Passes, because Alice’s server is authorized by example.com).
- The University server forwards the email to Gmail.
- Gmail checks the Envelope “From” (which still says alice@example.com), but the IP address delivering the message is now the University’s server IP.
- Gmail checks the SPF record for example.com. The University’s IP is not on Alice’s list.
- Result: SPF Fails. Gmail marks Alice’s highly legitimate email as spam.
The Solution: SRS (Sender Rewriting Scheme)
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.
The Authentication Triad: SPF vs. DKIM vs. 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.
DKIM (DomainKeys Identified Mail)
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.
- Why it complements SPF: DKIM survives email forwarding. Even if the IP address changes during a forward (breaking SPF), the digital signature remains intact within the email body, proving to the final destination that the email is legitimate.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC is the master policy layer that unites SPF and DKIM. It does two critical things:
- Enforces Alignment: SPF checks the Envelope “From,” which the user never sees. An attacker could buy a cheap domain (scam.com), set up a valid SPF record for it, and then change the visible Header “From” to ceo@yourcompany.com. SPF would technically pass, and the user would be fooled. DMARC stops this by requiring Alignment. For DMARC to pass, the domain in the hidden Envelope “From” (checked by SPF) must exactly match the domain in the visible Header “From”.
- Sets the Rules: DMARC tells the receiving server exactly what to do if an email fails both SPF and DKIM (None, Quarantine, or Reject).
Frequently Asked Questions (FAQs)
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.
Managing and Troubleshooting SPF
Discovering “Shadow Senders” via DMARC Reports
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.
Common Troubleshooting Scenarios
Scenario 1: “My new marketing tool’s emails are going straight to spam.”
- Cause: You likely forgot to add their specific include statement to your SPF record.
- Fix: Edit your existing TXT record to add the new include. Do not create a second TXT record.
Scenario 2: “MxToolbox says I have a PermError: Too many lookups.”
- Cause: Your combined include mechanisms are requiring more than 10 DNS lookups to fully resolve.
- Fix: Audit your record. Remove legacy vendors you no longer use, replace nested includes with static ip4 ranges where possible, migrate high-volume senders to subdomains, or implement an automated dynamic SPF flattening service.
Scenario 3: “My SPF record is perfectly valid, but emails forwarded to Gmail are failing.”
- Cause: This is the standard forwarding problem. The intermediate server is changing the IP address without rewriting the Envelope From via SRS.
- Fix: Ensure you have DKIM fully configured and signing your outbound mail. Since DKIM survives forwarding, it will allow the email to pass the final DMARC check even when SPF inherently breaks.
Conclusion
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.
