What is SPF? Sender Policy Framework explained

SPF (Sender Policy Framework) is an email authentication standard, defined in RFC 7208, that lets a domain owner publish a DNS record listing the servers authorised to send mail for that domain. When a message arrives, the receiving server looks up the SPF record for the sending domain and checks whether the connecting IP address is on the list.

That one-paragraph definition hides a few details that matter a great deal in practice: which domain SPF actually checks, how receivers turn the check into a result, and where the mechanism quietly stops working. This guide walks through each of them.

What problem does SPF solve?

The SMTP protocol that moves email between servers was designed without any built-in way to verify who sent a message. Any server can connect to yours and claim to be sending mail from any domain. Before authentication standards existed, receivers had no reliable way to tell a genuine message from your domain apart from a forgery.

SPF was the first widely adopted answer. The idea is simple: the owner of a domain knows which servers legitimately send its mail, so let them say so in DNS, where everyone can look it up. A receiver can then compare the IP address that actually delivered a message against the published list.

An SPF record is an ordinary DNS TXT record at the root of the domain. A typical one looks like this:

v=spf1 ip4:203.0.113.0/24 include:spf.protection.outlook.com -all

Read left to right, this says: version 1 of SPF; the IP range 203.0.113.0/24 is authorised; any server authorised by spf.protection.outlook.com (Microsoft 365, in this case) is authorised; and anything else should fail. The full mechanism and qualifier syntax is covered in our SPF record syntax guide.

Which address does SPF actually check?

This is the single most misunderstood point about SPF, and it explains most real-world surprises.

Every email has two sender addresses. The envelope from (formally the RFC5321.MailFrom, also called the Return-Path) is used during the SMTP conversation between servers and is where bounces are sent. The header from (RFC5322.From) is the address displayed in the recipient's mail client. They are often the same, but nothing requires them to be.

SPF checks the envelope from, not the visible From header. A receiver takes the domain from the MailFrom address, fetches that domain's SPF record, and evaluates the connecting IP against it. (If the MailFrom is empty, as it is for bounce messages, SPF falls back to checking the HELO hostname the sending server identified itself with.)

The consequence is important: a message can pass SPF while displaying a completely different domain to the recipient. A phisher can send mail with an envelope from at a domain they control, with a perfectly valid SPF record, while the From header shows your domain. SPF passes; the recipient still sees a forgery. The distinction between these two addresses is explored further in envelope from vs header from, and it is exactly the gap that DMARC was created to close.

How do receivers evaluate an SPF check?

When a receiving server evaluates SPF, it works through the record's mechanisms left to right and stops at the first match. Each mechanism carries a qualifier that determines the result when it matches. The evaluation produces one of seven results defined in RFC 7208:

Result	Meaning
pass	The IP is authorised by the domain's SPF record.
fail	The IP is explicitly not authorised (matched a - qualifier, usually -all).
softfail	The IP is probably not authorised (~all); treat with suspicion but do not reject outright.
neutral	The domain makes no assertion about this IP (?all).
none	No SPF record exists, or no domain could be determined.
temperror	A temporary DNS problem prevented evaluation; the receiver may retry.
permerror	The record is invalid and cannot be evaluated, for example a syntax error, multiple SPF records, or too many DNS lookups.

Two of these deserve a closer look. The difference between softfail and fail shapes how strictly receivers treat unauthorised mail, and choosing between ~all and -all is a genuine decision, not a formality. And permerror is the result that catches out growing organisations: SPF caps the number of DNS-querying mechanisms (include, a, mx, ptr, exists and the redirect modifier) at ten per evaluation. Plain ip4 and ip6 mechanisms do not count. Add enough third-party services via include and the record silently tips over the limit, turning every check into a permanent error. Our guide to the SPF 10 DNS lookup limit explains how to diagnose and fix this.

It is also worth knowing what a receiver does with the result. RFC 7208 describes the results; it does not mandate a delivery decision. In practice, few large mailbox providers reject mail on an SPF fail alone. The result is usually one input into a wider filtering decision, and, more usefully, an input into DMARC.

A worked example

Suppose example.co.uk publishes:

v=spf1 include:_spf.google.com -all

A message arrives at a recipient's server from IP 209.85.220.41 with an envelope from of billing@example.co.uk. The receiver extracts the domain example.co.uk, fetches its SPF record, and expands include:_spf.google.com, which resolves (through further includes) to Google's sending ranges. The IP 209.85.220.41 falls inside one of those ranges, so the mechanism matches with its default + qualifier and the result is pass. Had the message come from an IP outside every listed range, evaluation would have reached -all and returned fail.

