What Is an SPF Record?
Published
An SPF record is a single line of text your domain publishes in public DNS that lists which mail servers are allowed to send email using your domain’s name. It is the oldest of the three email-authentication standards, it costs one DNS entry to publish, and it is the first thing a receiving server checks when a message claims to be from you. Yet the August 2026 defaults.exposed census graded 376,928,750 domains for email authentication and found that only 38.8% — 146,413,297 — publish any SPF record at all. Six in ten domains publish nothing. Of the minority that do, most choose the weakest possible setting: a soft-fail ~all that tells receivers to accept mail even when it fails the check. This guide explains what an SPF record is, how its mechanisms work, why the soft-fail default undermines the protection, and how to check and fix your own in a few minutes.
If you have ever been told to “add an SPF record” and wondered what it actually does — or added one years ago and never looked at it again — the honest position is that publishing SPF and being protected by it are two different things. An SPF record can be present, syntactically valid, and still wave forged mail through, because the mechanism that decides how a failure is handled is a single character at the end of the record. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.
What is an SPF record, in plain English
SPF — Sender Policy Framework, defined in RFC 7208 — is a public DNS TXT record that answers one question: which servers are permitted to send email on behalf of this domain? You publish a list of the mail sources you use — your own mail server, your email platform, your CRM, your invoicing tool — and any receiving server can look that list up before accepting a message that claims to come from you.
Here is a typical record, published as a TXT record at the root of your domain:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all
Read left to right, it says: this record is SPF version 1; authorise whatever Google’s mail servers authorise; authorise SendGrid’s; authorise the single server at 203.0.113.10; and — the final mechanism — reject everything else. A receiving server takes the domain in the message’s envelope, looks up this record, and checks whether the sending server appears on the list.
The crucial and most misunderstood detail is which domain SPF checks. SPF authenticates the envelope sender — the hidden MAIL FROM / Return-Path address used during the SMTP handshake — and the HELO name. It does not check the From: address a human actually reads in their inbox. That gap is the entire reason SPF alone cannot stop the spoofing most people worry about, and it is why SPF needs DMARC on top. We will return to it below.
Because the record lives in public DNS, anyone can read it — including an attacker sizing up whether your domain is worth impersonating. That is not a flaw; it is how the system works. But it means your SPF posture is visible to the whole internet, protective or not.
How SPF actually works: the -all, ~all and +all mechanisms
An SPF record is a space-separated list of mechanisms. Most of them name a source of legitimate mail; the last one — the all mechanism — is the catch-all that decides what happens to a server that matched none of the others. Each mechanism carries a qualifier, a single leading character that sets the verdict when it matches:
+(Pass) — authorised. This is the default when no qualifier is written, so a bareallmeans+all.-(Fail, “hard fail”) — not authorised; the receiver should reject.~(SoftFail) — not authorised, but the receiver should accept the mail anyway and merely mark it.?(Neutral) — no assertion either way; treat as if there were no policy.
The mechanisms before all name your legitimate senders. The common ones are:
ip4:/ip6:— a specific address or CIDR range you send from.include:— pull in another domain’s SPF record wholesale, the wayinclude:_spf.google.comdelegates to Google Workspace. This is how most SaaS mail is authorised.aandmx— authorise the domain’s own A record or its mail exchangers.
A receiver evaluates the mechanisms in order and stops at the first match. If the sending server matches an include or an ip4, the mail passes. If it reaches the end without matching, the qualifier on all decides the outcome — and that final qualifier is where almost all of the real-world weakness lives.
Two practical limits catch people out. First, SPF has a hard ceiling of 10 DNS lookups per evaluation; every include, a, mx and redirect counts, and stacking too many SaaS providers tips the record into a permerror that voids it entirely. Second, an SPF record has a 255-character-per-string limit and a practical length budget, so sprawling records get truncated or malformed. A record that errors out protects nothing, no matter what its all says. How defaults.exposed grades the presence and the strength of these records is set out in the SPF exists methodology and the SPF policy-strength methodology.
Soft-fail vs hard-fail: why 56% of SPF records barely protect you
The difference between -all and ~all is one character, and it is the difference between an SPF record that blocks unauthorised mail and one that merely comments on it.
-all(hard fail) tells the receiving server: if a sender is not on my list, reject the message. This is enforcement. It is the setting that actually stops an unauthorised server sending as your envelope domain.~all(soft fail) tells the receiving server: if a sender is not on my list, this is probably not legitimate — but deliver it anyway and just note the soft failure. In practice most inboxes accept soft-fail mail; at worst it nudges a spam score. It is a suggestion, not a rule.
The census makes the scale of this default plain. Of the 146,413,297 domains that publish any SPF record, 56.4% — 82,539,695 domains — end their record with a soft-fail ~all. Only 38.4% — 56,268,491 — use a hard-fail -all that a receiver is expected to enforce. So a clear majority of the domains that took the trouble to publish SPF chose the version that invites through exactly the mail SPF exists to stop.
Why is soft-fail so common? Mostly caution that has calcified into a default. ~all is the setting many setup wizards and hosting providers pre-fill, because it cannot break legitimate mail even if the record is incomplete — a missing sender is waved through rather than bounced. That safety is real during setup, but it is meant to be temporary. Left in place, ~all becomes a permanent open door: your record documents your senders without ever enforcing the list.
There is a worse tier still. A record ending in +all authorises every server on the internet to send as your domain — the exact opposite of the point. It is rare, and almost always the result of a copy-paste error or a misunderstanding of the + qualifier, but where it appears the domain is not merely unprotected, it is actively advertising itself as safe to spoof. Our twin report leads with the enforcement gap in detail: SPF hard-fail vs soft-fail: why 82 million domains are using the weaker setting.
The takeaway is uncomfortable but simple. “We have an SPF record” is not the finish line. A record that ends in ~all is published, valid, and — for the purpose of blocking forged mail on its own — barely doing its job.
SPF alone isn’t enough: the 86.9 million-domain DMARC gap
Even a perfect hard-fail SPF record leaves a hole, and it is the hole that matters most for impersonation. Recall that SPF checks the envelope sender, not the visible From: header. An attacker can send mail that passes SPF for their own throwaway domain while writing your domain into the From: line the recipient sees. SPF passes — for the wrong domain — and the human reads your brand in the sender field.
The standard that closes this gap is DMARC. DMARC insists that the domain which passed SPF (or DKIM) is aligned with the From: domain the recipient actually sees, and it tells receivers what to do when that alignment fails. Without DMARC on top, SPF protects the envelope nobody looks at while leaving the visible address anyone can forge. This is why SPF is necessary but not sufficient, and why the two are always discussed together — see what is DMARC for the layer that turns SPF’s result into enforcement on the visible domain.
The census shows how often the second layer is simply missing. 86.9 million domains — 23.1% of the email-graded base — publish SPF but no DMARC at all. They have done the first half of the work and stopped. Their SPF result, pass or fail, is never tied back to the visible From: address, so it does nothing to stop someone forging that address. It is authentication with no enforcement attached.
The gap runs the other way too. 16 million domains publish DMARC without any SPF underneath it, an enforcement policy with one of its two evidence sources absent — quantified in DMARC without SPF: 16 million domains with half an authentication stack. Either half alone is a partial posture. The protection only exists when SPF (or DKIM) and an enforcing DMARC policy are present together.
And beneath all of this sits the largest cohort of all: 214,276,774 domains — 56.8% of the email-graded web — publish neither SPF nor DMARC, no email-authentication posture whatsoever. That silent majority is profiled in The Silent Domain: 56.8% of the internet has no email authentication. Against that backdrop, publishing any SPF record at all already puts a domain ahead of six in ten of its peers — but only a hard-fail record backed by DMARC actually closes the door.
How to check and fix your own SPF record
You cannot fix what you have not read, and the record is public, so checking takes seconds.
Check it. The fastest route is a scanner that reads your live DNS and interprets the result rather than just printing the raw text. Check your domain free at defaults.exposed — it reads your published SPF, DKIM and DMARC records straight from public DNS and tells you not only whether an SPF record exists but whether it ends in a hard fail or a soft fail, whether it stays under the 10-lookup limit, and whether DMARC is enforcing on top. It takes about 30 seconds and needs no account. If you prefer the command line, dig +short TXT yourdomain.com returns the raw record, and you read the qualifier on the trailing all yourself.
Fix it, in order:
- Inventory every service that sends mail as you. Your mail platform, CRM, help desk, invoicing tool, newsletter provider, transactional-email service. Missing one here is the single most common cause of broken mail after tightening SPF.
- Build one record that covers them all. Use each provider’s published
include:(they document it), add any fixed IPs withip4:/ip6:, and keep the total DNS lookups under 10 — flatten or consolidate providers if you are close to the ceiling. - Publish it with
~allfirst, then move to-all. Start on soft-fail while you confirm nothing legitimate is being missed, then change the single trailing character to-allfor enforcement. This is the one place~allis the correct answer — as a short staging step, not a destination. - Layer DMARC on top. SPF only protects the visible
From:address once DMARC aligns and enforces it. Begin atp=noneto collect reports, confirm your senders align, then tighten. The grading logic is documented in the DMARC policy methodology, and the reading-the-record walkthrough is in the DMARC checker guide.
Each step is a single DNS TXT edit. The effort is in the inventory at step 1, not the typing — which is exactly why the internet is littered with records that were published once, set to ~all, and never enforced.
SPF, DKIM and DMARC: how the three fit together
Email authentication is a stack of three standards, and they only work as a set. It helps to see what each one proves:
- SPF (RFC 7208) proves that a message was sent from a server the domain authorised. It checks the envelope sender. Its weakness on its own is that it says nothing about the
From:address a human reads. - DKIM (RFC 6376) attaches a cryptographic signature to the message, letting the receiver verify the mail was genuinely authorised by the domain and was not altered in transit. Like SPF, on its own it does not require alignment with the visible
From:. The grading of the signature’s presence is covered in the DKIM exists methodology. - DMARC (RFC 7489) ties SPF and DKIM to the visible
From:domain through alignment, and — critically — tells receivers what to do when a message fails: monitor, quarantine, or reject. It is the only one of the three that turns a check result into an enforcement action on the address people actually see.
Think of it as evidence and a verdict. SPF and DKIM are two independent ways to prove a message is genuinely yours. DMARC is the instruction that says: if neither proof holds for the domain in the visible From: line, refuse the message. A domain needs at least one working proof and the enforcing verdict. The census puts full protection — SPF and DKIM and an enforcing DMARC together — at just 2.9% of the email-graded web, 10,902,284 domains. SPF is the foundation of that stack, and 61% of domains have not laid it.
What this means
For IT and operations teams, SPF is the cheapest control you own and the easiest to leave half-finished. The census figure that should sting is not the 61% with no record — it is the 56.4% of publishers who stopped at soft-fail. Those teams did the work, wrote the include: list, published a valid record, and then left the trailing qualifier at ~all, so none of it is enforced. Reading your own record, confirming it ends in -all, staying under the 10-lookup limit, and layering an enforcing DMARC policy on top is a morning’s work with a permanent payoff. The alternative is a record that documents your senders to attackers while protecting no one.
For business owners, SPF is the first brick in the wall that stops criminals sending email that looks exactly like yours — the invoices, the payment-detail changes, the “quick favour” from the boss. On its own it is not the whole wall, but without it there is no wall at all, and the census says six in ten domains are in that position. The fix is free and needs no new software: an inventory of who sends mail for you, one DNS record, and the DMARC layer that makes it enforce. Not publishing SPF is a decision to leave the door unlocked.
For MSPs and IT providers, SPF posture is a fast, defensible audit line across a whole client base. Every client’s record is public, so you can assess the entire estate without touching a single mailbox: who has no record, who is stranded on ~all, who is over the lookup limit, who has SPF but no DMARC to enforce it. At an industry-wide 38.8% publication rate and a 56.4% soft-fail rate among publishers, most estates you inherit will need exactly this remediation — and it is billable, low-risk, and visible to the client the moment they run a re-check.
FAQ
What is an SPF record?
An SPF (Sender Policy Framework) record is a TXT record published in your domain’s public DNS that lists which mail servers are authorised to send email using your domain. When a receiving server gets a message claiming to be from you, it looks up your SPF record and checks whether the sending server is on the list, then applies the verdict set by the record’s trailing all mechanism. Defined in RFC 7208, it is the oldest email-authentication standard. The August 2026 census found only 38.8% of domains — 146,413,297 of 376,928,750 email-graded — publish one at all.
What is an SPF record in email?
In email specifically, SPF authenticates the envelope sender — the hidden Return-Path / MAIL FROM address used during the SMTP handshake — and the HELO name, not the From: address a person reads in their inbox. A receiving mail server checks the sending IP against your published list and either passes, soft-fails, or hard-fails the message. Because SPF only covers the envelope, it must be paired with DMARC to protect the visible From: address. You can confirm your own domain’s SPF in about 30 seconds with a free check at defaults.exposed.
Can you have multiple SPF records?
No. A domain must publish exactly one SPF (v=spf1) record. RFC 7208 is explicit that if a receiver finds two or more SPF records on the same domain, it returns a permerror and treats the domain as having no valid policy — so a second record does not add senders, it voids your protection entirely. If you use several providers, merge them into one record using multiple include: mechanisms, keeping the total DNS lookups under the hard limit of 10. Duplicate records, usually left behind when a new provider is added, are a common and silent cause of SPF failure.
How to check an SPF record?
Two ways. On the command line, dig +short TXT yourdomain.com prints the raw record and you read the trailing all qualifier yourself — -all is enforcing, ~all is soft-fail, +all is dangerously open. Faster and clearer is a scanner that interprets the result: defaults.exposed reads your live SPF, DKIM and DMARC from public DNS and tells you whether the record is present, whether it enforces or merely soft-fails, whether it stays under the 10-lookup limit, and whether DMARC is enforcing on top. It takes about 30 seconds and needs no account.
How to fix an SPF record?
Inventory every service that sends mail as you, then build a single record combining each provider’s include: and any fixed IPs, keeping DNS lookups under 10. Publish it with ~all while you confirm no legitimate sender is missing, then change the one trailing character to -all to enforce. Finally, add an enforcing DMARC policy so the SPF result protects your visible From: address, not just the envelope. Each stage is a single DNS TXT edit. The census shows the common failure is stopping early: 86.9 million domains publish SPF but never add the DMARC that makes it count.
Data to cite
- “Only 38.8% of domains publish any SPF record — 146,413,297 of the 376,928,750 email-graded domains measured in the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “56.4% of SPF publishers — 82,539,695 domains — end their record with a soft-fail ~all, which tells receivers to accept mail that fails the SPF check rather than reject it.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “Only 38.4% of SPF publishers — 56,268,491 domains — use a hard-fail -all that a receiving server is expected to enforce.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “86.9 million domains — 23.1% of the email-graded web — publish SPF but no DMARC, so their SPF failures are never enforced against the visible From: address.” — defaults.exposed August 2026 Domain Security Census (432M domains)
- “214,276,774 domains — 56.8% of the email-graded web — publish neither SPF nor DMARC, with no email-authentication posture at all.” — defaults.exposed August 2026 Domain Security Census (432M domains)
See where your own domain stands
An SPF record is only worth publishing if it enforces — and the census says most do not. Six in ten domains publish no record at all, and of the four in ten that do, a clear majority sit on a soft-fail ~all that quietly accepts the very mail SPF exists to stop. Almost none of those owners have seen their own posture stated plainly, because the record showed up “present” somewhere and the check stopped there.
Check your domain free at defaults.exposed — it reads your live SPF, DKIM and DMARC records from public DNS and tells you instantly whether your SPF record exists, whether it hard-fails or soft-fails, whether it stays under the 10-lookup limit, and whether DMARC is enforcing on top. Takes 30 seconds. No account needed. If you want the gaps closed properly — a single clean SPF record, DKIM, and an enforcing DMARC policy done right — see how the fix works.
Read the flagship census report: The State of Domain Security 2026 →
Related from this series: SPF hard-fail vs soft-fail: why 82 million domains use the weaker setting · What Is DMARC · DMARC without SPF: 16 million domains with half a stack · The Silent Domain
Aggregate data only. Data stored and processed in the EU.
Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded from 432,127,908 scanned. All figures are counts of graded domains. References: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC).
How to cite this report
Press / blog: defaults.exposed (2026). What Is an SPF Record? (And Why 6 in 10 Domains Don’t Have One). defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/what-is-an-spf-record
Academic: defaults.exposed. (2026, August 21). What Is an SPF Record? In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/what-is-an-spf-record
In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750 graded domains)
About the defaults.exposed August 2026 Census
The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,750 of them for email authentication using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.
Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026
Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →