What Is SPF and Why Is It Important for Email?

SPF, short for Sender Policy Framework, is an email authentication standard that helps receiving mail servers identify whether a message was sent from infrastructure authorized by the domain owner. Understanding what is SPF matters because a correct SPF record reduces domain spoofing risk, supports deliverability, and is now a practical baseline for sending transactional or campaign email.

What is SPF?

SPF stands for Sender Policy Framework. It is a policy published in DNS that lists the mail servers, IP addresses, and external services allowed to send email using a domain in the SMTP envelope.

In simple terms, SPF lets the owner of example.com publish a statement such as: “Mail claiming to be sent from example.com may originate from these systems.” When a receiving mail server gets a message, it compares the connecting server's IP address with that statement.

SPF does not encrypt email, scan attachments, or prove that the visible sender name is trustworthy. It is an authorization check for the infrastructure that delivered the message. It answers a narrow but valuable question:

Is the server that sent this message authorized to use this domain in the SMTP transaction?

The standard is defined in RFC 7208. It works through a DNS TXT record beginning with v=spf1, followed by mechanisms that describe approved senders and an ending policy such as -all.

A minimal SPF record that says no server is authorized to send mail for a domain looks like this:

example.com. IN TXT "v=spf1 -all"

That record is appropriate only for a domain that never sends email. For a normal sending domain, the record will authorize one or more sources.

For example, a company that sends from its own IPv4 address might publish:

example.com. IN TXT "v=spf1 ip4:198.51.100.24 -all"

That means mail sent with an envelope sender at example.com should pass SPF only when it comes from 198.51.100.24.

Why SPF is important

Email was designed in an era when the internet was smaller and sender identity was largely based on trust. SMTP allows a sending system to provide an envelope sender with the MAIL FROM command and a visible sender in the From: header. Without authentication, a malicious system can attempt to use another organization's domain in one or both places.

SPF adds an externally visible authorization layer. A receiving service can query the sender domain's DNS record and decide whether the connecting IP is on the approved list.

SPF helps reduce domain spoofing

A criminal can write an email that appears to come from billing@example.com, even if they do not control example.com. SPF makes that impersonation harder when the attacker sends through an unauthorized mail server and uses example.com as the envelope sender domain.

That does not mean SPF stops every phishing message. Attackers can register lookalike domains, compromise legitimate accounts, use unrelated reply addresses, or send messages that pass SPF for a domain they control. SPF is a control, not a complete anti-phishing strategy.

Still, SPF gives receiving systems a useful signal. A message that claims an envelope sender of example.com but arrives from a server not authorized by example.com has failed an important identity check.

SPF supports inbox placement and deliverability

Mailbox providers evaluate many signals before deciding whether to inbox, spam-folder, defer, or reject a message. Authentication is one of those signals. A missing, malformed, or failing SPF setup can weaken trust in otherwise legitimate mail.

Major mailbox providers also set explicit sender requirements. Gmail's sender guidelines require all senders to personal Gmail accounts to have SPF or DKIM configured. Senders that send more than 5,000 messages per day to Gmail accounts must set up SPF, DKIM, and DMARC.

That does not mean SPF passing guarantees inbox placement. Content, complaint rate, recipient engagement, IP reputation, domain reputation, list quality, and message formatting still matter. But a valid SPF implementation removes a preventable deliverability problem and is foundational to a credible authentication posture.

SPF protects operational email as well as marketing mail

SPF is just as relevant to password-reset links, login alerts, receipts, invoices, account verification messages, support replies, and monitoring alerts as it is to newsletters. Transactional messages often contain sensitive actions or account information, which makes impersonation especially damaging.

A developer may send these messages through an email API, an SMTP relay, a cloud application, a help desk, an e-commerce platform, or an identity provider. Each approved source must be accounted for in the domain's SPF policy.

SPF creates an inventory of authorized senders

A healthy SPF record is also an operational record of who is allowed to send email for a domain. Maintaining it forces teams to identify forgotten tools, retired vendors, test environments, and shadow IT systems that might otherwise continue sending unchecked.

This inventory is useful during incident response. If a service is no longer approved, removing its SPF authorization limits its ability to send mail using your envelope domain. It is not a substitute for revoking credentials or disabling the vendor account, but it is a meaningful layer of defense.

How an SPF check works

SPF is evaluated during SMTP delivery, before the recipient typically sees the message. The receiver has several inputs:

1. The IP address of the server connecting to deliver the message.
2. The domain used in the SMTP MAIL FROM command, also called the envelope sender or return-path domain.
3. In some cases, the domain introduced in the SMTP HELO or EHLO command, particularly when the envelope sender is empty.
4. The DNS TXT record published by the domain being evaluated.

Consider this simplified SMTP transaction:

EHLO mailer.provider.example
MAIL FROM:<bounces@notify.example.com>
RCPT TO:<person@gmail.com>
DATA
From: Acme Alerts <alerts@example.com>
To: person@gmail.com
Subject: Reset your password
...

The receiving server sees a connection from a particular IP address. It then checks the SPF policy for notify.example.com, because that is the domain in MAIL FROM:<bounces@notify.example.com>.

This distinction is critical: SPF normally evaluates the envelope sender domain, not necessarily the visible From: domain.

In the example, the person receiving the message sees alerts@example.com, but SPF may be evaluated against notify.example.com. That can be perfectly valid. It becomes especially important once DMARC is involved, because DMARC checks whether the authenticated SPF domain is aligned with the visible From: domain.

SPF evaluation outcomes

An SPF evaluator can return several results:

• pass: The connecting IP address is authorized by the policy.
• fail: The policy explicitly says the IP is not authorized.
• softfail: The IP is probably not authorized, but the policy is not an absolute rejection statement.
• neutral: The domain does not assert a policy either way.
• none: No SPF record was found for the evaluated domain.
• temperror: A temporary issue, often DNS-related, prevented evaluation.
• permerror: The record has a permanent problem, such as invalid syntax, multiple SPF records, or too many DNS lookups.

Receiving systems decide how much weight to give each result. A fail result can contribute to spam placement or rejection. A softfail result is not a reliable “good enough” state; it still tells the receiver the message is not clearly authorized.

If a receiver rejects a message specifically for an SPF violation, one possible SMTP response is:

550 5.7.23 SPF validation failed

Microsoft documents 550 5.7.23 as an SPF-related non-delivery error. Other providers may return different enhanced status codes or use SPF failure alongside other reputation and policy signals. Do not build monitoring around one exact bounce string.

SPF itself is DNS and SMTP based. There is no standard HTTP status code for an SPF pass or failure. If an email provider's REST API returns 200 OK, 202 Accepted, or a provider-specific HTTP error, that describes whether the provider accepted your API request—not whether Gmail, Outlook, or another receiver will later pass SPF or deliver the message.

SPF records: syntax and real examples

SPF policies are published as DNS TXT records at the sending domain. The record is a sequence of space-separated terms.

A common record looks like this:

example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.email-service.example -all"

The key elements are:

• v=spf1: Declares that this is an SPF version 1 record. It must come first.
• include:_spf.google.com: Delegates authorization to another domain's SPF record.
• include:spf.email-service.example: Authorizes the service represented by that SPF record.
• -all: States that servers not matched by earlier mechanisms should fail.

DNS control panels vary. One provider may ask for a Host or Name value of @; another may use a blank root-domain field; another may show the fully qualified domain. The essential DNS record type is TXT, and the value must begin with v=spf1.

Common SPF mechanisms

SPF mechanisms define ways a sender can match the policy.

For most application teams, ip4, ip6, and include are the practical mechanisms seen most often. The a and mx mechanisms can work, but they can be less explicit and may introduce lookup costs or unexpected authorization when infrastructure changes.

The ptr mechanism is not recommended. It is slow, operationally fragile, and discouraged by the SPF specification.

Qualifiers: +, -, ~, and ?

Each mechanism can have a qualifier that controls the outcome if that mechanism matches:

These examples show the difference:

"v=spf1 ip4:198.51.100.24 -all"

A message from the listed IP passes. All other sources fail.

"v=spf1 ip4:198.51.100.24 ~all"

A message from the listed IP passes. Other sources softfail.

During an initial migration, ~all may provide a short observation period while you uncover every valid sender. However, it should not become an indefinite substitute for maintaining the record. Once the sending inventory is correct, -all gives a clearer policy signal.

Never use +all for a production sending domain:

"v=spf1 +all"

It authorizes every IP address on the internet and defeats the purpose of SPF.

SPF and the visible From address are not the same thing

One of the most common SPF misunderstandings is assuming that SPF authenticates the address people see in their email client. It does not necessarily do that.

The visible address is usually in the RFC 5322 From: header:

From: Product Team <updates@example.com>

The SMTP envelope sender might instead be:

Return-Path: <bounce-8271@bounces.example-mail.example>

