SPF Email Authentication: What It Is, How It Works, and How to Fix It

SPF email authentication, or Sender Policy Framework, is a DNS-based method for declaring which mail servers and services are allowed to send email using a domain in the SMTP envelope sender. Receiving mail systems compare the server’s sending IP address with that domain’s SPF record and return a result such as pass, fail, softfail, neutral, or permanent error.

What SPF means in email sending

SPF stands for Sender Policy Framework. It is an email authentication standard designed to make it harder for an unauthorized server to impersonate a domain during SMTP delivery. A domain owner publishes an SPF policy as a DNS TXT record, and receiving systems use that policy to decide whether the connecting server is authorized for the message’s envelope-sender domain.

The key phrase is envelope sender. SPF does not directly authenticate the visible address in the email client’s From: field. Instead, it normally evaluates the domain used in the SMTP MAIL FROM command, which is also associated with the return path for bounces. If a sender uses an empty envelope sender, as is common for delivery-status notifications, the receiver evaluates the domain provided in the SMTP HELO or EHLO command instead.

A simplified SMTP exchange looks like this:

EHLO smtp.sender.example
MAIL FROM:<bounces@mailer.example>
RCPT TO:<recipient@example.net>
DATA
From: Product Team <news@example.com>
Subject: Your weekly update

In this example, SPF checks whether the connecting server is allowed to send for mailer.example, not whether it is allowed to use example.com in the visible From: header. That distinction is central to both SPF troubleshooting and DMARC alignment.

SPF is defined in RFC 7208. It allows a domain to authorize sending infrastructure by IP address, by hostnames and MX records, or by referring to another domain’s SPF policy with an include mechanism. The policy is evaluated by the recipient’s mail server during message acceptance, before the recipient sees the message in an inbox.

Why SPF email authentication matters for deliverability

SPF is not an inbox-placement guarantee. A passing SPF result does not override poor sender reputation, high complaint rates, suspicious content, weak list quality, or a history of low engagement. But SPF is foundational: it gives mailbox providers an authenticated signal about whether the server that sent the message was authorized by the domain used in the SMTP transaction.

Without SPF, a receiving system has less evidence that a message claiming to come from a domain actually originated with infrastructure the domain owner controls. That gap makes spoofing easier and weakens a sender’s overall authentication posture.

SPF supports, but does not replace, DKIM and DMARC

SPF is one of the three commonly discussed email authentication layers:

• SPF validates the sending server against the envelope-sender or HELO domain.
• DKIM adds a cryptographic signature to selected message content and headers.
• DMARC evaluates whether SPF or DKIM passed and whether the passing domain aligns with the visible From: domain.

This division matters because SPF alone cannot prove that the human-visible From: domain is legitimate. A message can have an SPF pass for mailer.example while displaying From: billing@example.com. That is technically valid SPF, but it may not satisfy DMARC for example.com unless mailer.example and example.com are aligned under the domain’s DMARC policy.

For campaign and transactional senders, this means a correctly configured SPF record should be treated as one part of a coordinated authentication setup. Use SPF to authorize the infrastructure that sends your envelope mail, DKIM to sign your messages, and DMARC to connect authenticated identifiers to the domain recipients see.

SPF can affect spam filtering and delivery decisions

Mailbox providers use many signals when making delivery decisions. Authentication status is one of them. A failed or broken SPF check can make a legitimate message look less trustworthy, particularly when combined with missing DKIM, an unaligned envelope sender, a new sending domain, or weak reputation signals.

Google’s sender guidance states that senders to personal Gmail accounts need SPF or DKIM, while bulk senders must set up SPF, DKIM, and DMARC. That does not mean SPF alone earns inbox placement. It does mean email authentication is expected infrastructure, not an optional optimization.

For a developer sending password resets, receipts, product alerts, and lifecycle campaigns, SPF failures can create several practical problems:

1. Legitimate mail may be filtered more aggressively. A receiver sees a mismatch between the sending host and the domain’s published authorization.
2. DMARC may fail if SPF is the only aligned authentication method. If DKIM is missing or misaligned, an SPF issue can become a visible DMARC failure.
3. Spoofing protection is weaker. An overly broad SPF policy can authorize systems that should not be able to send on your behalf.
4. Troubleshooting becomes slower. When several vendors send mail for the same domain, an incomplete record can cause intermittent failures that affect only some message streams.

How an SPF check works step by step

An SPF evaluation starts when a receiving mail server accepts an SMTP connection. The receiver knows the IP address of the system that connected to it, and it also sees the domain used in MAIL FROM or, for a null envelope sender, HELO/EHLO.

The receiver then queries DNS for a TXT record at that domain. If it finds a valid SPF record, it evaluates the mechanisms in order from left to right until it finds a match or encounters an error.

Consider this record:

v=spf1 ip4:198.51.100.24 include:spf.email-service.example -all

Here is how a receiver processes it:

1. v=spf1 identifies the record as an SPF version 1 policy. It must be first.
2. ip4:198.51.100.24 authorizes that single IPv4 address.
3. include:spf.email-service.example asks the receiver to evaluate the referenced domain’s SPF policy. If that referenced policy produces a pass, this mechanism matches.
4. -all matches every remaining sender that did not match an earlier mechanism and produces an SPF fail result.

If the connecting server is 198.51.100.24, it matches the first mechanism and SPF passes. If it belongs to the infrastructure authorized by spf.email-service.example, the include can match and SPF passes. If it is neither, it reaches -all and SPF fails.

SPF checks the sending IP, not a displayed name

A common misunderstanding is that SPF validates the address a recipient sees in the email client. It does not. SPF answers a narrower question:

Was the IP address that delivered this message authorized by the SMTP envelope domain being checked?

That narrow scope is still valuable. SMTP was designed in an era when any sender could often declare a return-path domain without proving authorization. SPF gives domain owners a way to publish an authorization policy that recipients can query independently.

But because the visible From: address is separate from the SMTP envelope sender, SPF needs DMARC to provide brand-level alignment. A sender that cares about phishing resistance should not stop at an SPF pass.

SPF results you may see

Mail systems can return several SPF outcomes. The most important are:

A recipient provider decides how much weight to give each result. SPF itself produces an authentication outcome; it does not force every receiver to reject, spam-folder, or accept the message.

SPF record syntax explained

An SPF record is published as a DNS TXT record. A basic policy has this form:

v=spf1 mechanism mechanism qualifier-all

For example:

v=spf1 ip4:203.0.113.17 include:spf.transactional.example -all

The record is a space-separated sequence of terms. Most terms are mechanisms, and each mechanism can have an optional qualifier. Mechanisms identify a set of sending hosts; qualifiers define the result if the mechanism matches.

Common SPF mechanisms

The following mechanisms are the ones most senders encounter in production records:

• ip4: authorizes a specific IPv4 address or CIDR range, such as ip4:203.0.113.17 or ip4:203.0.113.0/24.
• ip6: authorizes an IPv6 address or range, such as ip6:2001:db8:1234::/48.
• include: delegates authorization to another domain’s SPF policy. For example, include:spf.provider.example authorizes senders that pass the provider’s policy.
• a authorizes the IP addresses in the A or AAAA records for the current domain, or for a domain supplied after a colon.
• mx authorizes the IP addresses associated with the domain’s MX hosts. It is usually a poor substitute for explicitly identifying outbound senders because inbound MX systems and outbound senders are often different.
• exists: performs a DNS existence test and is generally an advanced mechanism rather than a default choice for ordinary application mail.
• all matches every sender. It should appear at the end because it is a catch-all mechanism.

SPF also defines the ptr mechanism, but RFC 7208 strongly discourages its use because of its performance and reliability characteristics. Modern sender configurations should normally use explicit IP mechanisms or vendor-provided include values instead.

SPF qualifiers: +, -, ~, and ?

