What Is an SPF Record? Email Sender Checks

A team I worked with couldn't understand why their invoices kept landing in customers' spam folders. The emails were plain, legitimate, sent from their own domain. The problem wasn't the content at all — it was that nothing, anywhere, had ever told the receiving mail servers that their new sending service was allowed to send on their behalf. Their SPF record still listed only the old provider. One line of DNS, out of date, was quietly routing real invoices into junk.

SPF is one of those pieces of plumbing you never think about until mail stops arriving. Here's what it is and why it matters.

The problem SPF solves

Email has an embarrassing secret: the 'from' address is just text the sender types. Nothing in the original design of email stops me from putting your domain in the 'from' field of a message I send. That's how phishing and spoofing work — a forged email that claims to come from your bank, your boss, or your own domain.

SPF, which stands for Sender Policy Framework, is the fix. It lets a domain owner publish a public, authoritative list of which mail servers are actually allowed to send email using that domain. Receivers can then check incoming mail against that list and treat anything from an unapproved server as suspect.

Think of it as a mailroom's approved-sender list

Picture a company mailroom that only accepts outgoing post from a short list of authorized departments. A courier shows up claiming to carry mail 'from Acme Corp'. The mailroom clerk checks the posted list: is this courier one Acme actually authorized? If yes, it goes out under Acme's name. If the courier isn't on the list, the clerk sets it aside — maybe it's fine, maybe it's someone forging Acme's letterhead, but it doesn't get the company's trust automatically.

An SPF record is that posted list, and the receiving mail server is the clerk. The domain owner decides who's on the list; every receiver in the world can read it and act accordingly.

Where the list actually lives: DNS

The list is published as a TXT record in your domain's DNS — the same DNS that maps your domain name to a server. Because DNS is public and global, any receiving server can look it up in milliseconds. If you've never seen your domain's DNS records, you can read what's currently published with a DNS checker; an SPF record shows up as a TXT entry beginning with v=spf1.

A real one looks like this:

v=spf1 include:_spf.google.com ip4:198.51.100.5 ~all

Short as it is, every piece is doing a job:

• v=spf1 — the version tag. It marks this TXT record as an SPF record so receivers know how to read the rest.
• include:_spf.google.com — a mechanism that says 'also trust everything in Google's SPF record'. You use include: for third-party services that send on your behalf — Google Workspace, Microsoft 365, a marketing platform, a help desk. Each service publishes the servers it uses, and you just reference it.
• ip4:198.51.100.5 — approves a specific server by its IP address. You'd use this for your own mail server or an app server that sends directly.
• ~all — the catch-all at the end, which decides what happens to any server not matched above.

The ending matters most: -all vs ~all

That final mechanism is the one people get wrong, and it's the one that decides how strict your policy is:

• -all (hard fail) — reject any sender not on the list. This is the strong stance: if it's not authorized, don't deliver it.
• ~all (soft fail) — accept unlisted senders but mark them suspicious. This is the cautious stance.
• +all — approve everyone. Never use this; it's the same as having no protection at all.

A sensible path is to start with ~all while you make sure you've listed every service that sends mail for you, then tighten to -all once you're confident nothing legitimate is being missed. The team with the lost invoices had the opposite problem: a strict record that simply didn't include their new sender, so real mail failed the check.

SPF is one of three, not the whole story

SPF answers exactly one question — is this server allowed to send for this domain? It doesn't prove the message wasn't altered along the way, and it has a known weak spot: it checks the technical envelope sender, not the 'from' address a human actually sees. That's why it comes with two companions:

• DKIM adds a cryptographic signature to each message, proving it genuinely came from your domain and wasn't tampered with in transit.
• DMARC ties SPF and DKIM together, tells receivers what to do when a message fails both, aligns the checks with the visible 'from' address, and sends you reports on who's sending as you.

You want all three. SPF is the foundation — the 'who may send' layer — and the other two build authenticity and enforcement on top of it.

Getting it right

If your legitimate email is landing in spam, your SPF record is one of the first things to check. Look up what's currently published with a DNS checker and make sure it lists every service you send from — your mail provider, yes, but also the marketing tool, the invoicing system, the support desk. Each one that sends as you needs to be covered by an include: or an ip4: entry, and a domain can only have one SPF record, so they all live on that single line.

SPF sits alongside the other domain-health signals worth keeping an eye on — the age and reputation of the domain you send from both feed how much receivers trust your mail, which you can sanity-check with a domain age checker and a domain rating checker. If you're setting up a new sending domain from scratch, it's worth understanding what domain rating measures and how rating differs from authority, since a brand-new domain starts with no reputation and SPF is only the first of several trust signals you'll build.

An SPF record is a small thing — one line of DNS text — doing an outsized job: it's the public guest list that lets the rest of the internet tell your real email from a forgery. Publish it, keep every sender on it, and tighten it once you're sure, and you take your domain off the easy-to-spoof list for good.