A receiver can evaluate SPF for bounces.example-mail.example and report spf=pass, even though the visible address is at example.com. That SPF pass means the delivery service was authorized by the envelope sender domain. It does not, by itself, establish a relationship to example.com.

This is why SPF alone does not adequately protect the visible From identity. DMARC fills the gap by requiring alignment between the visible From domain and either the domain authenticated by SPF or the domain authenticated by DKIM.

SPF alignment under DMARC

For SPF to satisfy DMARC, the SPF-authenticated envelope domain must align with the visible From: domain. Alignment can be strict or relaxed.

With relaxed alignment, these domains can align:

From: receipts@example.com
MAIL FROM: bounce@notify.example.com

They share the same organizational domain, example.com. With strict alignment, the domains must match exactly, so notify.example.com would not align with example.com.

This has a practical implication for email API and SMTP relay users. If your provider uses its own return-path domain by default, SPF can pass but fail DMARC alignment for your visible From domain. A properly configured custom return-path or sending subdomain can make SPF alignment possible.

DKIM can also satisfy DMARC alignment, and it often survives forwarding better than SPF. The reliable approach is to configure all three: SPF, DKIM, and DMARC.

SPF, DKIM, and DMARC: different jobs

These standards are often discussed together, but they do different things.

SPF authorizes sending infrastructure

SPF asks whether the delivery server is allowed to use a domain in the SMTP envelope. Its dependency on the connecting server is why it can break when mail is forwarded through an intermediary.

DKIM signs message content and selected headers

DKIM adds a cryptographic signature to a message. The receiver retrieves the public key from DNS and verifies that signed portions of the message have not been altered after signing.

DKIM is useful for identity and integrity. It also tends to handle forwarding better than SPF, provided the forwarding system does not modify signed content or headers in ways that invalidate the signature.

DMARC applies alignment and policy

DMARC uses the visible From: domain as its anchor. It checks whether SPF or DKIM passed and aligned with that visible domain. It also lets domain owners publish instructions for failures, such as monitoring only (p=none), quarantine (p=quarantine), or rejection (p=reject).

A straightforward way to remember the relationship is:

• SPF: “Was this server allowed to send?”
• DKIM: “Was this message signed by a domain, and did the signed content survive?”
• DMARC: “Does an authenticated domain match the visible From domain, and what should receivers do if it does not?”

No single protocol is sufficient by itself. SPF without DMARC can pass for an unrelated envelope domain. DKIM without DMARC may sign a domain unrelated to the visible From address. DMARC creates the domain-alignment rule that turns the underlying checks into stronger anti-impersonation protection.

How to create an SPF record safely

Do not begin by copying every SPF snippet you can find from vendors. Start with a complete inventory of systems that actually send mail using the domain or its subdomains.

Step 1: List every legitimate sender

Include more than your primary mailbox provider. Common senders include:

• Corporate mailbox systems.
• Transactional email APIs and SMTP relays.
• Marketing platforms.
• Customer-support and ticketing systems.
• CRM and sales-engagement tools.
• E-commerce receipt systems.
• Billing, invoicing, and subscription platforms.
• Identity providers that send password resets or verification codes.
• Website contact forms and server-side applications.
• Monitoring, alerting, and incident-management tools.
• Legacy servers, staging environments, and internal applications.

For each sender, identify the envelope sender domain it uses. A tool that displays From: support@example.com may actually use MAIL FROM:<bounces@provider.example>. In that case, its SPF record may not need to be included in example.com, though its DKIM and DMARC alignment still need review.

Step 2: Prefer dedicated sending subdomains

Separate mail streams where practical. For example:

• example.com for employee and core business correspondence.
• notify.example.com for product notifications and transactional mail.
• news.example.com for newsletters and promotional campaigns.
• support.example.com for customer-service systems.

Subdomain separation makes SPF records smaller, reduces coupling between vendors, and limits the blast radius of a misconfiguration. It can also help teams assign ownership and monitor reputation by stream.

For example:

notify.example.com. IN TXT "v=spf1 include:spf.transactional-provider.example -all"
news.example.com. IN TXT "v=spf1 include:spf.marketing-provider.example -all"

If a developer sends application messages through an SMTP relay or REST email API, the provider's documentation should specify the required SPF include domain, sending IP range, or custom return-path configuration. Verify that exact syntax in the provider documentation rather than guessing. For implementation details across SMTP and API-based sending, consult the email API reference and setup guides.

Step 3: Publish one SPF record per domain

A domain must have one SPF record. It may contain multiple mechanisms, but do not publish multiple TXT strings that each start with v=spf1.

Wrong:

example.com. IN TXT "v=spf1 include:spf.provider-one.example -all"
example.com. IN TXT "v=spf1 include:spf.provider-two.example -all"

Correct:

example.com. IN TXT "v=spf1 include:spf.provider-one.example include:spf.provider-two.example -all"

Multiple independent SPF records cause a permanent error because the receiver cannot know which policy is authoritative.

Step 4: Test before and after DNS changes

Use command-line DNS tools to see the record that public resolvers can retrieve:

dig TXT example.com +short

On Windows, you can use:

nslookup -type=txt example.com

Then use an SPF-aware validator. MXToolbox can retrieve and analyze SPF records, while mail-tester.com can inspect authentication on a real message sent to a test address. These tools are useful because they reveal issues that are easy to miss in a DNS control panel, including duplicate records, syntax problems, and excessive lookup depth.

You can also inspect an actual delivered message's headers. Look for an Authentication-Results: field such as:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@notify.example.com designates 198.51.100.24 as permitted sender) smtp.mailfrom=bounce@notify.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

The exact formatting differs by receiver, but the important values are the SPF result and the smtp.mailfrom domain that was evaluated.

The SPF 10-DNS-lookup limit

The most persistent SPF problem is the lookup limit. RFC 7208 requires evaluators to limit DNS-querying SPF terms to 10 during a single SPF evaluation. This is a hard protocol constraint, not a quality recommendation.

The limit exists because an SPF record can delegate to other records, which can delegate again. Without a cap, an attacker could create policies that force receivers to perform an unreasonable number of DNS queries.

The mechanisms and modifier that consume lookup budget include:

• include
• a
• mx
• ptr
• exists
• redirect

The following do not directly require a DNS lookup:

• ip4
• ip6
• all

The difficult part is that lookup counts are recursive. One visible include can expand into several DNS queries because the included provider record might contain additional include, a, or mx mechanisms.

A record that looks harmless but fails

"v=spf1 include:spf.workspace.example include:spf.crm.example include:spf.support.example include:spf.marketing.example include:spf.transactional.example ~all"

This record contains only five visible includes, but it can still exceed the limit. If two vendors themselves include several other domains, the evaluator may reach lookup number 11 and return permerror.

A permanent SPF error is not a partial pass. It means the receiver could not evaluate a valid policy. Depending on the receiver and DMARC configuration, that can lead to spam placement, failed DMARC alignment, or rejected mail.

How to avoid lookup-limit failures

The best solution is usually architectural rather than cosmetic:

1. Remove former vendors and unused includes.
2. Use separate SPF records on dedicated subdomains for separate mail streams.
3. Avoid a, mx, and especially ptr unless there is a specific reason to use them.
4. Consolidate sending platforms where it makes operational sense.
5. Audit the fully expanded record, not just the text you see at the root domain.
6. Re-test after every vendor change, because providers can alter their own SPF dependency trees.

Some teams use SPF flattening, where external includes are replaced with explicit IP ranges. This can reduce lookup count, but it creates maintenance risk: a vendor may add or retire sending IPs, leaving your flattened policy stale. If you flatten, treat it as managed configuration with regular automated updates and validation—not as a set-and-forget record.

Common SPF mistakes and how to fix them

Publishing more than one SPF record

Symptom: Validators report multiple SPF records or permerror.

Fix: Merge all authorized mechanisms into one v=spf1 TXT record for that exact domain. Do not confuse a DNS provider splitting one long TXT value into quoted chunks with publishing multiple separate SPF policies; DNS software can safely return parts of one TXT record, but there should be only one SPF policy beginning with v=spf1.

Forgetting a new sender

Symptom: Messages from one platform fail SPF while messages from other systems pass.

Fix: Identify the actual connecting infrastructure and envelope sender domain in the message headers. Add the provider's documented authorization only if it truly sends mail for that domain. Then send a fresh test message and confirm the resulting spf=pass.

Keeping ~all forever

Symptom: SPF returns softfail for unauthorized servers, but no clear enforcement posture exists.

Fix: Use softfail only as a deliberate temporary auditing state. Once you have enumerated valid senders, move to -all where appropriate. The right final policy depends on your delivery architecture, but indefinite ambiguity is rarely beneficial.

Using the wrong domain

Symptom: The root-domain SPF record appears valid, but mail still fails.

Fix: Check smtp.mailfrom in Authentication-Results and the Return-Path header. SPF may be evaluated against a sending subdomain, a custom bounce domain, or a provider-managed domain rather than the visible From domain.

Exceeding 10 lookups

