Sender Policy Framework (SPF): What It Is and How It Works

Sender Policy Framework (SPF) is an email authentication method that lets a domain owner publish, in DNS, the servers and IP addresses permitted to send email using that domain’s envelope sender. When a receiving mail server gets a message, it compares the connecting server’s IP address with the domain’s SPF policy and returns a result such as pass, fail, or error.

What is Sender Policy Framework?

Sender Policy Framework, usually called SPF, is a published list of approved email-sending sources. The list lives in a DNS TXT record for a domain and uses a compact syntax beginning with v=spf1. Its purpose is to give recipient mail servers a way to check whether the infrastructure attempting to deliver a message has permission to use a particular domain in the SMTP transaction.

SPF addresses a basic weakness in email: without authentication controls, a server can claim an envelope sender address at almost any domain. For example, a malicious server could attempt to send a message with the SMTP envelope sender billing@example.com even though it has no relationship with example.com. If example.com has an SPF record, the receiving server can compare the connecting IP address with the policy published by example.com.

An SPF record does not contain a list of individual people, inboxes, or visible display names. It authorizes mail systems. That can mean a dedicated outbound IP address, an office mail server, a cloud email provider, a marketing platform, a transactional email API, or another domain’s published SPF policy.

In practical terms, SPF answers this question:

Is the server currently delivering this email allowed to use the envelope-sender domain it presented during SMTP?

That scope matters. SPF does not directly validate the visible From: header that recipients see in their inbox. It validates the SMTP envelope identity, often surfaced to recipients as the Return-Path after delivery. DMARC is the standard that connects SPF or DKIM authentication to the visible From: domain through alignment rules.

Why Sender Policy Framework matters for deliverability

SPF is not a promise of inbox placement. A message can pass SPF and still land in spam because of poor engagement, a bad sending reputation, misleading content, complaint rates, or other filtering signals. But SPF is an important baseline authentication signal, and an invalid or missing configuration can make legitimate mail look less trustworthy.

Major mailbox providers expect domains that send email to use authentication. Google’s sender guidance requires all senders to authenticate with SPF or DKIM, while higher-volume senders to personal Gmail accounts must use SPF, DKIM, and DMARC. Authentication helps receiving systems distinguish legitimate infrastructure from spoofing and phishing attempts. (support.google.com)

For transactional email, SPF matters because messages such as password resets, receipts, account alerts, and login confirmations are time-sensitive. If a receiving server cannot authenticate an expected source, it may filter, defer, or reject a message depending on its local policy and the rest of the message’s authentication and reputation signals.

For campaigns, SPF supports brand protection and operational consistency. Marketing teams often use several services at once: a corporate mailbox provider, a customer-support system, an automation platform, and an email delivery provider. Every legitimate sender must be accounted for in the domain’s email-authentication design. A forgotten tool can cause SPF failures, while an old authorization can leave unnecessary sending paths open.

SPF improves trust, but it is not enough alone

SPF has three major limitations:

• It checks the envelope sender or SMTP HELO/EHLO identity, not necessarily the visible From: domain.
• It can break when email is forwarded, because the forwarding server’s IP was not the original sender’s authorized IP.
• It does not cryptographically protect message content or headers after sending.

That is why a complete authentication posture normally includes SPF, DKIM, and DMARC. SPF establishes whether a sending host is authorized. DKIM adds a cryptographic signature tied to a domain. DMARC evaluates whether SPF or DKIM passed with a domain aligned to the visible From: address, then publishes a policy for handling failures.

How an SPF check works

An SPF evaluation happens during SMTP delivery, while the receiving server is deciding how to handle an incoming message. The receiver identifies the IP address of the server connecting to it, obtains the relevant SPF policy from DNS, and evaluates the record from left to right.

The basic flow looks like this:

1. A sending server opens an SMTP connection to a recipient server.
2. The sending server identifies an envelope sender with the SMTP MAIL FROM command, such as bounce@mailer.example.com.
3. The recipient server notes the connecting server’s public IP address.
4. The recipient queries DNS for the SPF TXT record at mailer.example.com.
5. The recipient evaluates that record’s mechanisms against the connecting IP and other SMTP information.
6. The recipient records an SPF result, such as pass, fail, softfail, neutral, none, temperror, or permerror.

If the envelope sender is empty, as is common for delivery-status notifications and bounces, SPF falls back to evaluating the SMTP HELO or EHLO domain instead. This is one reason email infrastructure needs properly configured hostnames and not just a policy for the visible brand domain.

