What Is SPF? Sender Policy Framework Explained

SPF, or Sender Policy Framework, is a DNS record that lists which servers are allowed to send email on behalf of your domain. When a receiving server gets a message, it reads the envelope sender domain, looks up that domain's SPF record, and checks whether the connecting IP address is on the authorized list. If it is, SPF returns a pass; if not, it returns a fail. That result is one input mailbox providers use when deciding whether to deliver, filter, or reject your mail.

What Is SPF?

SPF stands for Sender Policy Framework. It is a way for a domain owner to publish, in DNS, the list of IP addresses and hosts that are permitted to send mail using that domain as the envelope sender. The mechanism is defined in RFC 7208, and it works through a single DNS TXT record published on the domain.

It helps to be precise about what SPF is not. SPF does not encrypt anything, does not vouch for the content of a message, and does not by itself authenticate the visible From address your recipient sees in their inbox. It authorizes sending infrastructure for the envelope domain. The visible From header is covered by DKIM and DMARC, which is why SPF is one piece of a set rather than a complete solution.

If you send marketing or transactional email from your own domain, SPF is the first thing to get right, because SPF is a foundational piece of email authentication and a prerequisite for DMARC.

How SPF Works in Practice

The sequence is straightforward once you separate the two identities involved in every message:

1. Your sending server connects to the recipient's mail server and announces a sender address during the SMTP conversation. This is the envelope sender, also called the Return-Path or MAIL FROM address.
2. The receiving server extracts the domain from that envelope sender.
3. It performs a DNS TXT lookup on that domain and finds the SPF record.
4. It evaluates the record's mechanisms against the IP address that just connected.
5. It records a result: pass, fail, softfail, neutral, or none (no record found).

The most common source of confusion is the gap between the envelope sender and the visible From header. They are often the same domain, but not always. An email platform may send on your behalf with an envelope domain of its own while displaying your brand in the From field. That is why SPF passing does not automatically mean the message is aligned with your visible domain, and why DMARC exists to enforce that alignment.

Two hard limits shape how you write records. First, SPF allows a maximum of 10 DNS lookups during evaluation. Mechanisms like include, a, mx, ptr, exists, and redirect each consume lookups, and nested includes count toward the total. Second, each character string in a TXT record is limited to 255 characters, and the total record is generally kept within 512 octets. Exceeding the lookup limit produces a permerror, which is worse than a fail because the record cannot be evaluated at all.

What an SPF Record Looks Like

Here is a typical record for a domain that sends through one email platform plus its own web server:

example.com.  TXT  "v=spf1 include:_spf.emailprovider.example ip4:203.0.113.10 -all"

Line by line:

• v=spf1 — declares the record version. Every SPF record starts with this, and it must be the first term.
• include:_spf.emailprovider.example — authorizes every IP that the provider publishes in its own SPF record. This costs one DNS lookup, and any includes inside it cost more.
• ip4:203.0.113.10 — authorizes a single IPv4 address, typically your own server. ip6: does the same for IPv6.
• -all — a hard fail for anything not matched above. Use this when you are confident the list is complete.

A domain sending through two providers looks like this:

example.com.  TXT  "v=spf1 include:_spf.providerone.example include:_spf.providertwo.example ~all"

Here ~all is a soft fail: unmatched mail is accepted but marked as suspicious. Soft fail is a reasonable choice while you are still discovering every legitimate sender, because a hard fail on a forgotten tool will bounce real mail. Once your inventory is complete, tighten to -all.