A qualifier appears immediately before a mechanism. When omitted, the qualifier is +, meaning pass if that mechanism matches.

The endings below are common:

-all

This says unauthorized sources should receive an SPF fail result.

~all

This says unauthorized sources should receive an SPF softfail result.

?all

This says the domain makes a neutral assertion for all unmatched sources.

The right ending depends on whether you have a complete inventory of authorized mail sources. Moving to -all before you have accounted for every legitimate sender can cause avoidable authentication failures. Leaving ~all forever, however, can preserve ambiguity and hide configuration gaps. The responsible approach is to inventory your sources, test each sending path, monitor results, and then choose the policy that reflects your actual authorization boundary.

SPF examples for real sending setups

The correct SPF record is not a generic template. It depends on every system that sends with your envelope-sender domain: company mailboxes, application servers, transactional email providers, marketing platforms, support tools, CRM workflows, billing products, and hosted forms.

One fixed application server

If a single application server with a stable IP sends all envelope mail for example.com, the record could look like this:

v=spf1 ip4:203.0.113.17 -all

This is simple and easy to audit. It works only if the server’s IP address is stable and the server is genuinely the sole sender for that domain.

A provider plus a company mail platform

Many organizations need both a business mailbox provider and an email API provider. The policy might resemble this pattern:

v=spf1 include:provider-one.example include:provider-two.example -all

The exact include domains must come from each provider’s current documentation. Do not guess them, copy them from an old blog post, or replace them with a visible sending hostname. An SPF include is a precise DNS reference, and one character wrong can authorize nobody or create a permanent error.

If you are connecting application mail through an API or SMTP relay, use the provider’s verified sending-domain instructions and test the actual return-path domain. The implementation details for a delivery platform should be checked against its current email API setup guides, because the required DNS entries and envelope-sender behavior can differ by configuration.

Separate subdomains for separate mail streams

A cleaner pattern is to separate mail streams by subdomain. For example:

From: Acme Receipts <receipts@acme.example>
Return-Path: <bounce@tx.acme.example>

Then tx.acme.example can publish an SPF policy solely for the transactional provider, while a marketing subdomain can authorize a different platform. This reduces the number of vendors in one record, narrows authorization, and makes operational ownership clearer.

Example:

TXT tx.acme.example: v=spf1 include:spf.transactional.example -all
TXT marketing.acme.example: v=spf1 include:spf.marketing.example -all

The parent domain may still have its own SPF record for employee mail. Each domain or subdomain is evaluated independently according to the envelope domain used by the message.

SPF is not a rate or score

SPF is sometimes discussed alongside bounce rate, complaint rate, open rate, or delivery rate. It is different from all of those. SPF is not a percentage calculated over a campaign; it is a per-message authentication evaluation.

A campaign may have 99.8% SPF passes, but that percentage is an aggregate operational metric created by your reporting system, not the SPF protocol itself. Likewise, a single message either receives a particular SPF result at a given receiver or it does not. Different recipients can occasionally observe different outcomes if DNS availability, message routing, or envelope identities differ.

A numeric SPF lookup-budget example

Although SPF is not a rate, it does have an important numeric limit: an SPF evaluation must not trigger more than 10 DNS-querying terms. The terms that count include include, a, mx, ptr, exists, and the redirect modifier. Direct ip4 and ip6 mechanisms do not require SPF DNS lookups in the same way.

Suppose your record is:

v=spf1 include:mail.example include:billing.example include:marketing.example include:support.example include:crm.example include:forms.example include:alerts.example include:product.example include:legacy.example include:regional.example include:events.example -all

That record contains 11 include mechanisms. Even before considering whether any referenced provider policy performs further lookups, it already exceeds SPF’s 10-lookup processing limit. A receiver can return permerror, which means the policy could not be evaluated correctly.

Now consider a record with only three visible includes:

v=spf1 include:mail.example include:marketing.example include:transactional.example -all