The SPF standard defines this behavior in RFC 7208. It specifies that SPF authorizes use of domains in the SMTP MAIL FROM identity and the SMTP HELO/EHLO identity, rather than the RFC 5322 From: header recipients see. (rfc-editor.org)

The domain SPF actually checks

A frequent source of confusion is that a message can show From: updates@example.com and still be evaluated against another domain for SPF. Consider this simplified message path:

Visible From: updates@example.com
Envelope sender / Return-Path: bounce@bounces.example-mail.net
Connecting sending IP: 203.0.113.25

In this case, SPF is checked against bounces.example-mail.net, because that is the envelope-sender domain. The visible From: address does not determine SPF pass or fail on its own.

This setup can still pass DMARC if the authenticated SPF domain aligns with the visible From: domain under DMARC’s alignment rules. In many provider-managed configurations, however, DKIM is the more dependable path to DMARC alignment because it can sign using a domain aligned with the visible sender domain even when the bounce domain is different.

SPF record syntax explained

An SPF policy is published as a DNS TXT record. A typical record begins with the version marker and ends with a catch-all mechanism:

v=spf1 ip4:198.51.100.24 include:spf.example-mail.net -all

This example means:

• v=spf1 identifies the record as SPF version 1.
• ip4:198.51.100.24 authorizes that IPv4 address to send.
• include:spf.example-mail.net evaluates another domain’s SPF policy and authorizes the sources that pass it.
• -all says that all other sources should fail.

SPF is not a separate DNS record type that should be created alongside TXT for modern implementations. SPF policies are published in TXT records. The legacy DNS SPF resource-record type is deprecated and should not be used for a new setup.

Common SPF mechanisms

The most common mechanisms are below.

The ptr mechanism exists in the specification for compatibility but is discouraged because it is expensive and unreliable. Modern SPF policies should ordinarily use explicit IP ranges, carefully managed include mechanisms, or provider-supported domains instead.

Qualifiers: plus, minus, tilde, and question mark

Every SPF mechanism can have a qualifier. If no qualifier is shown, + is implied.

The final all mechanism is especially important. A record ending in ~all says unmatched mail should softfail. A record ending in -all says unmatched mail should fail. Neither result alone dictates a universal receiver action; recipient systems combine SPF with DMARC, local policy, reputation, and other signals.

A strict -all is appropriate only after the sender has confirmed every legitimate source. Publishing it before discovering all applications that send mail can disrupt legitimate receipts, help-desk replies, invoices, and automated notifications.

SPF results and what they mean

SPF is not a percentage or campaign metric. It is an authentication evaluation with a defined result. A sender should monitor the distribution of those results across its mail streams, but there is no single SPF “score” calculated from sends and failures.

Here are the main results:

• Pass: The connecting host matched an authorized mechanism in the policy.
• Fail: The policy explicitly says the host is not authorized, commonly through -all.
• Softfail: The host is probably not authorized, commonly due to ~all.
• Neutral: The domain stated no assertion about whether the host is authorized.
• None: No usable SPF policy was found for the evaluated domain.
• Temperror: A temporary problem, such as a transient DNS failure, prevented a reliable result.
• Permerror: A permanent configuration or evaluation problem occurred, such as an invalid record or too many DNS-triggering mechanisms.

A worked SPF evaluation example

Suppose example.com publishes this record:

v=spf1 ip4:198.51.100.24 include:_spf.newsletter.example -all

A recipient receives a message where:

Envelope sender: mail@example.com
Connecting IP: 198.51.100.24

The receiver starts at the left:

1. ip4:198.51.100.24 matches the connecting IP.
2. SPF returns pass immediately.
3. The receiver does not need to evaluate the later include or -all terms.

Now change the connecting IP to 203.0.113.77. It does not match the ip4 mechanism, so the receiver evaluates include:_spf.newsletter.example. If the nested policy authorizes 203.0.113.77, the include matches and SPF passes. If it does not, the receiver reaches -all, and SPF returns fail.

The important operational detail is that SPF is evaluated left to right and stops when a mechanism produces a match. Put intended, specific authorizations before the final all mechanism.

The SPF 10-DNS-lookup limit

The most consequential SPF implementation limit is the DNS lookup cap. During one SPF evaluation, a receiver must limit the total number of mechanisms and modifiers that trigger DNS lookups to no more than 10. Exceeding that limit produces a permanent SPF error, commonly shown as permerror. (rfc-editor.org)

This is why an SPF record can look reasonable while still failing in production. Each include often leads to another SPF record, and that nested record may contain its own include, a, mx, exists, or redirect terms. The count is based on the evaluation path, not merely the visible number of words in the top-level TXT record.

Numeric lookup-count example

Assume a company publishes:

v=spf1 include:_spf.workspace.example include:spf.transactional.example include:spf.marketing.example include:spf.support.example -all

At first glance, there are only four include terms. But suppose the paths consume lookups as follows:

1. include:_spf.workspace.example consumes 3 lookups.
2. include:spf.transactional.example consumes 2 lookups.
3. include:spf.marketing.example consumes 4 lookups.
4. include:spf.support.example consumes 3 lookups.

The total is 3 + 2 + 4 + 3 = 12 DNS-triggering evaluations. That exceeds the limit of 10. A receiver can return permerror even though every vendor was legitimately intended to be authorized.

The standard also constrains void DNS lookups, meaning queries that return neither a usable answer nor an error. A policy with too many nonexistent or misconfigured referenced names can therefore fail even before a sender reaches the broader lookup ceiling.

How to avoid lookup-limit failures

To stay below the limit:

• Inventory every real mail source before adding includes.
• Remove services that no longer send for the domain.
• Avoid repeatedly nesting includes without checking their expanded lookup paths.
• Use separate subdomains for separate mail streams where that simplifies ownership and policy design.
• Ask providers for their current recommended SPF authorization value instead of copying old snippets from prior implementations.
• Test the fully expanded policy after every DNS or vendor change.

Do not solve the problem by casually replacing every include with IP addresses. Providers can rotate infrastructure, and hardcoded ranges can become stale. Use explicit IPs only when the infrastructure is genuinely static and you own the maintenance responsibility.

How to set up Sender Policy Framework correctly

A reliable SPF setup begins with an inventory, not with a DNS editor. The goal is to identify every system that can send mail with an envelope sender at the domain or subdomain being configured.

Start by listing sources such as:

• Google Workspace or Microsoft 365 mailbox sending
• Transactional email APIs and SMTP relays
• Marketing automation platforms
• Customer-support and ticketing systems
• CRM sequences and sales tools
• Website forms and application servers
• Monitoring, billing, and identity providers
• Legacy servers, printers, or on-premises applications

Next, decide whether every source should really send from the same domain. Separate subdomains often make authentication easier to understand and safer to operate. For example, a company might use notify.example.com for application notifications, mail.example.com for campaigns, and support.example.com for help-desk messages.

Each subdomain can have its own SPF record. This reduces the temptation to build one oversized, fragile policy for unrelated tools. It also makes it easier to retire a service without changing the authorization model for every other mail stream.

Publish one SPF record per domain

A domain should have one SPF policy record. Multiple independent TXT strings that each begin with v=spf1 do not combine into a larger authorization list. Multiple SPF records can lead recipients to return permerror.

If several systems need authorization, combine their mechanisms into one logical SPF record. DNS providers may display a long TXT value as quoted segments for storage or interface reasons; that is different from publishing multiple separate SPF policies. The SPF evaluator must see one coherent v=spf1 policy.

A cautious initial policy might use softfail while the inventory is being validated:

v=spf1 ip4:198.51.100.24 include:_spf.transactional.example ~all

After confirming all legitimate sources and monitoring results, a sender may move to a stricter policy:

v=spf1 ip4:198.51.100.24 include:_spf.transactional.example -all

The exact provider include domain must come from that provider’s current documentation. Do not assume that an include value is interchangeable across vendors or that an old value remains supported indefinitely.

For implementation details beyond DNS, consult the platform’s email API setup guides so the envelope sender, DKIM configuration, and sending domain are designed together rather than as unrelated settings.

Common causes of SPF failure or SPF permerror

SPF problems are usually configuration problems, not content problems. Changing a subject line, adding a logo, or lowering campaign volume will not repair an invalid SPF record. The fix starts by identifying what identity was evaluated, which IP connected, and which SPF mechanism produced the result.

The sending service was never authorized

This is the most common cause. A new email provider, customer-support platform, or SaaS tool begins sending mail using an envelope sender at the company domain, but nobody updates SPF. The recipient sees an unfamiliar IP, finds no matching mechanism, and returns fail or softfail.

This frequently happens when teams buy tools independently. Marketing may add a campaign service, product engineering may add a transactional API, and support may configure a ticketing system. Each tool works in isolation, but the domain’s DNS policy never receives a coordinated update.

The wrong domain was checked

Teams sometimes inspect the visible From: domain and assume that is the SPF domain. The recipient instead evaluated the envelope sender’s domain, or the HELO/EHLO domain for a message with an empty envelope sender. If those domains are provider-managed or different from the visible sender domain, adding an SPF record to the visible domain may not change the result at all.

