Skip to main content
ShieldMarc
Resources/Guides
Guide

What is SPF? Sender Policy Framework Explained

SPF is the oldest of the three email authentication standards and the first line of defence against people sending email as your domain. It is simple in principle: you publish, in DNS, the list of servers allowed to send mail for your domain, and receivers check every message against it. The detail is where most mistakes happen.

7 min read · Updated July 2026

What is SPF?

SPF stands for Sender Policy Framework. It is an email authentication standard, defined in RFC 7208, that lets the owner of a domain publish a list of the mail servers and IP addresses authorised to send email on that domain's behalf. The list lives in a single DNS TXT record. When a receiving server accepts an incoming message, it looks up that record and checks whether the connecting server is allowed to send for the domain.

The purpose is to make forgery detectable. Anyone can put your domain in the technical envelope of an email, but without SPF the receiver has no way to know whether the sending server is genuinely yours. SPF turns "this claims to be from example.com" into "this claims to be from example.com, and example.com says this server is (or is not) allowed to send for it."

How SPF works, and which address it checks

This is the single most misunderstood part of SPF. SPF does not check the From address that a recipient sees in their mail client. It checks the envelope sender — the MAIL FROM (also called the Return-Path) domain that the sending server declares during the SMTP conversation.

Here is the flow for a typical inbound message:

1.A server connects and says the message is from bounce@example.com (the envelope sender).
2.The receiver looks up the SPF record at example.com.
3.It compares the connecting server's IP address against the IPs the record authorises.
4.If the IP is listed, SPF passes. If not, SPF fails (how hard depends on the record's all qualifier).

Because SPF only authenticates the envelope domain, it says nothing on its own about the visible From address. An attacker can pass SPF for a domain they control while still forging the From header a recipient reads. Closing that gap is the job of DMARC alignment, covered below.

What an SPF record looks like

An SPF record is a DNS TXT record on your domain that begins with v=spf1. Here is a typical example for an organisation using Microsoft 365 plus a marketing platform:

v=spf1 include:spf.protection.outlook.com include:_spf.marketingtool.com -all

Each term is a mechanism. The common ones:

MechanismMeaning
include:Authorise all the IPs in another domain's SPF record (how you add a provider like Microsoft 365 or Google Workspace).
ip4: / ip6:Authorise a specific IP address or range directly.
a / mxAuthorise the domain's own A record, or the servers listed in its MX records.
allThe catch-all at the end. Its qualifier decides what happens to every server not matched above.

You can build a valid record with our free SPF Generator, or check an existing one with the SPF Checker.

~all vs -all: soft fail and hard fail

The qualifier on the final all mechanism tells receivers how to treat any server that is not explicitly authorised:

  • -all (hard fail) says unlisted servers are unauthorised and mail from them should be treated as failing SPF.
  • ~all (soft fail) says unlisted servers are suspicious but the message should usually still be accepted and marked.

Under DMARC the two behave almost identically, because DMARC enforcement, not the SPF qualifier, decides whether failing mail is quarantined or rejected. That makes ~all the safer default while you confirm every legitimate sender is in the record, with -all reserved for records you are certain are complete. Our guide on SPF hard fail vs soft fail covers the trade-off in full.

The 10 DNS lookup limit

SPF has a hard rule that trips up growing organisations: evaluating a record may trigger at most 10 DNS lookups (RFC 7208 §4.6.4). Every include, a, mx, ptr and exists mechanism — plus the redirect modifier — counts. Add a few SaaS senders, each with their own include that nests further includes, and you quietly exceed 10. When that happens SPF returns a permerror and receivers treat the record as broken, so even authorised mail can start failing.

The fix is to flatten or consolidate the record. Our SPF Flattener resolves nested includes to a flat list of IPs, and the guide on fixing SPF too many DNS lookups walks through the options.

Why SPF alone is not enough

SPF is necessary but not sufficient, for two structural reasons:

  • It breaks on forwarding.When a message is forwarded (a mailing list, a "forward to my other address" rule), the forwarding server's IP is not in your SPF record, so SPF fails even though the mail is legitimate. DKIM survives forwarding — as long as the message is not modified in transit — because its signature travels with the message.
  • It does not protect the visible From. SPF only authenticates the envelope domain, which recipients never see. On its own it cannot stop someone spoofing your exact From address. DMARC fixes this by requiring the SPF (or DKIM) domain to align with the From domain, and then applying a policy.

In practice you deploy all three together. For how they combine, see SPF vs DKIM vs DMARC, and to understand the layer that ties SPF to the address people actually read, see what is DMARC.

Common SPF mistakes

  • More than one SPF record. A domain must have exactly one v=spf1 record. Two or more is a permerror and SPF is treated as if it does not exist. Merge them into one.
  • Exceeding 10 DNS lookups. The most common cause of a previously working record silently failing as you add senders.
  • Leaving parked domains open. A domain that never sends email should publish v=spf1 -all so nothing is authorised. See DMARC for parked domains.
  • Relying on SPF alone. Publishing SPF without DKIM and DMARC leaves the visible From address unprotected.

Next steps

Frequently asked questions

What does SPF stand for?

SPF stands for Sender Policy Framework. It is an email authentication standard, defined in RFC 7208, that lets a domain owner publish, in DNS, the list of mail servers and IP addresses allowed to send email using that domain. Receiving servers check incoming mail against that list to help detect forged senders.

Which address does SPF check?

SPF checks the envelope sender — the Return-Path or MAIL FROM domain used during SMTP delivery — not the From address a recipient sees in their mail client. This is why SPF on its own cannot stop exact-domain spoofing of the visible From: that requires DMARC alignment, which ties the SPF result back to the From domain.

Is SPF enough on its own?

No. SPF only authorises sending IPs for the envelope domain, it breaks when mail is forwarded, and it does nothing about the visible From address. Real protection needs DKIM (a signature that survives forwarding when the message is unmodified) and DMARC (which aligns SPF or DKIM to the From address and applies a policy). SPF is a necessary foundation, not a complete solution.

What is the difference between ~all and -all in SPF?

-all is a hard fail: any server not listed is unauthorised and mail from it should be treated as failing SPF. ~all is a soft fail: unlisted servers are marked suspicious but usually still accepted. Under DMARC both behave similarly because DMARC enforcement handles the rejection, so ~all is the safer default until you are certain the record lists every sender.

How do I check my SPF record?

Look up the TXT records on your domain and find the one starting v=spf1, or paste your domain into a free SPF checker. ShieldMarc's SPF Checker validates the record, counts DNS lookups against the 10-lookup limit, and flags misconfigurations, with no sign-up needed.

Check your SPF in seconds

Paste your domain into the free SPF Checker to validate your record and count DNS lookups. For ongoing monitoring of SPF, DKIM and DMARC across every domain you own, create a free ShieldMarc account and start with your first domain in minutes.