It may still exceed the limit if those included records themselves use several include, a, or mx mechanisms. This is why counting only the terms in your top-level DNS record is not enough. You must account for the entire evaluated SPF tree.

Common SPF problems and what causes them

SPF failures are often caused by configuration drift, not by a single obvious typo. A company adds a new sending tool, changes outbound infrastructure, launches a contact form, or enables email from a CRM without revisiting its DNS policy. The email starts going out, but the SPF record remains unaware of it.

Missing an authorized sender

This is the most common failure mode. The sender’s IP address or provider include is absent from the SPF policy, so messages from that source reach -all or ~all.

Typical examples include:

• A website sends form notifications directly from its hosting server.
• A billing tool sends receipts using your domain.
• A customer-support platform sends ticket updates with a custom return path.
• A new marketing provider is configured by a separate team.
• An engineering team adds a backup SMTP relay during an incident.

The fix is not automatically to add broad mechanisms like a, mx, or +all. First identify the actual envelope-sender domain and outbound IP or provider authorization domain. Then add the narrowest correct authorization method, test it, and document which system owns it.

Multiple SPF records at the same domain

A domain must publish one SPF policy record. A frequent mistake is adding a new TXT record every time a new vendor needs authorization:

TXT example.com: v=spf1 include:vendor-a.example -all
TXT example.com: v=spf1 include:vendor-b.example -all

This does not create a combined policy. It can result in SPF permerror because receivers find multiple SPF records.

The correct approach is to merge authorized mechanisms into one record:

v=spf1 include:vendor-a.example include:vendor-b.example -all

Be careful when editing DNS interfaces that display TXT values in separate rows or split long values for presentation. The goal is one logical SPF record beginning with v=spf1, not several independent SPF policies.

Too many DNS lookups

Vendor-heavy organizations often hit the 10-lookup limit. The problem is especially common when several SaaS products each instruct customers to add an include mechanism and some of those providers rely on further nested includes.

To fix it, start with an inventory rather than immediately flattening the record. Remove retired tools, stop authorizing sources that no longer send mail, move unrelated streams to their own subdomains, and ask providers whether they offer a lower-lookup authorization design. Manual SPF flattening can reduce lookup count, but it also creates a maintenance obligation: if a provider changes its sending IP ranges, a flattened record can become stale.

Wrong domain in the SPF record

SPF is checked against the envelope sender, not necessarily the visible From: address. You may publish a perfect record at example.com while your provider sends mail with bounce@em.example.com as the envelope sender. In that case, the receiving system queries em.example.com, not the parent-domain record you were inspecting.

This is a common reason a team says, “Our SPF record is correct, but headers still show SPF fail.” Inspect the actual Return-Path and Authentication-Results values in a delivered message before changing DNS.

Incorrect use of include

In SPF, include:domain.example does not simply paste another record’s terms into yours. The include mechanism matches only when the referenced policy evaluates to SPF pass. If the referenced domain returns fail, softfail, neutral, or an error, the include itself does not authorize the sender in the way many people assume.

Use only the exact include value supplied by the service you are authorizing. Do not use include for a domain merely because it hosts your website, receives your mail, or appears in an email header.

DNS syntax or publication errors

An SPF record can fail because of invalid syntax, accidental punctuation, a malformed IP range, an extra v=spf1, or a DNS-hosting interface that has inserted unintended characters. It can also fail because a long TXT value has been entered incorrectly.

Start with a DNS lookup, then validate the complete returned value—not just the record you intended to save in the dashboard. A published policy is what receivers evaluate.

How to diagnose an SPF failure

The fastest way to troubleshoot SPF is to start with a real message that failed and work outward from the recipient’s authentication result. Do not begin by editing DNS based only on the visible From: address.

Read the authentication results header

Receiving systems commonly add an Authentication-Results header describing the checks they performed. The format is standardized for reporting message authentication outcomes.

A simplified example might look like this:

Authentication-Results: mx.recipient.example;
    spf=fail smtp.mailfrom=mail.example;
    dkim=pass header.d=mail.example;
    dmarc=pass header.from=mail.example