You can also use a (authorizes the domain's A record), mx (authorizes its mail exchangers), and ptr (reverse DNS). Avoid ptr: it is deprecated, slow, and unreliable.

Why SPF Matters for Deliverability

Mailbox providers use SPF as one signal in their filtering and spam scoring. A message that fails SPF can be filtered or rejected, especially when it also fails DKIM. A passing SPF result does not guarantee inbox placement, but a failing SPF result is a negative signal that is entirely within your control.

SPF is also a prerequisite for DMARC. DMARC requires that either SPF or DKIM pass and align with the visible From domain. Without a working SPF record, you lose one of the two paths to DMARC compliance, and you cannot move to a DMARC enforcement policy with any confidence.

One known limitation deserves emphasis: SPF breaks on forwarded mail. When a recipient forwards a message, the forwarding server becomes the connecting IP, which is not in your SPF record, so the check fails. This is expected behavior, not a misconfiguration. Sender Rewriting Scheme (SRS) or DKIM alignment is how that gap gets covered.

SPF Limits and Common Mistakes

Common SPF problems include:

• Exceeding 10 DNS lookups. Each include can hide further lookups inside it. Audit your count whenever you add a tool.
• Publishing more than one SPF record. A domain must have exactly one TXT record starting with v=spf1. Two records cause a permerror; merge them instead.
• Forgetting to update the record when adding a sending tool. New tools fail SPF until you add their include.
• Using -all too early. If any legitimate sender is missing, hard fail bounces real mail. Start with ~all and tighten later.
• Using ptr. It is deprecated and adds latency and lookups for no benefit.
• Splitting long records incorrectly. If a record approaches the 255-character string limit, split it into multiple quoted strings within the same TXT record, not into separate records.

How to Check and Fix Your SPF Record

A practical workflow:

1. Look up the record: dig TXT example.com +short or an online SPF checker.
2. Count the DNS lookups. Many checkers report this directly; if yours does not, count each include, a, mx, ptr, exists, and redirect term, including nested ones.
3. List every tool that sends from your domain and confirm each one's sending IPs are covered.
4. Consolidate everything into one record and remove duplicates.
5. Send a real test message to a Gmail or Outlook address and inspect the Authentication-Results header to confirm spf=pass.

If you would rather not hand-audit DNS, Mailerflow's own-domain sending includes guided DKIM, SPF, and DMARC setup with automatic verification, so the record is checked for you before you send. For a deeper walkthrough of validating all three records, see our guide on checking whether SPF, DKIM and DMARC are set up correctly.

SPF vs DKIM vs DMARC

SPF alone is not enough for modern deliverability. The three work as a set: SPF and DKIM provide the evidence, and DMARC tells receivers what to do when that evidence is missing or misaligned. If you want the full picture of how authentication survives forwarding, our explainer on the ARC authenticated received chain covers the chain-of-custody side.

Related Terms

• DKIM — a cryptographic signature added to outgoing mail that lets receivers verify the message was not altered in transit.
• DMARC — a policy record that tells receivers how to handle mail failing SPF or DKIM, and requires alignment with the visible From domain.
• Envelope sender — the address used in the SMTP conversation, also called Return-Path or MAIL FROM. SPF checks this, not the visible From.
• Return-Path — the header where the envelope sender is recorded when a message is delivered.
• Alignment — the match between the domain SPF or DKIM authenticated and the domain in the visible From header. DMARC requires it.
• DNS TXT record — the record type that holds SPF data, along with other domain verification strings.
• BIMI — a standard that displays a verified brand logo next to authenticated mail; it requires DMARC enforcement first.
• MTA-STS — a policy that forces TLS encryption for inbound mail to your domain.
• TLS-RPT — a reporting mechanism for TLS connection failures, often paired with MTA-STS.

FAQ

Can I have more than one SPF record?

No. A domain must publish exactly one TXT record beginning with v=spf1. Multiple records cause a permerror, so merge every sender into a single record.

Does SPF work with forwarded email?

Often not. Forwarding changes the connecting IP, so the SPF check fails against your record. Sender Rewriting Scheme or DKIM alignment is how that is handled.

How long does an SPF change take to propagate?

Propagation depends on your record's TTL; a low TTL (e.g., 300 seconds) means changes are visible within minutes, while a high TTL can take hours. Lower the TTL before a planned change if you need faster propagation.

Does SPF stop spoofing?

It stops spoofing of the envelope domain only. Someone can still spoof the visible From header unless DMARC is in place to enforce alignment.

Is SPF required?

Not strictly, but it is strongly recommended, and it is required if you want DMARC to work. Without SPF, you lose one of the two paths to DMARC compliance.

Set up your sending domain in Mailerflow with guided DKIM, SPF and DMARC and automatic verification, so authentication is handled before your first campaign goes out.