What Is SPF (Sender Policy Framework)?
SPF (Sender Policy Framework) is an email authentication standard that lets a domain owner publish, in DNS, the list of mail servers authorized to send email on the domain’s behalf. Receiving servers check the sending IP against this list to detect forged senders.
An SPF record is a single TXT record in your domain’s DNS that starts with "v=spf1" and lists authorized sources — IP addresses, "include:" statements for services like Google or your ESP, and an ending mechanism such as "~all" (soft fail) or "-all" (hard fail).
SPF has important limits. It authenticates the envelope sender (Return-Path), not the visible "From" address, and it breaks when email is forwarded. It also enforces a 10 DNS-lookup limit — exceed it and SPF fails entirely, so keep "include:" statements lean.
SPF alone is not enough. It should always be paired with DKIM and DMARC; DMARC is what aligns SPF to the visible From domain and turns these checks into real anti-spoofing enforcement.
How SPF works
SPF is a single DNS TXT record on your domain that lists every source allowed to send mail for it. When a receiving server accepts a connection, it reads the envelope sender (the Return-Path / MAIL FROM domain), looks up that domain’s SPF record, and checks whether the connecting IP is authorized. If the IP matches, SPF passes; if not, the final "all" mechanism decides how strongly to fail.
A record is a space-separated list of mechanisms evaluated left to right. "ip4:" and "ip6:" authorize specific addresses or ranges. "include:" pulls in another domain’s SPF record (used for services like Google Workspace, Microsoft 365, or your ESP). "a" and "mx" authorize your domain’s own A and MX hosts. The record must end with an "all" mechanism that sets the default for anything not matched.
SPF authenticates the envelope sender, not the visible From: address, and it breaks when mail is forwarded because the forwarding server becomes the new connecting IP. That is why SPF must be paired with DKIM and DMARC — DMARC is what aligns SPF to the From domain and turns it into real anti-spoofing enforcement.
How to set up SPF
Create one TXT record at your domain’s root (the "@" or apex host) starting with v=spf1. Add an include: for each sending service you use, then end with ~all (soft fail) while testing, tightening to -all (hard fail) once you are confident every legitimate source is listed. You may publish only one SPF record per domain — if you send through several providers, merge all their includes into that single record.
The example below authorizes Google Workspace and Microsoft 365. Replace the includes with the exact values your providers document. After publishing, wait for DNS to propagate (up to 24–48 hours) and confirm the record resolves and stays under the 10-lookup limit.
Common mistakes
The two record-killing errors are publishing more than one v=spf1 record (which invalidates all of them) and exceeding the 10 DNS-lookup limit. Each include:, a, mx, ptr, and exists mechanism costs a lookup; go over ten and receivers return a permerror that fails SPF outright, even for real mail. Flatten or remove unused includes to stay under the cap.
Other frequent mistakes: using +all (which authorizes the entire internet and defeats the point), leaving stale includes for services you no longer use, and forgetting that SPF alone does nothing against From-address spoofing without DMARC alignment.
Example records
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
Published as a TXT record at your domain apex. "~all" is a soft fail (mark, don’t reject); switch to "-all" for a hard fail once every legitimate sender is included.
SPF "all" qualifiers explained
| Qualifier | Meaning | Receiver behavior on non-match | When to use |
|---|---|---|---|
| -all | Hard fail | Reject / treat as unauthorized | Production — once all sources are confirmed |
| ~all | Soft fail | Accept but mark suspicious | While testing or rolling out SPF |
| ?all | Neutral | No opinion — treat as if no SPF | Rarely useful; effectively no enforcement |
| +all | Pass all | Authorizes every server on the internet | Never — this defeats SPF entirely |
Frequently asked questions
What is an SPF record?
An SPF record is a single DNS TXT record, starting with v=spf1, that lists the mail servers authorized to send email for your domain. Receiving servers check the sending IP against this list to detect forged senders. It is one of the three core email-authentication protocols alongside DKIM and DMARC.
What does ~all mean in SPF?
~all is the "soft fail" qualifier. It tells receivers that any server not listed in your SPF record is probably unauthorized, but the message should still be accepted and marked rather than rejected. Use ~all while testing, then switch to -all (hard fail) once every legitimate sending source is included.
What is the difference between ~all and -all?
~all (soft fail) tells receivers to accept but flag mail from unlisted servers; -all (hard fail) tells them to reject it. Start with ~all while confirming your setup, then move to -all for full protection once you are certain all legitimate senders are authorized in the record.
Can I have more than one SPF record?
No. A domain may publish only one v=spf1 TXT record. Two or more SPF records invalidate each other and cause authentication to fail. If you send through multiple providers, merge all their include: mechanisms into a single record.
What is the SPF 10-lookup limit?
SPF allows a maximum of 10 DNS lookups when evaluating a record. Each include:, a, mx, ptr, and exists mechanism counts. Exceeding ten triggers a permerror that fails SPF for legitimate mail, so keep includes lean and remove unused services.
Use MailPilot’s free SPF generator to build a correct, lookup-safe record, then verify it passes with the built-in DNS health checker.
Generate a valid SPF record →