What Is SPF: How Sender Policy Framework Prevents Email Spoofing, Improves Deliverability, and Lays the Groundwork for DMARC

Email was built on a protocol that takes every sender at its word. SMTP, standardized in 1982, allows any server to claim any domain, and that single design decision turned corporate email into the most reliably exploited entry point in enterprise security. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest number of reports in any crime category.

The question of what is SPF surfaces the moment a security team confronts that gap and looks for a way to close it. Domain owners need a mechanism to declare, publicly and verifiably, which servers may send on their behalf, and receiving servers need something authoritative to check against.

This guide covers:

• What Sender Policy Framework is, what it authenticates, and the specific problem it was built to solve;
• How the what is SPF authentication process runs from SMTP connection to final result;
• The complete anatomy of an SPF record, including all eight mechanisms, four qualifiers, and two modifiers;
• How Sender Policy Framework interacts with DKIM and DMARC alignment;
• Where SPF breaks, covering forwarding failures, the 10-DNS-lookup limit, and the 255-character ceiling;
• Step-by-step guidance for creating, testing, and maintaining Sender Policy Framework records at enterprise scale.

Email authentication verifies sending infrastructure, yet display-name spoofing and lookalike domains reach employees untouched by any DNS record. Adaptive Security detects and removes those AI-powered cyberattacks before delivery.

Book a demo

What Is SPF? Definition and Overview of Sender Policy Framework

SPF (Sender Policy Framework) is an email authentication protocol that lets domain owners specify exactly which mail servers may send email on their behalf by publishing a list of permitted IP addresses in a DNS TXT record. It closes a foundational weakness in the Simple Mail Transfer Protocol, which was built without any native mechanism to verify that the sender address on an incoming message is genuine. Sender Policy Framework alone cannot stop every form of email-based impersonation, though it functions as one of three pillars of modern email authentication alongside DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance).

SPF reframes the authentication question. Instead of asking whether a message looks legitimate, it asks whether the domain owner actually authorizes the sending server. When an inbound email arrives, the recipient's mail server queries the sender's domain DNS records, extracts the SPF record, and checks whether the connecting IP address appears in the authorized list.

If the IP matches, the message passes. If it does not, the server can flag, quarantine, or reject the message depending on the domain's stated policy. This makes Sender Policy Framework a uniquely practical defense: it requires no cryptographic keys shared between sender and recipient, and the check completes at the server level before the message reaches an inbox.

SPF's simplicity is also its ceiling. It authenticates the envelope sender domain, the return-path visible in email headers, in preference to the "From" address the recipient actually sees. That gap is why Sender Policy Framework must be paired with DKIM and DMARC to build a complete authentication chain.

Adoption data underscores both the protocol's importance and the work that remains. According to AFNIC's SPF, DKIM, DMARC and BIMI on .fr: Still on the Rise in 2025, SPF adoption reached 69% across .fr domains, up from 66.2% the prior year and 52.5% in 2023. Steady growth still leaves roughly three in ten domains publishing no sending policy at all, and those domains remain fully exposed to domain spoofing.

That gap defines SPF's role: it is the first line of defense, the gate that determines whether an email gets evaluated further at all. Without Sender Policy Framework, DKIM and DMARC have nothing to anchor to, and phishing emails ranging from mass credential harvesters to precisely targeted spear-phishing lures pass unchecked.

Domains without a published sending policy hand cyberattackers a free identity, and no downstream authentication layer can compensate for that absence. Adaptive Security hardens the human layer that DNS records never reach.

Take a self-guided tour

What Does SPF Stand For?

SPF stands for Sender Policy Framework. The name reflects the protocol's function: a policy that the domain owner publishes as a framework for receiving mail servers to evaluate. The "sender" refers specifically to the envelope sender domain, the return-path address carried in the SMTP conversation and invisible to the email recipient.

That distinction matters because Sender Policy Framework authenticates the transport layer in preference to the display layer. The "policy framework" language captures the fact that domain owners decide the consequences of an authentication failure themselves.

A hardfail (-all) instructs receivers to reject unauthorized messages, a softfail (~all) advises marking them suspicious while delivering anyway, and a neutral result (?all) makes no assertion either way. The protocol was first formalized as an experimental standard in 2006 under RFC 4408 and later refined in RFC 7208, the authoritative specification still in use today.

In operational practice, SPF is often discussed interchangeably with its DNS record format, the TXT record beginning with v=spf1. The term properly encompasses the entire verification framework: the DNS publication mechanism, the receiving server's query-and-validate process, and the policy enforcement logic that determines what happens to messages that fail the check.

What Problem Was Sender Policy Framework Created to Solve?

Sender Policy Framework was created to solve a single catastrophic design flaw: SMTP's complete absence of sender identity verification. When SMTP was designed, the internet was a small research network of mutually trusted participants, and the protocol assumed that whoever claimed to be sending from a domain was authorized to do so.

There was no authentication handshake, no cryptographic challenge, and no mechanism of any kind to prevent domain forgery. Cyberattackers quickly recognized they could send email appearing to come from any domain: a bank, a government agency, or a corporate executive. Recipients had no technical method to detect the deception.

This flaw enabled the entire phishing economy. Domain spoofing let cyberattackers impersonate trusted brands in credential-harvesting campaigns, send fraudulent invoices that appeared to come from real vendors, and launch business email compromise cyberattacks where the sender address looked identical to the CFO's actual email.

SPF emerged as the first standardized attempt to give domain owners a voice, a way to tell the internet, publicly and verifiably, which servers legitimately send their email. The protocol did not try to retrofit security into SMTP itself, which would have required changing every mail server in the world.

Instead, Sender Policy Framework used the Domain Name System, already universally deployed, as the trust anchor, making adoption incremental and backward-compatible. The approach worked precisely because it demanded nothing from the end user: SPF validation happens silently between mail servers during the SMTP conversation. That design choice made the protocol deployable at internet scale and remains the reason it stays relevant two decades later.

Sender Policy Framework in the Email Authentication Landscape

SPF does not operate in isolation. It is the first layer in a three-layer email authentication architecture that has become mandatory for any organization sending email at scale. In 2024, Google and Yahoo began requiring all bulk senders dispatching more than 5,000 messages per day to implement SPF, DKIM, and DMARC, and Microsoft matched the policy in May 2025 by rejecting non-compliant messages.

The three protocols address different vulnerabilities that, together, close the gaps no single protocol covers. Sender Policy Framework validates the sending server's identity by checking the envelope sender domain against an authorized IP list. DKIM adds a cryptographic signature to each outgoing message, letting the recipient verify that the content was not altered in transit and that it originated from the signing domain.

DMARC ties them together by telling receiving servers what to do when a message fails SPF or DKIM checks. Critically, DMARC aligns the authenticated domain from those checks with the "From" address the recipient sees. With DMARC in place and set to a reject policy, domain spoofing becomes functionally impossible for any domain the cyberattacker does not control.

The triad is now table stakes for inbox placement. Organizations lacking any of the three face deliverability penalties, elevated phishing risk, and compliance exposure under frameworks like PCI DSS 4.0.1, whose Requirement 5.4.1 has mandated anti-phishing mechanisms since March 2025 and names anti-spoofing controls such as SPF, DKIM, and DMARC as recommended examples.

Compliance frameworks now treat email authentication as a baseline control, yet a passing DNS check says nothing about whether an employee will trust a fraudulent request. Adaptive Security closes that judgment gap.

Explore the platform

How SPF Works: The Sender Policy Framework Authentication Process

SPF authentication verifies whether a sending mail server is authorized to deliver email on behalf of a domain. The receiving server extracts the domain from the envelope-from address (the Return-Path or MAIL FROM), performs a DNS TXT query to retrieve the SPF record, and evaluates the connecting IP against the mechanisms listed in that record.

The process yields one of seven possible results, and the receiving server then decides whether to accept, reject, or flag the message. Sender Policy Framework supplies the verdict; enforcement belongs to the receiver. Understanding each stage explains why the protocol succeeds against direct domain forgery and why it fails against the impersonation cyberattacks that matter most to security teams.

1. SMTP Connection Established and the MAIL FROM Command

Every email transmission begins with the Simple Mail Transfer Protocol. When a sending mail server initiates a connection to a receiving server, the two exchange a structured conversation of commands and responses, and the sending server responds to the greeting with a HELO or EHLO declaring its own hostname.