Symptom: A checker reports too many DNS lookups or permerror.

Fix: Audit recursive includes, remove unused services, and split mail streams onto subdomains. Do not assume the root record's number of include terms equals the real count.

Treating SPF as a replacement for DKIM and DMARC

Symptom: SPF passes but spoofing protections or alignment still fail.

Fix: Configure DKIM signing and publish a DMARC policy. SPF should be one component of a coordinated email-authentication implementation.

SPF and forwarding: why legitimate mail can fail

Email forwarding exposes a fundamental SPF limitation. SPF evaluates the IP address of the system that actually connects to the recipient's mail server. When a recipient forwards mail, the forwarding server—not the original authorized sender—often becomes the connecting system.

For example, an application sends mail from an authorized transactional service. The recipient has configured forwarding from one mailbox to another. The forwarder relays the message onward, but it is not listed in the application's SPF record. The final recipient can see SPF fail even though the original message was legitimate.

This is one reason DKIM is essential. A valid DKIM signature can survive forwarding, and DMARC can pass through aligned DKIM even if SPF fails. Forwarding services may also use ARC, or Authenticated Received Chain, to preserve authentication context, but senders should not rely on every forwarder and receiver handling ARC in the same way.

The practical lesson is not to weaken SPF until forwarding always passes. The lesson is to deploy SPF alongside aligned DKIM and DMARC, then test your real sending paths.

A practical SPF checklist for developers and operators

Before treating SPF as complete, work through this checklist:

• Publish exactly one SPF TXT record for each sending domain or subdomain.
• Start the value with v=spf1.
• Inventory every service that sends using the domain in its SMTP envelope.
• Confirm each vendor's current documented SPF authorization syntax.
• Prefer explicit ip4, ip6, and necessary include mechanisms over broad or indirect authorization.
• Do not use +all.
• Use -all after you have validated legitimate sources; use ~all only as a purposeful transition state.
• Keep total recursive DNS-querying terms at 10 or fewer.
• Review the evaluated smtp.mailfrom domain, not only the visible From: address.
• Set up DKIM for every sending stream.
• Publish and monitor DMARC, beginning with a reporting policy if needed.
• Send a real test message and inspect Authentication-Results.
• Re-audit SPF whenever a vendor is added, removed, migrated, or reconfigured.

When troubleshooting an individual recipient address, validate the recipient independently before assuming SPF is the only issue. A syntax or mailbox problem can look like a delivery issue even when authentication passes; an email address verification tool can help separate address-quality problems from sender-configuration problems.

Conclusion: SPF is necessary infrastructure, not a one-time DNS task

SPF is a DNS-based authorization policy that tells the world which infrastructure may send mail using a domain in the SMTP envelope. It is important because it helps reduce impersonation, supports email-provider authentication requirements, and provides an important deliverability signal for transactional and campaign mail.

A good SPF record is not merely a copied vendor snippet. It is a maintained representation of your real sending architecture. That means knowing which applications send mail, understanding envelope sender domains, keeping the policy under the 10-lookup limit, and removing authorizations that no longer belong.

Most importantly, treat SPF as part of a three-part authentication system. SPF authorizes the sending server, DKIM signs the message, and DMARC applies domain alignment and policy. Together, they give recipients and mailbox providers a much stronger basis for trusting your email.

FAQ

What is SPF in email?

SPF, or Sender Policy Framework, is a DNS TXT record that identifies the IP addresses and mail services authorized to send email using a domain in the SMTP envelope. Receiving servers compare the sender's connecting IP with that record and return a result such as pass, fail, softfail, or permerror.

Does SPF protect the visible From address?

Not by itself. SPF normally checks the SMTP MAIL FROM or envelope sender domain, which can differ from the visible From: header. DMARC is needed to require alignment between the visible From domain and an SPF- or DKIM-authenticated domain.

What should an SPF record look like?

A basic record might be:

"v=spf1 ip4:198.51.100.24 -all"

A record for a third-party sender might use an include mechanism:

"v=spf1 include:spf.provider.example -all"

Use the exact include value supplied in your provider's current documentation.

Can I have multiple SPF records?

No. A domain should publish one SPF policy. If multiple vendors need authorization, combine their mechanisms into a single TXT record that starts with one v=spf1 declaration.

Why does my SPF record show permerror?

Common causes are multiple SPF records, invalid syntax, recursive include loops, too many DNS lookups, or DNS records that cannot be resolved. The 10-DNS-lookup limit is a frequent cause, especially for domains that authorize many SaaS email platforms through include mechanisms.