This example says SPF failed for the SMTP envelope domain mail.example, while DKIM passed for mail.example and DMARC passed for the visible From: domain. The message may still satisfy DMARC because an aligned DKIM pass is sufficient; SPF failure remains useful evidence that the sending source or policy should be investigated.

When reading a header, capture these details:

1. The SPF result: pass, fail, softfail, none, temperror, or permerror.
2. The checked identity, often shown as smtp.mailfrom= or sometimes smtp.helo=.
3. The recipient’s reported sending IP, if included.
4. The DKIM signing domain shown as header.d=.
5. The visible From: domain used for DMARC alignment.

Build a sender inventory

List every system that can send mail using your domain or a subdomain. Include tools that engineers and marketers may not think of as “email providers,” such as cloud-hosted applications, alerting systems, form handlers, support desks, invoicing systems, and test environments.

For each source, record:

• Envelope-sender or return-path domain.
• Visible From: domain.
• Sending method, such as API, SMTP relay, direct MTA, or cloud function.
• Authorized IP range or vendor-provided SPF include.
• DKIM signing domain.
• Team owner and business purpose.

This inventory makes SPF changes safer. It also reveals when one root-domain record has accumulated too many unrelated senders and should be split into purpose-specific subdomains.

Check the entire evaluated policy chain

If the header says permerror, inspect the policy structure. Look for multiple SPF records, malformed mechanisms, excess lookups, or an unavailable referenced domain. If it says fail or softfail, identify the connection IP and determine which intended mechanism should have matched but did not.

For an include-based provider, verify both that the include exists in your record and that the provider’s documented mail stream is actually using the envelope domain you believe it is. A vendor can have separate requirements for shared sending, custom return paths, and dedicated IP configurations.

How to fix and improve SPF safely

An SPF change is an authorization change. Treat it like a production security and deliverability change rather than a quick DNS copy-and-paste task.

Use a deliberate remediation process

A practical sequence is:

1. Collect evidence from failed messages. Record the SPF result, checked domain, sending IP, and message stream.
2. Identify the actual sender. Confirm whether the mail originated with your application, a mailbox provider, a vendor, or an unauthorized system.
3. Decide whether the sender should be authorized. A failing source is sometimes a configuration bug or spoofing attempt, not a sender to add.
4. Add the narrowest valid authorization. Prefer a provider’s documented include or a specific managed IP range over broad authorization.
5. Merge, do not duplicate, SPF records. Keep one logical v=spf1 policy per domain.
6. Count DNS-querying terms across nested includes. Stay within the SPF lookup limit.
7. Send tests through each legitimate stream. Review recipient-side headers for SPF, DKIM, and DMARC results.
8. Monitor after DNS propagation. Confirm that production traffic, not only a single test, is authenticating as expected.

Prefer subdomain separation over a sprawling root record

Subdomains are one of the cleanest ways to improve SPF maintainability. For example, use a transaction-specific return-path domain for application email and a marketing-specific return-path domain for campaigns. This allows each stream to have its own authorization policy and reduces the risk that a change for one vendor breaks another.

It also improves incident response. If a marketing platform is misconfigured, you can remediate the affected subdomain without changing the authorization policy for password resets or receipts.

Do not use +all

A record ending in +all effectively authorizes every host on the internet. It removes the authorization value SPF is supposed to provide. It may seem to make an SPF failure disappear, but it does so by declaring that unauthorized senders are authorized.

Likewise, avoid adding broad a or mx mechanisms merely because they make a test pass. Those mechanisms may authorize infrastructure that was never intended to send outbound email. Explicit IP ranges, purpose-built subdomains, and provider-documented includes are usually easier to audit.

Coordinate SPF with DKIM and DMARC

A robust setup assumes SPF can break in some legitimate routing scenarios. Email forwarding is a classic example: a forwarder relays a message from a new IP address, but the original envelope-sender domain may not authorize that forwarding IP. SPF can therefore fail even when the original message was legitimate.

