What Is SPF Email? A 2026 Guide to Fixing Your Record

Do not index

An SPF record is a DNS TXT record that lists which mail servers are allowed to send email for your domain, helping receiving servers reduce spoofing and make better inbox placement decisions. It's also still missing on a surprising share of the web: a 2024 analysis of the top 1 million domains found that 39% lack an SPF record entirely (DMARC Checker).

If you're looking up what is SPF email, you're probably not doing it out of curiosity. You're doing it because emails are landing in spam, reply rates dropped, onboarding emails aren't reaching users, or a deliverability tool flagged SPF errors and now everything feels more technical than it should.

SPF matters because mailbox providers need signals they can trust. If your domain doesn't clearly publish who is allowed to send mail on its behalf, your messages are easier to doubt and your domain is easier to spoof. That hurts security, but it also hurts revenue. Sales emails get ignored, product emails disappear, and marketing performance suffers long before many teams realize the root cause is sitting in DNS.

Table of Contents

What Is an SPF Record and Why It Impacts Your Inbox Placement Why SPF matters in business terms What an SPF record actually does How SPF Authentication Technically Works The SPF check in plain English What the receiver evaluates Deconstructing an SPF Record Syntax and Examples The parts that matter Valid and risky examples SPF vs DKIM and DMARC Why You Need All Three What SPF does not cover How the three work together Common SPF Mistakes That Send Your Emails to Spam The failures I see most often What to do instead How to Check and Fix Your SPF Record A Step-by-Step Guide A practical SPF workflow What good results look like Frequently Asked Questions About SPF Can I have more than one SPF record for my domain What is the difference between softfail and hardfail How long does it take for SPF changes to work Does SPF stop phishing by itself What should I publish if my domain does not send email Why do emails still go to spam if SPF passes

What Is an SPF Record and Why It Impacts Your Inbox Placement

When your emails go to spam, the issue usually isn't one dramatic failure. It's a stack of trust signals that don't quite add up. SPF is one of the first signals mailbox providers check when deciding whether to trust mail from your domain.

SPF, or Sender Policy Framework, is an email authentication method that lets a domain publish which mail servers are authorized to send on its behalf. Google's documentation explains that receiving servers use it to verify whether messages that appear to come from the domain were sent by authorized servers, which helps reduce spoofing and improve deliverability (Google Workspace Admin guidance on SPF).

Why SPF matters in business terms

SPF isn't just an anti-spam acronym for IT teams.

It affects whether your outbound sales messages look legitimate, whether your newsletter has a better chance of reaching the inbox, and whether attackers can impersonate your domain with less resistance. If your team is already working on sender trust, this matters alongside broader domain health work like improving email reputation.

A simple way to think about SPF is this: you are publishing a public allowlist for email sending. If a receiving server sees a message from your domain coming from a source that isn't on that list, trust drops.

For a concise outside definition, Breaker's SPF definition is a useful quick reference for non-technical readers.

What an SPF record actually does

An SPF record lives in DNS as a TXT record. It tells receiving systems which sending sources are permitted for the domain that handles the SMTP envelope sender.

That matters because mailbox providers don't reward ambiguity. A domain with no SPF, stale SPF, or incomplete SPF creates doubt around legitimate mail flow. A domain with clean, current authentication gives providers a clearer reason to trust what arrives.

A few practical outcomes follow from that:

Better sender trust: Receivers can compare your claimed sending source against your published policy.

Lower spoofing exposure: Attackers have a harder time using your domain without tripping authentication checks.

Fewer false assumptions: Teams stop thinking "we have SPF" when what they really have is an outdated record that no longer matches the tools they use.

How SPF Authentication Technically Works

SPF works like a security desk checking a guest list. The receiving mail server doesn't care what your internal intent was. It checks whether the sending source matches the authorization published in DNS for the envelope sender domain.

The SPF check in plain English

Microsoft describes SPF as a DNS-based authentication mechanism where a domain's TXT record lists authorized sources for the SMTP envelope sender. Receiving systems compare the connecting IP address against mechanisms in the record, such as ip4 and include, and then apply an enforcement qualifier like -all, which directly affects whether mail is delivered or rejected (Microsoft SPF configuration guidance).

The sequence looks like this:

The message arrives: A receiving server accepts a connection from a sending server.

The receiver checks the envelope sender: This is often called the Return-Path or MAIL FROM domain.

DNS is queried for SPF: The receiver looks for a TXT record that starts with v=spf1.