Read the full message headers. Look for Return-Path, Received-SPF, and Authentication-Results. Those fields can reveal the evaluated identity, the connecting IP, and whether the failure was SPF itself, DMARC alignment, or another authentication component.

More than one SPF record exists

Multiple DNS TXT records that each start with v=spf1 are not a valid way to authorize multiple vendors. Receivers can treat this as a permanent error. Consolidate the mechanisms into a single SPF policy for that exact domain.

This mistake often appears after a migration. A team leaves the original mailbox-provider record in place, then adds a second record supplied by an email platform. The correct approach is normally to merge approved mechanisms into the existing single policy while verifying the lookup count.

The policy exceeds 10 DNS lookups

Nested includes are a common hidden failure. A sender may have only three visible vendor includes, but each provider’s policy may fan out into several more DNS-triggering terms. Since the limit applies during evaluation, the record needs periodic review as vendors change their own SPF infrastructure.

A strict -all policy was published too early

A strict ending is useful after a domain’s actual sending sources are known. It becomes disruptive when important but forgotten systems still send mail. Examples include an automated invoice tool, a form-to-email script, a recruiting platform, or an employee’s outbound message from an on-premises relay.

The solution is not to replace -all with +all. +all effectively authorizes every sender and defeats SPF’s security purpose. Instead, identify the legitimate source and authorize it specifically, or change the application so it uses an approved relay and envelope-sender domain.

How to fix and improve an SPF configuration

Treat SPF maintenance as an email-infrastructure process rather than a one-time DNS task. The following workflow is effective for most organizations.

1. Capture a failed message’s headers. Record the connecting IP, envelope sender, HELO/EHLO domain, SPF result, DKIM result, and DMARC result.
2. Identify the exact evaluated domain. Do not begin by editing the visible From: domain unless headers show it was actually used for SPF.
3. Map the mail source to an owner. Determine whether the source is an approved application, an unauthorized service, a forwarded message, or a spoofing attempt.
4. Retrieve the source’s current provider guidance. Use the vendor’s official domain-authentication documentation for any include value or custom bounce domain requirement.
5. Update the one SPF TXT policy for that domain. Merge authorization carefully and preserve a single v=spf1 record.
6. Count DNS-triggering terms. Include nested paths, not just visible top-level includes.
7. Validate DKIM and DMARC at the same time. SPF alone is not a complete anti-spoofing strategy.
8. Send real tests to multiple mailbox providers. Inspect the received headers rather than relying only on an outbound application’s success message.
9. Document the change. Record the vendor, domain, purpose, record value, owner, and review date.

Use dedicated subdomains for clearer ownership

Subdomains are often the cleanest long-term improvement. Instead of allowing every vendor to send with @example.com in its envelope sender, give each mail stream a deliberate boundary.

For example:

Application mail: bounce@notify.example.com
Marketing mail: bounce@news.example.com
Support mail: bounce@support.example.com

Each of those domains can have an SPF policy tailored to its system. The application team does not need to modify marketing infrastructure, and the marketing team does not need to add unrelated relay services to a critical transactional domain.

This approach also reduces blast radius. If a campaign provider is retired or misconfigured, the change is isolated to its mail subdomain rather than affecting password-reset and receipt delivery.

SPF, DKIM, and DMARC: how they work together

SPF, DKIM, and DMARC are frequently grouped together because their strengths cover one another’s weaknesses.

A message does not need both SPF and DKIM to pass DMARC. DMARC can pass when either SPF passes and aligns, or DKIM passes and aligns. Still, deploying both provides resilience. Forwarding often breaks SPF but can preserve a valid DKIM signature. Conversely, a valid SPF result can support authentication where DKIM is unavailable or temporarily misconfigured.

Google describes the relationship simply: SPF indicates that a server sent the message, while DKIM indicates that the sender wrote it; using both produces a stronger signal. (knowledge.workspace.google.com)

For a sender building new infrastructure, the practical goal is not merely “SPF pass.” The goal is authenticated, aligned mail with stable sending identities, controlled bounce domains, valid DKIM signatures, a monitored DMARC policy, and a reputation appropriate to the mail stream.

SPF and email forwarding

Forwarding is a structural challenge for SPF. When Alice sends mail through an authorized server to Bob, SPF may pass at Bob’s original mailbox provider. If Bob then forwards that message to Carol, Carol’s provider receives the mail from Bob’s forwarding server, not Alice’s original authorized sender.

If the envelope sender remains Alice’s domain, Carol’s provider evaluates SPF against Alice’s policy but sees Bob’s forwarding IP. That IP likely is not authorized by Alice’s SPF record, so SPF can fail.