Forwarding services may use Sender Rewriting Scheme, or SRS, to rewrite the envelope sender and mitigate this issue. DKIM can also survive ordinary forwarding because it validates a signature on message content rather than the forwarding IP, though message modifications by mailing lists can break signatures. DMARC is designed to evaluate aligned SPF or aligned DKIM, which is why deploying both authentication methods is more resilient than relying on SPF alone.

SPF limitations every sender should understand

SPF is important, but it has limits. Knowing them prevents teams from treating a pass result as proof that every part of an email is trustworthy.

First, SPF does not directly authenticate the display name or visible From: address. A message can pass SPF for an unrelated envelope domain. DMARC alignment addresses that gap when the SPF-authenticated domain aligns with the From: domain.

Second, SPF is sensitive to IP-based routing. Forwarding can cause failure because the forwarder’s IP is not listed in the original sender’s policy. This is a protocol limitation, not necessarily evidence that the original message was forged.

Third, SPF records can become fragile as a business adds vendors. DNS lookup limits and nested provider records mean authorization design needs active maintenance.

Fourth, SPF does not manage reputation. A correctly authenticated sender can still be filtered for poor engagement, spam complaints, suspicious content, sudden volume spikes, or sending to invalid addresses. Authentication establishes identity-related evidence; it does not make unwanted mail wanted.

SPF email authentication checklist

Use this checklist when launching a new mail stream or investigating delivery problems:

• Publish exactly one logical SPF TXT policy for each envelope-sender domain.
• Start the record with v=spf1.
• Inventory every approved sending source before adding mechanisms.
• Use exact vendor-provided include values or explicit, controlled IP ranges.
• Keep all at the end of the policy.
• Avoid +all, unnecessary a and mx mechanisms, and the discouraged ptr mechanism.
• Count DNS-querying terms across nested includes and remain under the 10-lookup limit.
• Check real recipient headers for spf=, dkim=, and dmarc= results.
• Verify the smtp.mailfrom domain, not only the visible From: address.
• Separate transactional, marketing, and employee mail onto appropriate subdomains when complexity grows.
• Pair SPF with aligned DKIM and a monitored DMARC policy.
• Revisit the record whenever you add, remove, or reconfigure an email vendor.

Conclusion

SPF email authentication is the DNS policy that tells receiving mail systems which servers may send mail for an envelope-sender domain. Its job is straightforward, but production configurations can become complex when multiple providers, subdomains, forwarding paths, and nested DNS references are involved.

The reliable approach is to understand what SPF actually evaluates, authorize only known senders, keep one valid policy per domain, stay within DNS lookup limits, and test against real message headers. Most importantly, treat SPF as part of an authentication system with DKIM and DMARC—not as a standalone deliverability switch.

FAQ

What is an SPF record in email?

An SPF record is a DNS TXT record beginning with v=spf1. It lists the IP addresses, hosts, or external policies authorized to send email for a domain used in the SMTP envelope sender or HELO/EHLO identity.

Does SPF check the visible From address?

No. SPF normally checks the SMTP MAIL FROM domain, often visible as the return-path domain. DMARC is the protocol that evaluates whether an SPF pass is aligned with the visible From: domain.

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

Use -all when you have a complete, tested inventory of legitimate senders and want unmatched sources to produce SPF fail. Use ~all when you are still validating senders or intentionally want unmatched sources to receive softfail. Neither ending automatically dictates rejection; recipients make their own delivery decisions.

Why does SPF return permerror?

Common causes include publishing more than one SPF record for the same domain, invalid syntax, or exceeding the 10 DNS-querying-term limit through direct and nested includes. Inspect the complete published DNS record and every referenced SPF policy.

Can SPF pass while DMARC fails?

Yes. SPF can pass for an envelope domain that does not align with the visible From: domain. DMARC requires an aligned SPF pass or an aligned DKIM pass, depending on the domain’s policy and alignment settings.