Why does forwarding break SPF?

SPF's design has a structural weakness: it authenticates the server that delivered the message to you, not the server that originally sent it. Those are the same until a message is forwarded.

Consider a message sent legitimately from example.co.uk to a recipient's old work address, which auto-forwards to their personal mailbox. The forwarding server passes the message on, but now the connecting IP belongs to the forwarder, not to any server in example.co.uk's SPF record. Unless the forwarder rewrites the envelope from (a technique called SRS, Sender Rewriting Scheme, which many forwarders do not implement), the final receiver evaluates the original domain's SPF record against the forwarder's IP and gets fail.

Nothing about the message is illegitimate; SPF simply cannot follow it through an intermediate hop. Mailing lists have the same problem, often compounded by content changes. This is why a domain at DMARC enforcement should never rely on SPF alone: DKIM (DomainKeys Identified Mail) signs the message content itself, so a signature normally survives forwarding intact unless the forwarder modifies the message. The failure modes and mitigations are covered in detail in why forwarding breaks SPF.

Why is SPF alone not enough?

Pulling the threads together, SPF has three limitations that stop it being a complete anti-spoofing control:

• It checks the wrong address for human purposes. SPF validates the envelope from, which recipients never see. An attacker can pass SPF on their own domain while forging your domain in the visible From header.
• It breaks on forwarding. Any intermediate hop that preserves the original envelope from will fail SPF at the final receiver, so legitimate mail fails through no fault of the sender.
• It carries no instruction. An SPF record says who may send, but not what a receiver should do with mail that fails, and receivers apply their own judgement inconsistently.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) addresses all three. It requires that an SPF or DKIM pass be aligned, meaning the authenticated domain must match the visible From header domain, which closes the two-address gap. It accepts either SPF or DKIM as sufficient, so forwarded mail with a surviving DKIM signature still passes. And it lets the domain owner publish an explicit policy (none, quarantine or reject) plus request reports on what receivers are seeing. How the alignment test works is explained in DMARC alignment explained, and the way the three standards interlock is the subject of how SPF, DKIM and DMARC work together.

None of this makes SPF obsolete. It remains one of the two authentication paths DMARC can use, it is quick to deploy, and for mail that travels directly from your sending infrastructure to the recipient it works exactly as intended. The right mental model is that SPF is a necessary layer, not a complete defence.

How do you deploy SPF well?

A brief, practical checklist for getting SPF right on a domain:

1. Inventory your senders first. List every system that sends mail as your domain: your mailbox provider, marketing platform, CRM, invoicing tool, monitoring alerts. Missing one means legitimate mail starts failing.
2. Publish exactly one record. Multiple TXT records starting v=spf1 produce a permerror, which is worse than no record at all. Merge all mechanisms into a single record.
3. Stay under the lookup limit. Count the DNS-querying mechanisms, including those nested inside each include. Ten is the ceiling.
4. End with a restrictive qualifier. Finish with ~all or -all. A record ending +all authorises the entire internet and is worse than useless.
5. Monitor before you trust it. DMARC aggregate reports show you, per sending IP, whether SPF passed and aligned in the real world, which is the only reliable way to confirm the inventory in step one was complete.

That last step is where monitoring earns its keep. The raw reports arrive as XML files; a DMARC monitoring service such as DMARCHub turns them into readable dashboards so you can see which sources pass SPF and which need attention (see /features).

Frequently asked questions

Does SPF stop email spoofing on its own?

No. SPF validates the envelope from address, which recipients never see, so an attacker can pass SPF using their own domain while forging yours in the visible From header. Stopping display-address spoofing requires DMARC, which ties authentication results to the From header domain and lets you publish a reject policy.

What does SPF stand for and where does it live?

SPF stands for Sender Policy Framework. It lives in your public DNS as a TXT record at the root of your domain, beginning with v=spf1. There is no software to install; the receiving server does the checking, and your only job is to keep the record accurate as your sending services change.

Is an SPF fail enough to get an email rejected?

Usually not by itself. RFC 7208 leaves the delivery decision to the receiver, and most large mailbox providers treat an SPF fail as one signal among many rather than an automatic rejection. Consistent rejection of forged mail comes from publishing a DMARC policy of quarantine or reject, which tells receivers explicitly what you want done.

Do I need SPF if I already have DKIM?

Yes, in practice. DMARC needs only one aligned pass, but relying on a single mechanism leaves no safety margin: a DKIM misconfiguration, an unsigned message stream, or a key rotation mistake would then fail everything. SPF and DKIM cover each other's weak spots, and some receivers weight mail with both more favourably. Publish both wherever you can.