Some forwarding systems mitigate this with Sender Rewriting Scheme (SRS), which rewrites the envelope sender so the forwarding service can be authenticated for the forwarded delivery. DKIM can also help because a valid signature may survive forwarding, provided the forwarder does not modify signed content in a way that breaks the signature.

This is another reason not to treat an isolated SPF failure as proof that a sender is malicious. Authentication results require context. A forward can fail SPF legitimately, while a properly aligned DKIM signature still enables DMARC to pass.

Sender Policy Framework best practices for campaigns and transactional email

The right SPF record is necessary, but the operating model matters just as much. Email teams should manage SPF as part of change control, vendor governance, and deliverability monitoring.

Keep transactional and marketing mail separate

Transactional and promotional mail have different urgency, sending patterns, recipients, and reputation risks. Separate domains or subdomains let teams isolate authentication policies and manage each stream independently.

A transactional mail stream might send only through an application API and use a narrow SPF policy. A campaign stream might need authorization for an automation platform, a preference center, and a tracking or reply-management service. Keeping those systems separate reduces record complexity and helps prevent a campaign tool change from interrupting account-security messages.

Remove stale authorizations

Every active SPF mechanism is a statement that a service may send on behalf of the domain. Leaving old vendors in a policy expands the set of infrastructure that appears authorized, complicates audits, and makes it harder to understand which source generated a message.

Review SPF after a platform migration, merger, acquisition, brand launch, major DNS change, or security incident. A quarterly review is sensible for domains with many independent mail systems; smaller environments should still review whenever they add or retire a sender.

Test the complete authentication chain

A DNS checker can tell you whether a TXT record is syntactically plausible, but real-mail testing tells you whether your chosen envelope sender, DKIM signing domain, and visible From: domain work together. Send a test message, open the raw headers at the receiving mailbox, and inspect Authentication-Results.

Look for more than SPF pass. Confirm that DKIM passes, DMARC passes, and the domains align as intended. If a provider uses its own return-path domain, expect SPF to authenticate that domain; make sure DKIM and DMARC still produce the desired brand-domain alignment.

Common Sender Policy Framework misconceptions

“SPF protects the From address by itself”

Not reliably. SPF checks the SMTP envelope identity, which can differ from the visible From: field. DMARC is what applies alignment to the visible From: domain.

“Adding a second SPF TXT record adds another sender”

No. Multiple v=spf1 policies for the same domain can create a permanent SPF error. Combine intended mechanisms into one record.

“A long SPF record is automatically invalid”

Not necessarily. DNS TXT strings can be represented in segments, and record character length is not the same as SPF lookup count. The critical operational limit is the number of DNS-triggering mechanisms evaluated, which must remain at or below 10.

“Use +all so legitimate mail never fails”

That makes SPF effectively meaningless because every source matches. A secure policy authorizes known senders and uses an appropriate final all mechanism after testing.

“SPF pass guarantees inbox placement”

No. Authentication is necessary infrastructure, not a substitute for permission-based acquisition, recipient engagement, low complaint rates, accurate list hygiene, useful content, and a healthy sending reputation.

Conclusion

Sender Policy Framework is a DNS-based authorization system for email-sending infrastructure. It lets a domain publish which hosts may use its envelope identity, and it gives recipient servers a standardized way to detect unauthorized senders.

A good SPF deployment is specific, complete, and maintainable: one valid TXT policy per sending domain, every legitimate source deliberately authorized, no unnecessary legacy services, and no more than 10 DNS-triggering evaluations. Pair it with DKIM and DMARC, separate unrelated mail streams onto sensible subdomains, and verify the result in real message headers after each change.

FAQ

What is an SPF record?

An SPF record is a DNS TXT record beginning with v=spf1 that declares which IP addresses, servers, or third-party mail services are authorized to send email for a domain’s envelope sender.

Does SPF check the visible From address?

Usually no. SPF checks the SMTP MAIL FROM domain, commonly shown as the Return-Path, or the HELO/EHLO domain when the envelope sender is empty. DMARC evaluates alignment with the visible From: domain.

Should an SPF record end in ~all or -all?

Use ~all while auditing and testing if you need a cautious transition. Use -all after confirming every legitimate sender is authorized. Do not use +all, because it authorizes every source.

Why does SPF return permerror?

Common causes include multiple SPF records for one domain, invalid syntax, excessive DNS lookups, or broken nested include paths. The 10-DNS-lookup limit is a particularly common cause in multi-vendor setups.

Can SPF alone stop spoofing?

No. SPF helps receivers identify unauthorized envelope senders, but it does not by itself protect the visible From: domain or message content. Use SPF with DKIM and DMARC for stronger spoofing protection and better deliverability resilience.