The sending source is evaluated: The receiver compares the connecting source against the mechanisms in the record.

A result is produced: Depending on the qualifier and the match, the message may pass, fail, or be treated with suspicion.

What the receiver evaluates

The important detail is that SPF evaluates the envelope-from domain, not the address a human sees in the inbox preview. That technical distinction matters later when people assume SPF alone stops impersonation.

Here are the parts of the check that affect deliverability most:

SPF element	What the receiver does	Why it matters
`v=spf1`	Identifies the TXT record as SPF	Without it, the record isn't valid SPF
`ip4` or `ip6`	Checks whether a sending IP is explicitly authorized	Useful for direct mail servers
`include`	Pulls in another domain's SPF policy	Common for third-party senders
`a` or `mx`	Authorizes sources based on DNS A or MX records	Can work, but often adds complexity
`-all` or `~all`	Tells the receiver how strict to be with non-matches	Impacts enforcement and risk tolerance

That last point is where teams get into trouble. SPF can be perfectly valid on paper and still fail in production if someone added a new CRM, support platform, or outbound tool and forgot to update DNS.

Deconstructing an SPF Record Syntax and Examples

A lot of SPF advice stops at "add a record." That isn't enough. You need to be able to read the record and decide whether it still reflects reality.

The parts that matter

A valid SPF record starts with v=spf1. After that, you list the authorized sources and finish with a qualifier that tells receivers how to treat anything not listed.

Mailpro notes that SPF supports precise IP authorization using CIDR notation and delegated authorization through include mechanisms. It also notes that a strict -all policy tells destination systems to reject mail from any source not explicitly listed, which makes accuracy critical for deliverability (Mailpro explanation of SPF syntax).

Here are the common building blocks:

v=spf1This identifies the record as SPF version 1. Every SPF record starts here.

ip4 and ip6These authorize specific sending IPs or ranges. Use them for infrastructure you control directly.

includeThis delegates part of the authorization to another sender's SPF policy. It is common for providers like Google Workspace, transactional email platforms, and CRM systems.

a and mxThese authorize based on your domain's A or MX records. They can be useful, but they can also make records harder to reason about.

~all and -all~all is softfail. -all is hard fail. The stricter option is safer once your inventory is complete.

Valid and risky examples

Below is a simple comparison of patterns you might see.

Example	Meaning	Verdict
`v=spf1 include:... ~all`	Authorizes a provider and softfails everything else	Often fine during cleanup
`v=spf1 include:... include:... -all`	Authorizes multiple providers and hardfails unknown senders	Good if inventory is complete
`v=spf1 ip4:... -all`	Allows only one direct server or range	Good for simple infrastructure
`v=spf1 ?all`	Gives no clear policy for non-matches	Usually too weak
`v=spf1 +all`	Effectively authorizes everyone	Risky and defeats the point

A healthy SPF record is usually short enough to understand, strict enough to be useful, and current enough to reflect your actual mail stack.

Two practical checks catch most issues fast:

Map every sender: List Google Workspace, Microsoft 365, outbound platforms, support tools, product mail systems, and any infrastructure your developers use.

Match record to reality: If a tool sends mail for your domain and isn't represented in SPF, that mail is exposed.

SPF vs DKIM and DMARC Why You Need All Three

SPF is necessary. It is not enough.

That is the part many introductory guides miss, and it's why teams sometimes publish SPF, see a "pass," and still have phishing exposure or inbox placement problems.

What SPF does not cover

A key limitation of SPF is that it authenticates the envelope-from domain, not the visible From header a user sees. That means SPF alone does not fully prevent display-name or header-from impersonation, which is why it needs DKIM and DMARC for broader phishing protection (Wikipedia overview of SPF limitations).

If you only remember one point, make it this one:

That's why modern authentication is layered.

How the three work together

Think of the three protocols as solving different trust problems:

Protocol	Primary role	What it helps with
SPF	Verifies whether the sending source is authorized for the envelope sender	Basic sender authorization
DKIM	Uses a cryptographic signature tied to the domain	Message integrity and domain-level authentication
DMARC	Applies policy and alignment rules across SPF and DKIM	Enforcement and clearer receiver handling

If you want the deeper comparison, this guide on SPF vs DKIM vs DMARC email authentication explained is the right next read.

The practical difference shows up in real mail flow:

SPF alone: Helps prove a server was authorized, but leaves gaps around visible sender identity.