The critical moment for SPF arrives with the MAIL FROM command, which tells the receiving server where to send bounce messages if the email cannot be delivered. The domain portion of this address becomes the identity that Sender Policy Framework authenticates. If an SMTP session delivers MAIL FROM: <bounces@example.com>, the receiving server will later query DNS for SPF records belonging to example.com.

This is the first point of confusion most administrators encounter. The MAIL FROM address is entirely separate from the "From" header recipients see in their inbox, so a cyberattacker can set the visible From header to ceo@yourcompany.com while using a MAIL FROM of spoofer@evil-domain.com. SPF will check evil-domain.com, authenticating the envelope in preference to the letterhead.

2. DNS TXT Query for the Sender Policy Framework Record

Once the receiving server has the envelope-from domain, it performs a DNS TXT query against that domain. SPF records live as specially formatted TXT records in the domain's DNS zone, and the receiving server's resolver requests all TXT records associated with the domain, then scans the responses for any record beginning with v=spf1.

Only one Sender Policy Framework record should exist per domain. If multiple TXT records begin with v=spf1, the specification dictates that the receiving server must return a PermError because the record set is syntactically invalid and cannot be evaluated. This common configuration mistake silently breaks SPF for entire domains.

DNS lookup limits also matter. The specification caps the total number of DNS queries triggered during evaluation at 10, including the initial TXT query, and mechanisms that generate additional lookups (include, a, mx, and ptr) all count toward that ceiling. If no TXT record beginning with v=spf1 exists at all, the receiving server returns None: the domain asserts no sending policy, and no authentication claim can be made either way.

3. Parsing the SPF Record and Evaluating the Sending IP

A valid SPF record is a string of mechanisms and modifiers separated by spaces. The receiving server parses this record left to right, evaluating each mechanism against the connecting IP address, and the first mechanism that produces a definitive match ends the evaluation immediately.

The most common mechanisms include ip4 and ip6, which match specific IP addresses or CIDR ranges; a and mx, which resolve hostnames to IP addresses and compare them to the connecting server; include, which pulls in the Sender Policy Framework record of another domain; and all, which matches everything and must appear at the end. Each mechanism can carry a qualifier: + for Pass (the default), - for Fail, ~ for SoftFail, or ? for Neutral.

Consider a typical record: v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all. The receiving server first checks whether the connecting IP falls within the 192.0.2.0/24 range, and a match returns Pass and stops evaluation. Otherwise the server moves to the include mechanism, pulling in Google's record and evaluating the connecting IP against Google's authorized senders; if that produces no Pass, the server reaches -all, which matches any remaining IP and returns Fail.

4. Interpreting the Sender Policy Framework Result

The evaluation always terminates with one of seven defined results:

• Pass: The connecting IP is authorized by the domain's record, and the sender has proven its identity at the envelope level;
• Fail: The connecting IP is explicitly not authorized, triggered by the -all mechanism, and receiving servers typically reject the message or mark it as spam;
• SoftFail: The connecting IP is not explicitly authorized, though the domain owner has not committed to a hard Fail policy (triggered by ~all), so the message should be accepted only under heightened scrutiny or quarantine;
• Neutral: The domain owner makes no assertion about the connecting IP (triggered by ?all), which is functionally equivalent to having no record and is typically used during testing;
• None: No record exists for the domain, so no authentication claim can be made;
• TempError: A transient error occurred during evaluation, typically a DNS timeout, and the receiving server should retry later without automatically rejecting the message;
• PermError: The record is syntactically invalid, multiple records conflict, or the DNS lookup limit was exceeded, and messages may be rejected or accepted depending on the receiver's policy.

SPF by itself does not dictate what the receiver does with any result; it provides the authentication verdict, and DMARC layers policy on top. DMARC also requires alignment between the envelope-from domain checked by Sender Policy Framework and the visible From header domain that recipients see.

Envelope-From vs. Visible From Header: Why the SPF Difference Matters

The distinction between the envelope-from address and the visible From header is the single most misunderstood aspect of Sender Policy Framework, and the reason the protocol alone cannot prevent phishing. The envelope-from address exists exclusively for SMTP delivery: it is where bounce messages go, transmitted during the SMTP conversation in the MAIL FROM command, and it may never be seen by the recipient.

The From header appears in the message body and is what email clients display. A cyberattacker sending a spear phishing email can set the envelope-from to a domain they control, one with a valid SPF record that will Pass, while setting the visible From header to the CEO's actual company domain. SPF authenticates the envelope domain and passes, and the recipient sees the spoofed From address and trusts it.

This is why Sender Policy Framework must be combined with DMARC to be effective against domain spoofing. DMARC introduces alignment: for SPF to contribute to a DMARC Pass, the domain it authenticated must match the domain in the visible From header, either exactly or at the organizational level depending on the alignment mode. Without DMARC enforcement, a passing check on an unrelated envelope domain provides zero protection for the domain the recipient actually sees.

HELO/EHLO Identity Checks and Null Sender Paths in SPF

Not every email has an envelope-from address. Bounce messages, delivery status notifications, and certain automated system messages use a null sender path, sending the MAIL FROM command as MAIL FROM:<>. Since there is no domain to query in an empty address, Sender Policy Framework falls back to authenticating the HELO/EHLO identity instead.

The receiving server extracts the domain from the hostname declared in the sending server's greeting and performs the DNS TXT query against that domain. The rest of the evaluation proceeds identically: the SPF record associated with the HELO identity is parsed, and the connecting IP is compared against its authorized senders. Many organizations still fail to publish records for their mail server hostnames, leaving bounce-message authentication entirely absent.

This HELO fallback also applies when the MAIL FROM domain has no SPF record. Rather than returning None, the receiving server may, depending on implementation, check the HELO identity's record instead. The practical takeaway for administrators is direct: every hostname that sends email needs its own record, covering more than the domain appearing in user-facing From addresses.

When organizations deploy phishing simulations that test whether employees detect spoofed sender identities, the effectiveness of those exercises depends on whether the organization's own configuration authenticates both regular mail flows and the HELO identities used by bounce handlers. That same authentication gap is what DKIM was designed to close, by adding a cryptographic signature that survives forwarding independent of which IP address delivered the message.

Bounce handlers and automated notification systems send mail from hostnames most security teams never inventory, leaving whole categories of traffic unauthenticated. Adaptive Security tests those blind spots with realistic phishing simulations.

Take a self-guided tour

SPF Record Anatomy: Syntax, Mechanisms, and Qualifiers

Every SPF record begins with the version identifier v=spf1 followed by one or more mechanisms and modifiers, each evaluated left to right by the receiving mail server. The record is always published as a DNS TXT record, and the dedicated SPF record type (type 99) was formally deprecated in RFC 7208 and should never be used.

A properly constructed Sender Policy Framework record states exactly which servers are authorized to send email on a domain's behalf, and what receivers should do with messages from servers absent from that list. The syntax is compact, though each element carries operational consequences that surface only when a record is evaluated at scale.

All 8 SPF Mechanisms Explained

SPF provides eight mechanisms that define which hosts may send mail for a domain. Each is evaluated against the connecting IP address, and the first match terminates processing:

• all: Matches every IP address, always, and belongs at the very end of the record as a catch-all for any sender not matched by a preceding mechanism. Without all, the result defaults to Neutral, which provides no meaningful protection; -all means reject everything not explicitly authorized;
• a: Matches if the connecting IP appears in the A or AAAA DNS records of the domain. Used without an argument it checks the domain publishing the record, and with an argument (a:mail.example.com) it checks the specified domain, which suits organizations whose mail servers share hostnames with web servers;
• mx: Matches if the connecting IP is listed in any MX record of the domain and can accept an argument (mx:example.com). This helps when inbound mail servers also handle outbound delivery, though it authorizes every IP in every MX record at every priority level, which can inadvertently expand the authorized sender pool;
• ip4: Matches an exact IPv4 address or CIDR block and is the most precise and performant mechanism because it requires no DNS lookups. For environments where outbound mail originates from known static ranges, ip4:192.0.2.0/24 should serve as the primary authorization method;
• ip6: Identical to ip4 but for IPv6 addresses, such as ip6:2001:db8::/32. Infrastructure with IPv6-capable mail servers needs explicit ip6 mechanisms, since omitting them means IPv6 senders fall through to the catch-all;
• include: Delegates authorization to another domain's record by evaluating that record as if it were part of the original. A Pass from the included domain makes the mechanism match, which is how include:_spf.google.com authorizes Google Workspace, and each include counts against the DNS lookup limit;
• exists: Performs a conditional DNS A lookup that matches if the specified domain resolves to any IP address. This rarely appears in practice, though it enables dynamic authorization where an external system controls whether a particular sender should pass, as in exists:%{i}._spf.example.com;
• ptr: Matches if reverse DNS on the connecting IP resolves to a hostname within the domain and forward DNS on that hostname resolves back to the original IP. RFC 7208 explicitly recommends against ptr due to heavy DNS overhead and reliance on reverse DNS infrastructure outside the domain owner's control, so replace it with ip4, ip6, or include.

