An email sender policy framework (SPF) is an authentication protocol that helps domain owners control which mail servers can send email on their behalf. It gives receiving mail servers a way to check whether a message came from an approved source, which makes unauthorized use of a domain harder. For organizations that send email from multiple systems, SPF is one of the core controls that helps define legitimate sending infrastructure and reduce simple spoofing attempts.
Key Takeaways
- SPF authenticates the envelope sender address used in email routing. Recipients see a separate "From" address in their inbox.
- Every SPF record must consolidate all authorized senders into a single DNS TXT entry, and exceeding 10 DNS lookups during evaluation causes a permanent error that breaks authentication for all mail from that domain.
- SPF requires DKIM and DMARC to protect the sender identity displayed to end users and to give domain owners control over how failed messages are handled.
- Domains that do not send email still need an SPF record configured to reject all senders, because an absent record leaves the domain open to impersonation.
What an SPF Record Does
An SPF record tells receiving mail servers which sources are legitimate for a domain and how to treat messages from unauthorized sources.
Authorized Sending Sources
An SPF record is a DNS TXT record that lists every IP address and domain authorized to send email for a specific domain. It gives receiving mail servers a DNS-based reference point for deciding whether a message came from an approved source. Without that record, there is no published policy to check against, which makes it easier for attackers to spoof the domain in email routing data.
Authentication and Reputation Effects
Receiving servers use that declaration during email authentication to decide whether an incoming message should be trusted, flagged, or rejected. In practice, that means the record helps limit unauthorized use of the domain and reduces the risk that fraudulent mail will damage the domain's sender reputation. The result is a more controlled sending environment, especially when the domain relies on multiple approved systems.
How the Email Sender Policy Framework Authentication Process Works
SPF authentication happens at the server level by comparing the sending server's IP address against the domain's published list of authorized senders.
Return-Path Evaluation
The process starts when an email arrives at a receiving mail server. The server extracts the domain from the Return-Path header, also called the envelope sender or MAIL FROM address, which is a routing-layer identifier separate from the "From" address visible in the recipient's inbox. The server then performs a DNS lookup to retrieve the SPF TXT record for that domain.
Mechanism Matching and Results
Once retrieved, the server evaluates the SPF record's mechanisms from left to right. It checks whether the IP address of the server that sent the message matches any of the authorized addresses or ranges listed in the record. The first mechanism that matches determines the result.
If the IP address appears in the authorized list, the message receives a "Pass" result and proceeds through any remaining checks. If the IP does not match any mechanism, the outcome depends on the qualifier attached to the record's final "all" term: a hard fail (-all) instructs the receiver to reject the message, a soft fail (~all) marks it as suspicious, and a neutral (?all) makes no assertion either way. These results feed into broader authentication decisions, particularly when DMARC is also in place.
SPF Record Syntax and Mechanisms
An SPF record follows a defined structure built from a version tag, authorization mechanisms, and a final policy qualifier.
Version Tag and IP-Based Mechanisms
Every SPF record begins with v=spf1, which identifies it as an SPF version 1 record. This tag is required, and any TXT record without it will not be interpreted as SPF.
The most straightforward mechanisms are ip4 and ip6, which authorize specific IPv4 or IPv6 addresses or CIDR ranges. These mechanisms do not require DNS resolution during evaluation, which means they do not count toward SPF's processing limits. For organizations that control their own mail infrastructure, listing IP addresses directly is the most efficient approach because it avoids consuming DNS lookup budget and removes dependencies on third-party SPF records.
Include, A, MX, and All
When a domain uses third-party services for email, such as a marketing platform or a cloud-hosted email provider, those services typically instruct the domain owner to add an include mechanism pointing to the service's own SPF record. The receiving server then recursively evaluates that external record as part of the check. Adding an include tells the receiving server to also accept IPs authorized by that provider's SPF record.
Two other mechanisms appear frequently. The a mechanism authorizes any IP matching the domain's A or AAAA DNS record, and the mx mechanism authorizes the IPs of the domain's mail exchange servers. Both require DNS resolution and count toward processing limits.
Every SPF record ends with an all mechanism paired with a qualifier. The four qualifiers are + (Pass, the default if omitted), - (Fail), ~ (SoftFail), and ? (Neutral). The choice between -all and ~all determines how strictly receiving servers treat unauthorized senders. Hard fail (-all) reduces the risk of unauthorized systems sending mail as the domain.
Why Email Sender Policy Framework Matters for Domain Security and Deliverability
Email sender policy framework matters because it gives receiving servers a verifiable list of authorized sending sources. That makes domain spoofing harder and gives domain owners stronger control.
Protection Against Spoofing
Email spoofing, where an attacker forges the sender address to impersonate a trusted organization, remains one of the most common tactics in phishing attacks and business email compromise (BEC). According to the 2025 IC3 report, BEC losses reached $3.04 billion that year. SPF provides a baseline defense by enabling receiving servers to reject or flag messages from servers that are not on the domain's authorized list. It eliminates a common form of spoofing: sending from an unauthorized IP while claiming a legitimate domain in the envelope sender field.
Control Over Sending Infrastructure
Beyond security, publishing SPF records helps domain owners control which systems are authorized to send on their behalf. That matters for deliverability as well as trust, because a domain with a clearly defined sending policy is easier for receiving systems to evaluate. In practice, SPF gives organizations a cleaner way to separate approved mail flows from unauthorized ones, even though other protocols are still needed to protect the visible sender identity.
Common Email Sender Policy Framework Limitations
Email sender policy framework solves a narrow authentication problem, and its technical limits can break validation or leave visible sender identity unprotected.
The 10 DNS Lookup Limit
SPF evaluation is restricted to a maximum of 10 DNS mechanism lookups per check. The mechanisms that count toward this limit are include, a, mx, ptr, and exists; IP-based mechanisms (ip4, ip6) and the all qualifier do not count because they require no DNS resolution. Exceeding the limit produces a PermError, a permanent failure that causes SPF authentication to fail for every message from the domain until the record is corrected. SPF evaluation also has a separate void lookup limit: implementations should return PermError when more than 2 DNS queries return no usable records during evaluation, which can be triggered by stale include entries pointing to defunct services.
This limit becomes a practical problem as organizations add third-party email services. Each include mechanism consumes at least one lookup, and nested includes within the referenced record consume additional lookups from the same budget. A common mitigation is subdomain delegation: routing distinct mail streams such as marketing, transactional, and internal email through separate subdomains, each with its own SPF record and its own 10-lookup budget.
Forwarding Failures and Identity Gaps
SPF checks the IP address of the server that connects to the receiving mail server. When a message is forwarded, the forwarding server's IP is what gets evaluated, but the Return-Path domain still points to the original sender's SPF record. Since that record does not authorize the forwarding server, SPF fails for the forwarded copy even though the original message was legitimate. This architectural limitation comes from SPF's design. DKIM compensates for this weakness because DKIM signatures travel with the message body and do not depend on the sending server's IP.
A related gap involves the distinction between the envelope sender and the visible sender identity. SPF authenticates the Return-Path address, the envelope sender used during SMTP routing. Recipients see the "From" header in their email client. These two fields can contain different domains. An attacker can send a message from a server legitimately authorized in one domain's SPF record while displaying a completely different domain in the visible From header: the SPF check passes, but the recipient sees a spoofed identity. DMARC addresses this gap by requiring that the domain authenticated by SPF, or DKIM, aligns with the domain in the visible From header.
Duplicate Records and Permissive Policies
Two common misconfigurations cause immediate SPF failures. First, publishing multiple SPF records, two or more TXT records beginning with v=spf1, for the same domain produces a PermError. This typically happens when an organization adds a new email provider and creates a second SPF record without consolidating it into the existing one. All authorized senders must be listed in a single record. Organizations should verify whether an existing SPF record is published before adding any new entry.
Second, using +all, which authorizes every IP address on the internet, or excessively broad IP ranges effectively disables SPF protection. Authorize only the specific IPs currently in use for sending, and avoid broad ranges that could inadvertently authorize other users on shared infrastructure.
How SPF Works With DKIM and DMARC
SPF, DKIM, and DMARC work as a layered system because each one validates a different part of email identity and handling.
Protocol Roles
SPF verifies that the sending server's IP address is authorized by the envelope sender's domain. DKIM verifies that a cryptographic signature attached to the message was generated by a server authorized by the signing domain. This confirms that the message was not altered in transit. The two protocols are complementary: SPF is tied to the server connection and breaks during forwarding, while DKIM is tied to the message itself and breaks when content is modified, such as when mailing lists add footers.
DMARC Alignment and Policy
DMARC sits on top of both protocols and adds two capabilities that neither provides alone. First, it requires identifier alignment, meaning the domain authenticated by SPF or DKIM must match the domain in the visible From header. This closes the envelope-to-header gap described above. Second, it gives domain owners a policy mechanism: they can instruct receiving servers to reject, quarantine, or simply monitor messages that fail authentication, and they receive aggregate reports showing how their domain is being used across the internet.
For DMARC to pass, at least one of SPF or DKIM must both pass its check and be in alignment with the From header domain. CISA's BOD 25-01 guidance also requires agencies to implement SPF and reach a DMARC policy of reject.
How To Create and Validate an SPF Record
Creating an SPF record means identifying every authorized sender, publishing one complete DNS TXT record, and checking that the policy stays within SPF limits.
Authorized Sender Inventory
The process starts with identifying every service that sends email on behalf of the domain. This includes the organization's primary email provider, third-party platforms such as marketing automation or transactional email services, and any other infrastructure that generates outbound email. Organizations should then list directly controlled IP addresses using ip4 or ip6 mechanisms, add include mechanisms for each third-party service, and select an all qualifier: -all for production domains where all senders have been identified, or ~all during a transition period.
Publication and Validation
Before publishing, the total number of DNS-resolving mechanisms should be verified against the 10-lookup limit, including nested includes within referenced records. The record should be published as a single TXT entry in the domain's DNS settings, and only one TXT record beginning with v=spf1 should exist for the domain. After publishing, an SPF validation tool can confirm correct syntax, verify that all authorized IPs are listed, and check that the DNS lookup count is within limits. Domains that do not send email should still publish v=spf1 -all to prevent attackers from impersonating them.
Building a Stronger Email Authentication Foundation
SPF provides a necessary first layer of email authentication by giving domain owners control over which servers can send on their behalf. Its value depends on correct implementation, ongoing maintenance, and deployment alongside DKIM and DMARC to cover the gaps it cannot address alone. Organizations that treat SPF as one part of a three-protocol system will build a more resilient defense against email impersonation and protect both their recipients and their domain reputation.
Frequently Asked Questions
What Is the Difference Between SPF, DKIM, and DMARC?
SPF checks whether the sending server is authorized for the envelope sender domain. DKIM checks whether the message carries a valid signature tied to the signing domain. DMARC builds on those checks by requiring alignment with the visible From address and by letting domain owners define how failed messages should be handled.
Can a Domain Have More Than One SPF Record?
No. A domain can publish many TXT records, but only one of them can be the SPF policy that begins with v=spf1. If more than one SPF record exists for the same domain, receivers can treat that as a permanent error, which breaks SPF evaluation for mail from that domain.
Should I Use -All or ~All in My SPF Record?
The stricter choice is -all, which tells receiving systems that unauthorized senders should fail. The more cautious choice is ~all, which signals that unauthorized mail is suspicious but stops short of a hard rejection instruction. In practice, ~all is often used while a domain owner is still confirming every legitimate sender.
Why Does SPF Fail When Email Is Forwarded?
Forwarding changes the server that delivers the message to the next recipient. SPF evaluates that connecting server, so the forwarded copy often no longer matches the original sender's SPF policy. That is why forwarding can break SPF even when the original message was legitimate.
Does SPF Prevent Email Spoofing?
SPF helps prevent spoofing tied to unauthorized sending servers. SPF checks the envelope sender while recipients see the From header, so a message can still appear to come from a different visible domain. That gap is why SPF is strongest when it works alongside DKIM and DMARC.