SPF plus DKIM: Adds stronger proof that the message wasn't altered and is tied to a domain.

SPF plus DKIM plus DMARC: Gives mailbox providers a policy framework for how to treat failures and whether the visible identity aligns with the authenticated domains.

DMARC policies are often written as:

p=none for monitoring

p=quarantine for sending failures toward spam or junk handling

p=reject for strongest enforcement

The mistake is thinking SPF can stand in for all of that. It can't. For inbox placement, SPF is table stakes. For phishing resistance and policy control, you need the full set.

Common SPF Mistakes That Send Your Emails to Spam

The biggest SPF failures aren't dramatic. They're quiet. Mail keeps flowing, then one platform change or one vendor include pushes the record over the edge and legitimate mail starts failing intermittently.

The failures I see most often

The first is complexity. Proofpoint notes a critical SPF rule that many teams miss: many receiving servers stop evaluating an SPF record after 10 DNS lookup mechanisms such as include, a, and mx. When that limit is exceeded, legitimate email can fail authentication (Proofpoint on SPF and the 10 lookup limit).

That creates a very modern problem. A company starts with one provider, then adds a CRM, support desk, outbound sales platform, marketing automation tool, and transactional provider. Each one wants an include. The final DNS record looks normal to a human, but it becomes fragile in live evaluation.

The second common mistake is publishing multiple SPF records. A domain should have one SPF record, not several separate TXT entries that each begin with v=spf1. This usually happens when different teams add providers independently.

The third is stale authorization. A tool was removed months ago, but its include stays in the record. Another tool started sending but never got added. SPF becomes an archaeological record of old vendors instead of a working authorization policy.

What to do instead

Use this checklist when SPF looks valid but mail performance says otherwise:

Count lookup-heavy mechanisms: Watch every include, a, and mx carefully. A record can look short and still expand into too many lookups.

Keep one authoritative record: Merge all legitimate senders into a single SPF record for the domain.

Remove dead vendors: If a platform no longer sends mail for you, remove it from SPF.

Publish SPF as TXT: The old dedicated SPF record type is deprecated. Use a DNS TXT record.

Review after every tooling change: SPF should be updated whenever marketing, sales, product, or support changes sending providers.

A practical symptom map helps:

Symptom	Likely SPF issue	What to check
Some messages pass, others don't	Missing sender or stale vendor entry	Compare sending tools to current SPF
SPF errors appear after adding a new platform	Lookup count or bad include chain	Review nested mechanisms
The domain has SPF but mail still fails	More than one SPF record or invalid syntax	Check TXT records at the root
Non-sending domain gets spoofed	No explicit non-sending policy	Publish a strict no-mail SPF policy

SPF is not set-and-forget DNS. It needs ownership. In growing teams, that usually means someone has to maintain a sender inventory, not just the record itself.

How to Check and Fix Your SPF Record A Step-by-Step Guide

A common failure looks like this. A company adds a new CRM, a support platform, and an outbound sales tool over six months. Mail volume goes up, replies drop, and nobody connects the decline to SPF until a lookup shows the record is bloated, outdated, or missing a sender that now handles high-value mail.

That is why SPF checks need to be operational, not occasional. The record in DNS may exist and still be wrong for the way your domain sends mail today.

A practical SPF workflow

Start with a live lookup against the exact domain in your From or Return-Path setup. Use an SPF record checker that resolves your live DNS and flags common errors, then compare that output to your actual sender inventory. mailX is one option. It checks SPF and related deliverability signals, then points you to the issue instead of only showing raw TXT output.

Work through the check in this order:

Check the right domain Teams often inspect the root domain while the actual mail stream uses a subdomain such as news.example.com or support.example.com. Check every domain and subdomain that sends mail.

Confirm the record returns one valid SPF policyThe result should show one v=spf1 record. If DNS returns multiple SPF records or malformed syntax, receivers can treat SPF as invalid.

Expand every include At this stage, many checks stop too early. A short SPF record can still fail because included vendors trigger too many DNS lookups. If your stack has grown over time, this is one of the first things to verify.

Match the record to real sendersEvery include, IP, a, or mx mechanism should map to a tool or server your team still uses. If nobody can name the owner of an entry, it should be reviewed.

Review the qualifier at the end~all is safer during cleanup because it gives you room to verify hidden senders. -all is stronger once the inventory is complete and tested. The trade-off is simple. A strict policy improves spoofing resistance, but it will break legitimate mail if your sender list is incomplete.