SPF Qualifiers: +, ?, ~, and -

Every mechanism can carry one of four qualifiers that tell the receiving server how to interpret a match. When no qualifier is written, + (Pass) applies by default, which is why ip4:203.0.113.5 and +ip4:203.0.113.5 are equivalent.

The four qualifiers map directly to the enforcement posture a domain owner is willing to declare:

• + (Pass): The connecting host is authorized and the message passes SPF, the default when no qualifier is specified;
• ? (Neutral): The domain asserts no position on whether the host is authorized, and receivers treat the result identically to having no record at all, so it suits only transitional testing of a specific sending source;
• ~ (SoftFail): The host is probably not authorized, though the domain declines a definitive assertion, so the receiving server may accept the message while marking it or routing it to spam. SoftFail is common during rollout when an organization still wants visibility into unauthorized senders without rejecting legitimate mail;
• - (Fail): The host is explicitly not authorized and the receiving server should reject the message. This is the strongest protection and the only qualifier signaling a definitive policy, appropriate at the end of a record once every legitimate sending source is accounted for.

SPF Modifiers: exp= and redirect=

Modifiers are name-value pairs that appear at the end of the record, after all mechanisms. Unlike mechanisms, they do not influence whether a message passes or fails; they control auxiliary behavior instead, and both defined modifiers serve narrow operational purposes that most domains never require.

exp= (explanation) specifies a domain from which the receiving server can fetch an explanatory string when Sender Policy Framework evaluation results in a Fail. If a message is rejected, the recipient's mail server performs a DNS TXT query on the exp= domain and may include the returned text in the SMTP bounce message, which helps when providing a support contact or a page explaining why the message was blocked.

redirect= replaces the current evaluation with the SPF record of another domain. Unlike include, which evaluates the included record and returns to the current one, redirect terminates evaluation entirely and uses the target domain's record for the final result. It fits cases where one domain's email policy is entirely delegated to another, such as a subsidiary redirecting to the parent company's record, and only one redirect= may appear as the last token.

The Sender Policy Framework Macro Language (Advanced)

For organizations with complex or highly dynamic sending infrastructure, SPF supports a macro language that allows mechanisms and modifiers to reference runtime variables. Macros use percent-encoded placeholders that the receiving server expands during evaluation, including %{i} (the connecting IP address), %{d} (the domain being evaluated), and %{s} (the sender's email address).

The macro language also supports transformations such as reversing octets, URL-encoding, or converting to lowercase, along with optional delimiters. In practice, macro usage stays niche because static mechanisms cover nearly all legitimate sending configurations, and macros introduce their own complexity, including additional DNS lookups that count toward the 10-lookup limit.

Debugging macro-based failures is significantly harder than tracing a straightforward ip4 or include, so implement macros only against a specific operational requirement that static mechanisms demonstrably cannot satisfy. An annotated example shows what a clean record looks like: v=spf1 ip4:192.0.2.0/24 ip6:2001:db8:500::/48 include:_spf.google.com mx -all.

This record authorizes any server in the 192.0.2.0/24 IPv4 range, any server in the 2001:db8:500::/48 IPv6 range, everything authorized by Google Workspace's record via include, and every IP listed in the domain's MX records. The final -all instructs receivers to reject anything else. It is compact, uses no deprecated mechanisms, stays well under the 10-lookup limit, and states a definitive Fail policy.

Every mechanism on paper is only as strong as its translation into a live DNS record, and that translation is where most domains discover the distance between their intended policy and their actual authorized sender footprint.

A record that looks correct in a text editor can still authorize servers no one on the security team can name. Adaptive Security turns each real cyberattack that slips through into targeted cybersecurity awareness training.

Explore the platform

How SPF, DKIM, and DMARC Work Together

SPF, DKIM, and DMARC form a three-layer email authentication stack in which each protocol answers a question the others cannot. Sender Policy Framework verifies which servers may send mail for a domain, DKIM cryptographically proves message integrity, and DMARC ties both to the visible From header while enforcing a policy when authentication fails.

SPF checks the envelope Return-Path against an authorized IP list and never inspects the From header. DKIM signs the message body and selected headers so receivers confirm nothing was altered in transit, and it survives forwarding where Sender Policy Framework routinely breaks. DKIM provides no mechanism for telling receivers what to do when a signature fails, which is precisely the enforcement gap DMARC fills.

Together these three protocols address sender authorization, content integrity, and domain alignment. Since February 2024, Google and Yahoo have required all three for bulk senders, making the stack a practical requirement in preference to an optional configuration.

Why All Three Are Necessary Alongside Sender Policy Framework

SPF alone validates only the envelope sender, the Return-Path address that handles bounces, and never inspects the From header displayed to recipients. A cyberattacker can configure Sender Policy Framework for their own malicious domain, pass the check, and still display a target organization's domain in the From field. The recipient sees a legitimate sender while the authentication result says nothing about the domain that matters.

DKIM closes a different gap by attaching a cryptographic signature that survives forwarding, something SPF cannot do because forwarded mail originates from the forwarder's IP in preference to the original sender's authorized list. When a DKIM signature validates, the receiving server knows the message content is intact and the signing domain has taken responsibility for it. DKIM alone offers no instruction on what to do with unsigned messages, and a missing or broken signature produces no action unless a policy layer demands one.

DMARC supplies that policy layer. It takes the independent results of Sender Policy Framework and DKIM and asks a single question: does the authenticated domain match the domain in the From header? A yes for either protocol means DMARC passes; a no for both means DMARC applies the domain owner's policy of none, quarantine, or reject, and generates aggregate reports so administrators can monitor authentication performance across every sending source.

According to Valimail's 2026 State of DMARC Report, DMARC awareness has reached 78% while actual enforcement has plateaued at 42%, a 36-point gap representing organizations that implemented the protocol to satisfy mailbox provider requirements yet remain unprotected against domain spoofing. Deployment without enforcement leaves the brand exposed, and the same logic applies one layer down: an SPF record without a definitive policy is a record in name only.

How SPF Authentication Ties to the From Header

DMARC alignment is the mechanism that prevents cyberattackers from authenticating with one domain while impersonating another. For DMARC to pass, the domain in the visible From header must align with either the SPF-authenticated domain or the DKIM-signed domain, and at least one of the two must produce a Pass. Alignment is the bridge connecting raw authentication results to the identity recipients actually see.

Sender Policy Framework alignment compares the domain in the Return-Path header against the domain in the From header, and DMARC supports two modes. Strict alignment requires an exact domain match, so a Return-Path of mail.example.com against a From header of example.com fails. Relaxed alignment accepts any subdomain within the same organizational domain, and it is the default for both SPF and DKIM, which is what keeps legitimate mail passing for organizations running separate subdomains for marketing, support, and transactional mail.

This is also where the question of whether SPF can pass while DMARC fails finds its answer: yes, and the reason is always alignment. Consider a third-party email marketing platform sending on an organization's behalf. The platform's servers are authorized in the Sender Policy Framework record, so the check returns a Pass, though the Return-Path domain belongs to the marketing platform.

If the From header displays the organization's domain while the Return-Path shows the vendor's, alignment fails under both strict and relaxed modes. SPF technically passed, though the authenticated domain has no relationship to the From domain recipients see. According to DMARC Report's The State of DMARC Adoption in 2026, roughly 938,000 domains publish a DMARC record while only 9% are actually protected, which shows how many organizations navigate these alignment challenges without ever reaching full enforcement.

What Happens When SPF and DKIM Produce Conflicting Results

DMARC's design is deliberately permissive: only one of Sender Policy Framework or DKIM needs to pass with alignment. A message where SPF passes with alignment but DKIM fails, or the reverse, still passes DMARC. This redundancy is intentional because each protocol fails under different operational conditions.

SPF breaks when email is forwarded, because the forwarding server's IP is not listed in the original sender's record, so the check returns a hard fail. DKIM survives forwarding because the cryptographic signature is embedded in the message headers and remains valid as long as the body and signed headers are unmodified. In this scenario DKIM passes with alignment and DMARC passes overall, with the signature serving as the safety net that prevents legitimate forwarded mail from being quarantined.

The inverse occurs when an intermediary modifies the message body or a signed header after DKIM signing. Some mailing list software appends unsubscribe footers or modifies subject lines, breaking the signature, while Sender Policy Framework evaluates only the sending IP against the DNS record and remains unaffected by content changes. If SPF passes with alignment, DMARC still passes even though DKIM validation failed, and each protocol covers the other's blind spot.

The risk surfaces when neither protocol can save the other. A forwarded message where SPF fails and a mailing list also breaks DKIM produces two failures, alignment becomes irrelevant, and DMARC applies the domain owner's policy. If that policy is p=reject, the message is silently discarded, which is why organizations relying on mailing lists, forwarding services, or complex third-party sending ecosystems must audit their entire authentication surface before moving to strict enforcement.

The combination of Sender Policy Framework, DKIM, and DMARC only protects the domain when at least one leg of the stack survives the delivery path intact. Phishing simulations that test against these forwarding paths and third-party sender configurations reveal exactly where those gaps exist before cyberattackers find them first.

Authentication stacks fail quietly, and a domain at p=reject with a broken record offers a fraction of the protection its owner assumes. Adaptive Security surfaces the cyberattacks that survive every layer.

Book a demo

SPF Limitations, Forwarding Failures, and the DNS Lookup Limit

SPF cannot authenticate email that passes through an intermediary. When a message is forwarded, the receiving mail server sees the forwarder's IP address in preference to the original sender's, and Sender Policy Framework checks that IP against a domain record that does not list it, producing an authentication failure.

The protocol also imposes hard structural ceilings: a 10 DNS lookup limit and a 255-character TXT string maximum. Both turn routine multi-provider email configurations into silent delivery failures. According to DMARC Report's Does Forwarding Mailers Affect DMARC Alignment observational study (2026), which analyzed 1.1 billion messages across a 118-domain panel, 73% of forwarding-induced DMARC failures originated from SPF-only breakage where DKIM was absent or unaligned.

The SPF Forwarding Problem and Why It Breaks Authentication

Sender Policy Framework authenticates by checking the IP address of the server that delivered the message against the list of authorized senders published in the sending domain's DNS record. This model works cleanly when a message travels directly from sender to recipient, and it breaks the moment an intermediate server enters the path.

When a recipient forwards email from a work address to a personal account, the forwarding server becomes the new delivering host. The final receiving server sees that forwarder's IP and queries the SPF record of the original sender's domain, and because the forwarder's IP is not listed there, the check returns a fail. Authentication that passed at the first hop evaporates at the second.

This is not an edge case. University alumni forwarding, corporate email redirection, and mailing list distribution all introduce intermediary hops that invalidate Sender Policy Framework. The problem is structural: the protocol authenticates the transmission path in preference to the message, so any change to that path destroys the result.

Practitioners have four alternatives to plain message forwarding:

• Remailing rewrites the envelope-from address so the forwarder becomes the new sender, and SPF checks then reference the forwarder's own record;
• Refusing to forward sidesteps the problem entirely, though it is rarely acceptable for legitimate use cases;
• Allowlisting forwarders' IP addresses in the original domain's record works for known, trusted intermediaries, though it creates a maintenance burden and weakens the security model by authorizing servers the domain owner does not control;
• The Sender Rewriting Scheme offers the most effective fix and is detailed below.

Sender Rewriting Scheme (SRS) and ARC: Solutions to SPF Forwarding Failures

SRS solves the forwarding problem at the envelope level. When a forwarder implements SRS, it rewrites the envelope MAIL FROM address to use its own domain before relaying the message onward, so the final receiving server performs SPF verification against the forwarder's domain, which naturally authorizes the forwarder's own IPs.

Sender Policy Framework passes, and bounces also route back to the forwarder correctly, preventing backscatter to the original sender. SRS fixes SPF while leaving DKIM and DMARC alignment unresolved wherever forwarding intermediaries also modify message content, such as mailing lists that add subject prefixes or footers. That is where the Authenticated Received Chain (ARC) standard enters.

ARC preserves authentication results across forwarding hops by adding three cryptographic headers:

• ARC-Authentication-Results: The intermediary's view of SPF, DKIM, and DMARC status at that hop;
• ARC-Message-Signature: A DKIM-like signature covering the message and those results;
• ARC-Seal: A signature protecting the integrity of the chain itself.

When the final recipient's mail server receives a message with a valid ARC chain from a trusted intermediary, it can treat the upstream authentication results as authoritative even if local SPF and DKIM checks fail. Gmail and Outlook.com both support ARC, and domains that deployed it at major forwarders reduced DMARC fail rates on forwarded mail by a median of 52% across Gmail and 31% across Outlook.com delivery paths, according to the same observational study. SRS and ARC are complementary: SRS fixes the envelope, and ARC preserves trust across the chain.

The 10 DNS Lookup Limit in Sender Policy Framework: What Counts and What Happens When Exceeded

RFC 7208, section 4.6.4 mandates that SPF evaluation must not require more than 10 DNS queries. This limit exists to prevent DNS amplification cyberattacks, since without it a cyberattacker could publish a record with hundreds of nested include: entries and force receiving servers to perform thousands of queries.

The limit applies recursively. A record that includes _spf.google.com where Google's record nests three additional sub-includes consumes four slots of the total 10. Each include:, a, mx, ptr, redirect=, and exists: mechanism triggers a DNS query that consumes one slot, and mx is particularly deceptive because a domain with three MX servers triggers one MX lookup plus three A lookups, consuming four slots from a single term.

What does not count: ip4:, ip6:, and the initial TXT record query for the Sender Policy Framework record itself are free, and the all mechanism requires no query.

Exceeding the limit produces a PermError, which is more consequential than a simple fail. It means the record is structurally invalid, and receivers treat the result as equivalent to neutral, meaning authentication was not performed at all. According to Ashiq et al.'s SPF Beyond the Standard: Management and Operational Challenges in Practice and Practical Recommendations, presented at the 33rd USENIX Security Symposium (2024), which analyzed 176 million domains across four top-level domains, 6.5% of records incur excessive DNS lookups that breach the RFC-defined ceiling.

The failure is silent on the sender's side. The message leaves normally while the receiving server discards it or routes it to spam without any bounce notification reaching the sender, and DMARC fails in cascade because SPF alignment cannot be verified. Organizations routinely cross this threshold without realizing it, since Google Workspace alone consumes four lookups and adding a bulk email service, a marketing platform, and a dedicated MX server pushes a domain past nine before any additional services are configured.

Excessive DNS lookups also introduce measurable latency. Each lookup adds tens to hundreds of milliseconds to email delivery, compounded across every message that triggers evaluation. Receiving servers cache DNS responses, though the first evaluation for a new sending domain always incurs the full lookup cost, and high-volume mail flows amplify this overhead into observable delivery delays.

The 255-Character Limit and SPF Flattening

DNS TXT records are constrained to 255 characters per string. SPF records exceeding this length must be split across multiple TXT strings, which introduces complexity and increases the risk of misconfiguration, and a domain using several cloud email services can easily produce a record running to 400 or 500 characters before any optimization.

Sender Policy Framework flattening addresses both the lookup limit and the character limit simultaneously. The technique resolves every include:, a:, mx:, and redirect= mechanism into its constituent IP addresses and publishes the result as a single record composed entirely of ip4: and ip6: entries. Since neither mechanism counts toward the lookup limit and both are compact per entry, a flattened record eliminates DNS query overhead and reduces character footprint in one operation.

Flattening carries a maintenance cost that practitioners must not underestimate. Provider IP addresses change, sometimes without notice, and a flattened record that is not refreshed regularly will silently fall out of date, authorizing IPs that no longer belong to the service and failing to authorize new ones. Monthly re-flattening is the minimum safe cadence.

For organizations with more than five email providers, a structural solution is more sustainable than flattening alone: dedicating subdomains to individual services, each with its own independent SPF record and lookup budget. The same subdomain strategy becomes the foundation for DKIM alignment, where each service signs with its own selector and domain, keeping authentication independently verifiable across every hop.

Records break silently, and the first signal is usually a customer asking why an invoice never arrived. Adaptive Security keeps the human layer sharp while DNS configurations drift out of date.

Take a self-guided tour

Why SPF Matters for Email Security and Deliverability

SPF establishes the minimum identity check that every major mailbox provider now requires before accepting email. Without it, legitimate messages land in spam or get rejected outright. Google and Yahoo began requiring Sender Policy Framework or DKIM authentication for all senders in February 2024, and Microsoft followed with its own enforcement in May 2025.

The shift made SPF the entry ticket to the inbox in preference to an optional best practice. Google reported that Gmail users received 265 billion fewer unauthenticated messages in 2024 compared to the year prior, a 65% reduction driven directly by authentication enforcement. A domain without Sender Policy Framework is now a deliverability failure waiting to happen alongside being a security gap.

SPF and Email Deliverability: What Mailbox Providers Require

The move from filtering first to rejecting first now defines how major providers handle unauthenticated email. Google's sender guidelines require SPF or DKIM for all senders delivering to personal Gmail accounts, and Sender Policy Framework, DKIM, and DMARC together for anyone sending more than 5,000 messages per day.

Microsoft enacted parallel requirements for its consumer domains in May 2025, and Yahoo rolled out the same threshold for bulk senders in February 2024. The consequence for domains without SPF is immediate: email either routes to the spam folder or triggers a hard bounce with a 5.7.26 error, vanishing before the recipient ever sees it.

Yahoo's product leadership framed the joint mandate as a shared obligation across the email ecosystem, arguing that every user deserves a secure experience regardless of provider and that achieving it requires the industry to move together. That framing has since translated into enforcement. Organizations sending transactional emails, invoices, password resets, and customer communications without Sender Policy Framework are already experiencing silent delivery failures, and a domain without a record effectively tells receiving servers it cannot prove its own identity.

Sender Policy Framework as an Anti-Spoofing and Brand Protection Defense

SPF shrinks the cyberattack surface by publishing a record listing every mail server authorized to send from a domain. A hard fail (-all) policy instructs receiving servers to reject any message originating from an unauthorized source, which protects a brand from being exploited as the apparent sender of malicious email.

The domain(s) Sender Policy Framework protects are prime targets in phishing and business email compromise (BEC) campaigns, where cyberattackers exploit domain trust to convince recipients to act. According to the FBI's 2025 Internet Crime Report, BEC accounted for $3.046 billion in losses across 24,768 incidents, averaging roughly $123,000 per case, and those cyberattacks land inside real financial workflows where a spoofed sender carries decisive weight.

SPF has a critical limitation here: display-name spoofing. A cyberattacker who forges a familiar executive name in the display field while using a different envelope-from domain bypasses the protocol entirely, because the envelope-from passes authentication even though the recipient sees a trusted name. Cyberattackers also register lookalike domains with valid records of their own, so Sender Policy Framework reduces the pool of directly spoofable domains while remaining one layer of defense.

How SPF Interacts with Email Security Gateways and Blocklists

Email security gateways and cloud email security platforms treat SPF as a core signal in the filtering pipeline. When a message arrives, the gateway runs a check against the envelope-from domain and factors the result into its spam-scoring algorithm. A missing or misconfigured record can tip a legitimate message into quarantine, especially when combined with other weak signals like a recently registered domain or a low-volume sending pattern.

The relationship between Sender Policy Framework and blocklists is similarly consequential. Blocklist operators monitor traffic patterns and flag domains appearing in high volumes of spam or spoofed email, and a domain with a valid, well-maintained record is less likely to be blocklisted because receiving servers can distinguish authorized mail from forgeries, reducing the volume of abuse reports tied to the domain.

Once a domain lands on a major blocklist, email delivery to entire providers can stop overnight. Without SPF in place, proving legitimacy to blocklist operators becomes significantly harder, and the remediation timeline stretches from hours into weeks.

Delivery failures rarely announce themselves. Revenue-critical mail can disappear for weeks before anyone traces it back to a DNS record. Adaptive Security protects the inbox where those cyberattacks land.

Explore the platform

SPF Enforcement Policies: -all, ~all, ?all, and +all

The all mechanism in an SPF record carries a qualifier dictating how receiving mail servers treat unauthorized senders, and choosing the wrong one either exposes a domain to spoofing or breaks legitimate email delivery. The critical distinction sits between -all (hard fail), which instructs servers to reject mail from any IP not explicitly listed, and ~all (soft fail), which allows delivery while flagging the message as suspicious.

A hard fail policy provides the strongest spoofing protection though it can disrupt forwarded email from mailing lists, alumni forwards, or third-party services. Soft fail preserves deliverability at the cost of weaker enforcement against cyberattackers actively scanning for permissive configurations. Microsoft Threat Intelligence warned in January 2026 that weak or permissive Sender Policy Framework policies, including soft fail, are a primary enabler of domain spoofing campaigns powered by phishing-as-a-service platforms.

Hard Fail (-all) vs. Soft Fail (~all): Choosing the Right SPF Policy

The -all qualifier represents the strongest posture an SPF record can take. Any IP not explicitly authorized in the record gets rejected outright, which closes the door on direct-domain spoofing because a cyberattacker sending from an unlisted server never reaches the inbox.

The tradeoff carries operational weight. Forwarded email often breaks under hard failure because the forwarding server's IP is absent from the original domain's record, causing the receiving mail server to reject legitimate mail. This is why ~all remains common during initial deployment, when an organization is still discovering all legitimate sending sources, since soft fail tells receiving servers to accept the message while marking it suspicious.

The downside is that many receiving mail servers do not treat soft failures with urgency, and cyberattackers know it. Microsoft's January 2026 advisory identified soft fail Sender Policy Framework policies as one of the key configuration weaknesses allowing threat actors to successfully spoof organizational domains, and Microsoft's Threat Intelligence team confirmed that strict DMARC rejection paired with hard fail prevents these cyberattacks. For organizations confident in their record after thorough testing, graduating to -all eliminates the ambiguity cyberattackers exploit.

Neutral (?all) and Pass-All (+all): When and Why to Avoid Them

The ?all qualifier takes no position at all. It is a neutral statement making no assertion about unauthorized senders, and from the receiving server's perspective it is functionally identical to having no SPF policy, offering zero protection against spoofing. Its only legitimate use is during the earliest hours of deployment when an administrator wants to monitor mail flow without any enforcement, so treat it as a temporary placeholder.

The +all qualifier is worse than neutral. It actively authorizes every IP address on the internet to send mail on behalf of the domain, effectively disabling Sender Policy Framework entirely and signaling to receiving servers that the domain owner does not care who spoofs their identity.

There is almost no legitimate use case for +all in a production environment, and any domain found using it should be treated as misconfigured. Both ?all and +all leave organizations defenseless against the exact cyberattack vector a properly configured phishing simulation program is designed to test and harden against.

How SPF Enforcement Interacts with DMARC Policy

SPF enforcement does not operate in isolation. When a domain publishes a DMARC record with an enforcement policy of p=quarantine or p=reject, that policy overrides the qualifier's soft-fail treatment. A message returning spf=softfail under ~all will still be quarantined or rejected if the DMARC policy demands it, provided alignment is in place, which means organizations running DMARC at p=reject can technically use ~all without weakening enforcement.

Relying on DMARC to compensate for a weak Sender Policy Framework policy is poor architectural hygiene. The two standards serve different functions: SPF authorizes sending IPs, and DMARC tells receivers what to do when authentication checks fail. Very few organizations actually enforce DMARC at that level, and with enforcement plateaued across the domain population, SPF policy remains the front line of defense for the vast majority.

Microsoft's 2026 guidance is unambiguous: pairing -all with a DMARC reject policy provides the strongest available defense against domain spoofing. When both layers are aligned and enforced, a cyberattacker cannot slip through the distance between suspicious and blocked.

Permissive policies are published in public DNS, which means cyberattackers can identify soft targets faster than most teams can audit their own records. Adaptive Security prepares employees for the campaigns that follow.

Book a demo

How to Set Up, Test, and Validate an SPF Record

Setting up an SPF record requires three deliberate actions: inventorying every service that sends email on a domain's behalf, constructing a single TXT record with the correct mechanisms, and publishing it at the domain's DNS root. The record must start with v=spf1 and list each authorized sender through ip4, ip6, or include mechanisms, closed by an ~all or -all qualifier.

Once published, testing confirms the record is syntactically valid and that receiving servers can locate it. Too many organizations skip that step, leaving misconfigured Sender Policy Framework records silently failing for months while legitimate mail quietly disappears.

Step-by-Step: Creating and Publishing a First Sender Policy Framework Record

The first task is a complete audit of every service sending email using the domain. This includes the primary email platform (Google Workspace, Microsoft 365), marketing automation tools, CRM systems, support platforms, transactional email services, and any on-premise mail servers. Missing even one sender means legitimate emails from that source will fail SPF checks and risk landing in spam folders.

Once the full list exists, obtain each provider's inclusion mechanism. Most major platforms publish a dedicated domain referenced with the include: directive, so Google Workspace uses include:spf.google.com and Microsoft 365 uses include:spf.protection.outlook.com. Construct the record as a single string: v=spf1 followed by each mechanism in order of most to least frequently used, ending with ~all to soft-fail unauthorized senders.

A typical mid-sized organization's record might read: v=spf1 include:spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.salesforce.com ~all. Hard-fail (-all) is more aggressive and will cause unauthorized messages to be rejected outright, which suits domains that never send email while warranting caution on active sending domains.

The record is published as a DNS TXT record at the domain root, meaning the host field is either @ or left blank depending on the DNS provider's interface. Navigate to the domain registrar or DNS host, locate the DNS management section, and create a new TXT record with the type set to TXT, the host set to the root domain, and the value set to the full SPF string.

Some providers require the value to be wrapped in quotation marks. Set the TTL between 300 and 3600 seconds, since a lower TTL during initial deployment allows faster propagation and easier correction if an error surfaces. After publishing, DNS propagation can take up to 48 hours, though most changes resolve within minutes.

A critical rule governs the whole exercise: only one Sender Policy Framework record may exist per domain. RFC 7208 from the Internet Engineering Task Force explicitly states that multiple records are not permitted for a single domain, and publishing a second triggers a PermError that causes all checks to fail. Adding a new sender means editing the existing record.

One further limitation applies. Implementing SPF requires owning the domain, since free email services manage records for their own domains and individual users sending from those addresses cannot publish their own. Sender Policy Framework is a domain-level control, so an organization without DNS control for a domain cannot authenticate mail from it.

How to Test and Validate an SPF Record

Testing catches syntax errors, missing senders, and the multiple-record problem before they affect deliverability. Start with command-line tools: dig TXT yourdomain.com on Linux or macOS, or nslookup -type=TXT yourdomain.com on Windows. The response should contain exactly one SPF record string, and seeing multiple records or none at all signals a configuration needing immediate correction.

For deeper validation, use online checkers. MXToolbox's SPF Record Lookup parses the record, flags syntax problems, counts DNS lookups, and warns when a record approaches the 10-lookup limit. DMARCIAN's SPF Surveyor provides a visual breakdown of every mechanism and its resolution path, which helps considerably when debugging complex records with multiple include: directives.

The definitive test is sending a real email. Gmail allows inspection of authentication results in the message headers: open a delivered email, select "Show original," and look for spf=pass in the Authentication-Results header. A pass confirms the receiving server successfully validated the Sender Policy Framework record, a softfail or neutral means the record exists but either does not cover the sending IP or has a configuration issue, and a permerror almost certainly indicates multiple records or a syntax problem.

SPF for Dynamic IP Addresses and Cloud Email Providers

Cloud email providers use large, frequently changing pools of IP addresses, making it impractical to list individual IPs in an SPF record. These providers solve this by publishing their own record referenced with the include: mechanism, so when a receiving server encounters include:_spf.google.com, it performs a separate DNS lookup to resolve Google's current authorized ranges, keeping the record accurate even as Google rotates infrastructure.

This approach applies to virtually every modern email service. Microsoft 365 (include:spf.protection.outlook.com), Amazon SES (include:amazonses.com), and Mailchimp (include:servers.mcsv.net) all publish records their customers reference. The tradeoff is that each include: consumes one of the 10 available DNS lookups, so organizations sending through many cloud services should audit the list regularly, remove providers no longer in use, and consolidate where possible.

Sender Policy Framework authenticates only the sending server. DKIM adds a cryptographic signature verifying message integrity from send to delivery, and DMARC ties both protocols together with a policy telling receiving servers how to handle messages that fail authentication.

Every new vendor added outside change control is a lookup closer to a PermError that fails every message at once. Adaptive Security keeps employee readiness intact while infrastructure catches up.

Take a self-guided tour

Common SPF Misconceptions and Syntax Errors

SPF looks deceptively simple, a single DNS TXT record listing authorized senders, though the distance between published and correct is where most organizations stumble. Outright syntax errors affect only 0.4% of records worldwide, while evaluation-phase challenges reach 7.7% of domains, according to the same Ashiq et al. USENIX Security 2024 analysis of 176 million domains.

These errors do more than waste effort. They create a false sense of security while leaving domains exposed to exactly the spoofing Sender Policy Framework was designed to prevent, and the most damaging misconceptions concern what the protocol protects at all.

Common Sender Policy Framework Syntax Errors and How to Fix Them

The most catastrophic SPF mistake is publishing multiple records on the same domain. RFC 7208 is unambiguous: a domain must have exactly one TXT record beginning with v=spf1.

When a receiving mail server encounters two or more, it cannot determine which to evaluate and returns a PermError, permanently failing authentication for every message from that domain. The fix is direct: consolidate all sending services into a single merged record.

Beyond the multiple-record problem, administrators routinely trip over small syntax errors that break the entire record:

• Trailing dots where colons belong: Writing include:spf.protection.outlook.com. turns a valid include mechanism into an unresolvable hostname;
• Equal signs substituted for colons: A construction like include=example.com leaves the receiving server unable to parse the mechanism;
• Spaces inserted inside mechanisms: Something like ip4: 192.0.2.0/24 breaks the record boundary and causes the entire policy to fail;
• A misplaced version prefix: The v=spf1 string must be the very first token in the record, and omitting it or placing anything before it means the record is not recognized as SPF at all.

Misconceptions About What SPF Actually Protects

The most dangerous misunderstanding about SPF is that it prevents all email spoofing. It authenticates only the envelope-from address, the Return-Path domain hidden in the message headers, leaving the From header recipients actually see untouched.

A cyberattacker can set a clean envelope-from on a domain they control, pass Sender Policy Framework cleanly, and still display a trusted executive address in the visible From field. Cousin-domain cyberattacks exploit the same gap: a cyberattacker registers a plausible variant domain, publishes valid SPF and DKIM for it, and sends phishing emails that look legitimate to both recipients and authentication checks. DMARC closes this gap by requiring alignment between the authenticated domain and the From header domain.

Another persistent myth holds that SPF protects an organization against inbound phishing cyberattacks. It is an outbound defense, telling the rest of the internet which servers are authorized to send mail on behalf of a domain and preventing cyberattackers from spoofing that domain against external targets. It does nothing to filter what arrives in employee inboxes.

Inbound phishing defense requires a different set of tools: email security gateways, advanced threat protection, and cybersecurity awareness training that builds recognition skills across the full cyberattack surface, including multi-channel phishing simulations reaching far beyond what any Sender Policy Framework record addresses.

The Unnecessary Include Problem and How to Clean Up an SPF Record

Over time, SPF records accumulate technical debt. Every third-party service added gets an include mechanism, and when those services are retired or contracts expire, the includes often remain. Each orphaned include adds at least one DNS lookup to every evaluation, and exceeding the RFC 7208 ceiling produces a PermError that fails every message, including those from legitimate senders who would have matched earlier mechanisms.

Auditing a record means answering one question for every include: does this service still send mail on behalf of this domain? A no means removing the mechanism, and uncertainty means checking DMARC aggregate reports to see which sending sources actually generate traffic.

A lean Sender Policy Framework record stays safely under the 10-lookup ceiling while reducing the cyberattack surface. Every include represents a third party whose own security posture becomes the domain owner's if that party is compromised.

Orphaned includes have every third party's security posture without anyone approving the trade. Adaptive Security detects the cyberattacks that reach employees through vendors and platforms already trusted.

Explore the platform

SPF History, Deprecated Features, and Sender ID

Sender Policy Framework was born from a fundamental weakness in SMTP: any computer could send email claiming to be from any domain, with no built-in mechanism to verify that claim. By the early 2000s, spammers and phishers exploited sender spoofing at massive scale, making it nearly impossible for recipients to distinguish legitimate mail from forgeries.

The standards work that followed produced both SPF and a competing proposal that failed, and the distinction between them still explains why the protocol authenticates what it does. Understanding that history clarifies which parts of the specification are load-bearing and which are vestigial artifacts safe to remove.

The Origins of Sender Policy Framework (2000-2006): From SMTP Vulnerability to RFC 4408

The first public discussion of using DNS records to authorize outbound mail servers surfaced in 2000, and the flurry of proposals on IETF mailing lists in 2002 and 2003 ignited serious standards work. In June 2003, Meng Weng Wong merged the Reverse MX proposal by Hadmut Danisch and the Designated Mailer Protocol by Gordon Fecyk into a unified specification called "Sender Permitted From," renamed Sender Policy Framework in February 2004.

Wong launched the SPF-discuss mailing list and, over the next six months, incorporated contributions from a rapidly growing community that shaped the syntax administrators recognize today. In early 2004, the IETF formed the MARID working group to unify SPF with Microsoft's Caller ID for E-mail proposal, producing what became known as Sender ID.

The merger collapsed under technical disagreements and licensing conflicts. The core division was irreconcilable: Sender ID checked the Purported Responsible Address derived from message headers, while the SPF community insisted on authenticating only the envelope-from address, the return path transmitted during the SMTP conversation and the one piece of sender information a receiving server can trust before accepting the message body.

The community ultimately walked away from MARID and returned to what it called "classic" Sender Policy Framework. In July 2005, the IESG approved the protocol as an experimental standard, and RFC 4408 was published on April 28, 2006, inviting the broader community to observe and test SPF over two years of real-world deployment.

RFC 7208 and the Path to Standards Track (2014)

After nearly eight years of operational experience, the SPF specification graduated from experimental to standards-track. On April 25, 2014, the IETF published RFC 7208 as a Proposed Standard, formally obsoleting RFC 4408.

The new standard incorporated lessons learned from widespread deployment. It added the 10-DNS-lookup limit to prevent denial-of-service conditions, introduced the concept of void lookups to handle non-responsive DNS queries gracefully, and clarified error-handling semantics that had caused inconsistent implementations across mail transfer agents. RFC 7208 remains the authoritative Sender Policy Framework specification and has not been obsoleted.

Sender ID and the Deprecated Type 99 DNS Record

Sender ID, the compromise technology emerging from the failed MARID working group, was published as experimental RFC 4406 alongside SPF's RFC 4408 and never achieved equivalent adoption. Its reliance on the PRA header, an address synthesized from multiple header fields, created ambiguity that the Sender Policy Framework community had warned against, and Sender ID is now considered obsolete.

The distinction between the two protocols remains an important technical footnote. SPF authenticates the envelope-from, while Sender ID attempts to authenticate the header-from, a job later handled more effectively by DMARC's identifier alignment.

The other major deprecation concerns DNS record types. In 2005, IANA assigned resource record type 99 specifically for Sender Policy Framework records, and RFC 4408 recommended domains publish data in both TXT records and the dedicated type 99 RR. Adoption of type 99 was minimal, and the SPFbis working group that produced RFC 7208 concluded that significant migration to the dedicated record type was very unlikely, making removal the cleanest path forward.

RFC 7208 Section 5.5 explicitly removed support for the SPF RR type, so receiving mail servers must now check only TXT records. Any domain still publishing a type 99 record maintains a vestigial artifact with no operational effect.

Sender Policy Framework adoption reached a critical inflection point on February 1, 2024, when Google began requiring SPF or DKIM authentication for all domains sending email to Gmail addresses. The move turned email authentication from a best practice into a delivery prerequisite and triggered similar requirements from Yahoo, Microsoft, and other major mailbox providers, making correct configuration the difference between outbound messages, including phishing simulations, reaching employee inboxes or being silently discarded.

Enterprise SPF Strategies: Multi-Domain, Microsoft 365, and Ongoing Maintenance

Managing SPF at enterprise scale means governing dozens of sending services across multiple domains, each with distinct authentication requirements. The work starts with inventorying every service and domain that sends mail, then configuring the correct Microsoft 365 mechanism for the tenant type in use.

From there, enterprises need explicit records for every sending subdomain, hard-fail policies on every parked domain, and a quarterly audit cadence with documented change control for every modification. Sender Policy Framework at scale is a governance discipline as much as a DNS exercise, and the failure modes are almost always organizational.

1. Sender Policy Framework for Microsoft 365: Commercial, GCC, and 21Vianet

Microsoft 365 tenants do not all point to the same SPF record. The standard mechanism for commercial tenants and Government Community Cloud is include:spf.protection.outlook.com, while GCC High and Department of Defense tenants must use include:spf.protection.office365.us instead because they operate in Microsoft's sovereign cloud, where pointing to the commercial endpoint produces silent failures.

For organizations operating in China, the 21Vianet-operated Microsoft 365 instance requires include:spf.protection.partner.outlook.cn. Using the wrong endpoint means legitimate mail fails authentication, and the failure stays hidden until someone notices the bounce messages.

The MOERA domain, the *.onmicrosoft.com address, already has its Sender Policy Framework record managed by Microsoft and needs no action. Every custom domain, however, requires its own TXT record with the correct mechanism for the environment, as detailed in Microsoft's Defender for Office 365 documentation.

According to Lazy Gatekeepers: A Large-Scale Study on SPF Configuration in the Wild (ACM Internet Measurement Conference 2023), which analyzed 12 million domains, 2.9% of SPF records are broken, most commonly from exceeding the lookup ceiling. Enterprises with complex Microsoft 365 deployments are especially vulnerable to this gap, since a single mistyped mechanism can trigger authentication failures across every domain that includes it.

2. Multi-Domain and Subdomain SPF Management

SPF does not cascade. Every subdomain that sends email needs its own record, because the TXT record at an apex domain covers only that domain, so a marketing team sending campaigns from news.example.com needs a dedicated record even when the parent domain already has one.

Enterprises managing dozens of brands and domains face a structural choice among three patterns:

• Per-domain records maintained independently: These offer the most granular control and isolate failures, since a misconfiguration in one brand's record never breaks another's delivery;
• A unified include hierarchy: Each domain references a central Sender Policy Framework record, which simplifies maintenance while creating a single point of failure;
• Subdomain delegation via redirect=: This hands the entirety of evaluation to the target domain, which works well when a subdomain should mirror its parent's policy exactly.

For domains that should never send mail, including parked brands, acquired company domains, and defensive registrations, the correct record is v=spf1 -all. This tells receiving servers to reject everything, closing a vector cyberattackers exploit by spoofing forgotten domains, and each unused domain without this record is an open door for email spoofing against the brand.

3. Safe SPF Migration and Ongoing Maintenance

When switching email providers or adding a new sending service, never delete the old SPF mechanism before the new one is active. Add the new provider's include: or IP range alongside the existing entry, confirm both services deliver mail correctly for at least one full business cycle, and only then remove the old entry. A premature cutover creates an authentication gap where legitimate mail gets quarantined or rejected, often without immediate detection.

Quarterly audits are the minimum for enterprise Sender Policy Framework hygiene. Each review should verify that every listed sending service remains in active use, that no mechanism exceeds the 10-DNS-lookup limit specified in RFC 7208, and that parked domains still carry v=spf1 -all. Monitoring tools that parse DMARC aggregate reports surface unauthorized sending sources and reveal services added outside the change control process.

Document every modification with the date, the service added or removed, and the approver. When sending services change faster than the documentation, the SPF record becomes a liability disguised as a control.

Marketing teams onboard email platforms without telling IT, and the record breaks a quarter later with no bounce to explain it. Adaptive Security keeps employees ready for the cyberattacks that gap invites.

Book a demo

Beyond SPF: Why Email Authentication Needs a Human Complement

SPF, DKIM, and DMARC authenticate sending infrastructure without ever evaluating whether an email's content, intent, or sender identity is trustworthy. According to Verizon's 2026 Data Breach Investigations Report, the human element was involved in 62% of breaches, up from 60% the previous year.

Many phishing emails pass every authentication check because they arrive from compromised legitimate accounts, cyberattacker-owned domains with valid Sender Policy Framework records, or abused SaaS platforms whose infrastructure is fully authenticated. Email authentication stops domain spoofing at the infrastructure level, and it cannot detect a well-crafted social engineering message sent from a real account that a human being must still decide whether to trust.

What SPF Cannot Protect Against: The Gaps in Email Authentication

SPF validates that an email originated from an IP address authorized by the sending domain, answering one narrow question: did this message come from an approved server? It does not answer whether the person behind the message is who they claim to be, whether the visible From name matches the actual sender, or whether the request inside the email is legitimate.

Several cyberattack categories sail past Sender Policy Framework, DKIM, and DMARC without triggering a single alert:

• Compromised legitimate accounts: A cyberattacker who has taken over a real employee's mailbox at a trusted organization sends emails that pass every protocol, because the sending infrastructure is genuine and the domain reputation is spotless;
• Display-name spoofing: Manipulating the human-readable From field to show a trusted executive's name while routing through an unrelated address that passes SPF leaves the authentication headers clean even though the visible sender is fraudulent;
• Lookalike-domain cyberattacks: Registering typo-squatted domains, configuring valid Sender Policy Framework and DKIM for them, and sending fully authenticated phishing emails from infrastructure the cyberattacker controls defeats alignment entirely.

In every case, the technical perimeter holds while the human target remains exposed. According to the National Cybersecurity Alliance's 2025-2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 58% of employed participants reported receiving no cybersecurity awareness training on the security or privacy risks of AI tools, despite 65% now using them.

The Case for a Layered Email Security Strategy Around Sender Policy Framework

Email authentication and cybersecurity awareness training are complementary layers in a defense-in-depth model. SPF, DKIM, and DMARC form the technical perimeter, blocking domain spoofing, providing policy enforcement, and generating visibility into who sends mail on an organization's behalf.

When a phishing email clears every authentication check, the employee reading it becomes the last line of defense and the only layer capable of recognizing the social engineering behind a legitimate-looking message. According to the CrowdStrike 2026 Global Threat Report, average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured at just 27 seconds, which leaves almost no margin for a delayed human response.

Organizations deploying DMARC at enforcement level still experience phishing incidents because cyberattackers continuously adapt, shifting to compromised accounts, registering new domains with valid authentication, or abusing trusted platforms whose infrastructure passes every check. The technical layer reduces the cyberattack surface while the human layer, built through realistic multi-channel phishing simulations and continuous cybersecurity awareness training, catches what gets through.

How Adaptive Security Closes the Gap SPF Leaves Open

A correctly configured SPF record eliminates direct domain forgery and nothing beyond it. The cyberattacks that actually reach employees, AI-generated business email compromise from compromised vendor accounts, display-name impersonation, and lookalike domains carrying their own valid Sender Policy Framework records, arrive fully authenticated. Adaptive Security addresses that residual risk by detecting and removing AI-powered phishing before delivery, layering onto Google Workspace or Microsoft 365 through an API with no MX record changes and no mail flow disruption.

Detection is where authentication stops and reasoning begins. Native filters match known patterns, so novel AI-generated cyberattacks pass by design, while Adaptive Security applies behavioral signals, intent analysis, and LLM reasoning to catch cyberattacks carrying no prior signature. When a cyberattack is confirmed, it is remediated automatically across every inbox it reached, and similar messages are taken down simultaneously.

Every detected cyberattack becomes intelligence rather than a closed ticket. The email that bypassed Sender Policy Framework links back to the employee it targeted, feeding their risk score and triggering targeted cybersecurity awareness training on that exact technique, while Cloud Email Security, phishing simulations, Compliance Training, and AI Governance operate as one cybersecurity awareness training platform. Organizations get the human layer that authentication was never built to provide, calibrated against the cyberattacks their people actually receive.

Fully authenticated phishing reaches employees every day, and no DNS record will ever flag it. Adaptive Security detects those cyberattacks, removes them across every inbox, and turns each one into cybersecurity awareness training.

Book a demo

Frequently Asked Questions About What Is SPF

What Does SPF Stand for in Email Security?

SPF stands for Sender Policy Framework. It is an email authentication protocol, standardized in RFC 7208, that allows domain owners to define which mail servers are authorized to send email on their behalf. When an email arrives, the receiving mail server looks up the sending domain's record in DNS and checks whether the connecting IP address appears in the authorized list. If the IP matches, SPF returns a pass. If not, the result is a fail, softfail, or neutral depending on the domain's configured enforcement policy. The protocol was created to close a fundamental gap in SMTP, which has no built-in sender verification, meaning anyone can forge the return-path address. Alongside DKIM and DMARC, Sender Policy Framework is one of the three core email authentication standards used to combat domain spoofing.

Does Sender Policy Framework Prevent Email Spoofing and Phishing?

SPF prevents unauthorized servers from spoofing a domain in the envelope-from (Return-Path) address, and it does not stop all forms of email spoofing and phishing. The protocol authenticates only the invisible Return-Path domain and never checks the visible From header that recipients see in their inbox. Cyberattackers bypass Sender Policy Framework through display-name spoofing, where the sender name shows a trusted identity while the actual email address is unrelated. It also cannot stop phishing from compromised legitimate accounts that pass checks cleanly, or cyberattacks using lookalike domains where the cyberattacker sets up their own domain with valid SPF. Meaningful protection requires combining the protocol with DKIM and DMARC, and organizations relying on Sender Policy Framework alone remain vulnerable to the social engineering tactics driving most successful phishing cyberattacks.

What Is the Difference Between SPF, DKIM, and DMARC?

SPF, DKIM, and DMARC are three email authentication protocols serving distinct functions. Sender Policy Framework validates the sending server's IP address against a domain-authorized list, answering whether a given server is allowed to send mail for a domain. DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify that an email's content has not been altered in transit and that it originated from the signing domain. DMARC (Domain-based Message Authentication, Reporting, and Conformance) provides policy enforcement and reporting by requiring alignment: the domain authenticated by SPF or DKIM must match the visible From header domain. DMARC also tells receiving servers what to do with unauthenticated messages, whether that means monitoring, quarantining, or rejecting them. All three are necessary because each addresses gaps the others leave open.

What Is the 10 DNS Lookup Limit in SPF and How Is It Fixed?

The 10 DNS lookup limit is a restriction defined in RFC 7208 capping the number of DNS queries a single SPF evaluation can trigger. Each include, a, mx, ptr, and exists mechanism counts as one lookup, as does the redirect modifier, while IP-based mechanisms (ip4 and ip6) do not count. Exceeding 10 lookups produces a PermError, meaning authentication fails and legitimate email may be rejected or spam-filtered. Fixing it starts with auditing the record and removing include statements for services no longer sending on the domain's behalf, then replacing include mechanisms with their resolved IP addresses where practical. For complex environments, Sender Policy Framework flattening resolves all nested includes into a single flat IP list, reducing lookups to one, though flattened records require ongoing maintenance when providers update their IP ranges.

Can an Email Pass SPF but Fail DMARC?

Yes. An email can pass SPF authentication and still fail DMARC when the domain authenticated by the protocol, the envelope-from or Return-Path domain, does not align with the domain in the visible From header. DMARC requires alignment: the Sender Policy Framework-authenticated domain must match the From header domain, either exactly under strict alignment or at the organizational level under relaxed alignment. This commonly occurs with third-party senders. A marketing platform sends email displaying a customer's domain in the From header while the platform's own domain appears in the Return-Path for bounce processing, so SPF authenticates the platform's domain and passes, yet DMARC sees a mismatch and returns a fail. This is precisely why DKIM is essential alongside the Sender Policy Framework, since DKIM can provide the domain alignment that SPF alone cannot guarantee.

Key Takeaways

• What is SPF comes down to one function: Sender Policy Framework lets domain owners publish a DNS TXT record naming every mail server authorized to send on their behalf, and receiving servers check every connection against it;
• SPF authenticates the envelope-from domain in preference to the visible From header, which is why display-name spoofing and lookalike domains bypass it entirely;
• Sender Policy Framework only becomes meaningful protection when paired with DKIM and DMARC, since DMARC supplies the alignment that ties authentication results to the identity recipients actually see;
• A record ending in -all states a definitive policy, while ~all invites cyberattackers scanning for permissive configurations and +all disables SPF altogether;
• The 10-DNS-lookup ceiling and the 255-character limit break Sender Policy Framework silently, so quarterly audits and dedicated subdomains keep multi-provider environments inside both boundaries;
• Every parked, acquired, and defensive domain needs v=spf1 -all, because forgotten domains are the ones cyberattackers spoof first;
• SPF is an outbound control, so inbound phishing defense depends on cloud email security and cybersecurity awareness training that prepares employees for fully authenticated cyberattacks.

Authentication records protect a domain's reputation while leaving the people who read the mail to judge every request alone. Adaptive Security gives security teams both layers in one cybersecurity awareness training platform.

Take a self-guided tour