Test after each DNS changeDo not batch five edits and hope for the best. Make one change, wait for DNS to update, then test again. That makes it much easier to identify which edit fixed or broke evaluation.

A walkthrough helps if you're new to this:

What good results look like

A healthy SPF result is boring in the best way.

One published SPF record: Receivers should find a single authoritative policy.

A record that stays under evaluation limits: Passing syntax is not enough if nested includes push you over the 10-lookup limit.

Named, current senders only: The record reflects your current ESPs, sales platforms, support tools, and internal mail servers.

A deliberate policy ending: ~all during validation, -all after you have confirmed legitimate sources.

If the check finds problems, fix them in this order:

Build a sender inventory firstPull from marketing, sales, support, product, engineering, and IT. SPF breaks when one team adds a tool without telling the DNS owner.

Remove anything you no longer useOld includes create lookup bloat and keep former vendors authorized to send.

Flatten or simplify carefullyReducing lookups helps, but aggressive flattening can create stale records if vendor IPs change. Choose the approach your team can maintain.

Retest using live DNS, then send real messagesA record can validate in theory and still miss a production mail path. Test the actual workflow that matters, such as password resets, invoices, outbound sequences, and support replies.

This matters even more for teams using AI agents to send mail, triage deliverability issues, or recommend config changes. An agent needs live SPF diagnostics, not a static assumption that the DNS entry is fine. SPF changes as your software stack changes, and inbox placement follows those changes fast.

Frequently Asked Questions About SPF

One DNS change can look harmless in the admin panel and still break mail an hour later. That is why SPF questions keep coming up. The record is small, but the failure modes are not, especially once a company adds multiple ESPs, outbound tools, support platforms, and AI agents that need live diagnostics instead of stale assumptions.

Can I have more than one SPF record for my domain

No. Publish one SPF record per domain.

If you publish multiple SPF records, receivers may treat SPF as invalid with a PermError. In real delivery terms, that means mail can fail authentication even when one of the records contains the right sender. I see this after mergers, tool migrations, and rushed vendor setups where each team adds its own TXT record instead of updating the existing one.

What is the difference between softfail and hardfail

~all is a softfail. It signals that mail from non-listed senders should be treated with caution.

-all is a hardfail. It signals that mail from non-listed senders is unauthorized and can be rejected.

The trade-off is straightforward. ~all gives you room to validate real mail paths while you clean up your sender inventory. -all is the stronger policy, but only after you have confirmed that every legitimate platform is covered, including edge cases like ticket replies, billing mail, and app notifications.

How long does it take for SPF changes to work

SPF changes depend on DNS propagation and cache expiry. Some updates appear within minutes. Others take longer, depending on the DNS host, TTL settings, and recursive resolvers between you and the receiver.

If the record looks right in your DNS console but live checks still show the old version, do not assume the syntax is broken. Recheck from multiple DNS resolvers and test again after cache expiry. This matters even more when you are debugging active delivery problems, because one stale lookup path can make the issue look intermittent.

Does SPF stop phishing by itself

No. SPF helps limit spoofing from unauthorized infrastructure, but it does not protect the visible From address on its own.

Attackers can still abuse lookalike domains, and SPF alignment may fail to enforce your brand identity without DKIM and DMARC. SPF is one control in the authentication stack, not the full answer.

What should I publish if my domain does not send email

Publish v=spf1 -all for a non-sending domain.

That tells receivers no server is authorized to send mail for that domain. It is a good policy for parked domains, defensive registrations, and domains used only for web traffic. It also reduces abuse risk from domains nobody on your team should be mailing from in the first place.

Why do emails still go to spam if SPF passes

SPF pass does not guarantee inbox placement. Mailbox providers also evaluate DKIM, DMARC alignment, domain and IP reputation, complaint patterns, engagement, message consistency, and sending infrastructure.

There is another common problem. SPF can pass for one platform and fail for another because the record was built around the original mail stack and never updated as new tools were added. A record that worked last year can drift into trouble once nested includes, forwarding paths, or the 10-lookup limit enter the picture.

Email deliverability problems are usually traceable. They come from authentication gaps, DNS errors, reputation issues, infrastructure problems, or sender behavior. SPF is one of the first places to check because it breaks often, degrades trust fast, and changes as your software stack changes.

If you want a fast next step, use mailX to run a live deliverability check, review your SPF setup, and get clear guidance on what to fix next.

Authored using Outrank