Demystifying SPF: The Email Bouncer Explained

Somewhere in your DNS zone, there is a TXT record starting with v=spf1. Most admins know it exists. Fewer know what it actually does. Even fewer want to touch it, because “it works” and nobody wants to be the reason it stops working.

Let’s fix that.

SPF Is A Bouncer, Not A Bodyguard

Think of SPF as the bouncer standing outside the email club.

The bouncer has one job: check if your name is on the guest list. That’s it. The bouncer does not check what you’re carrying, whether you’re planning to start a fight inside, or whether your intentions are pure. If your name is on the list, you’re in.

SPF (Sender Policy Framework) works the same way. It publishes a list of mail servers that are allowed to send email for your domain. When a receiving mail server gets a message claiming to be from yourcompany.com, it checks whether the sending server’s IP address is on that guest list.

That’s the entire job. SPF does not check content. It does not check for phishing. It does not know if the email is polite. It only checks: is this server allowed to speak for this domain?

What An SPF Record Actually Looks Like

A basic SPF record for a company using Microsoft 365 might look like this:

v=spf1 include:spf.protection.outlook.com -all

Broken down:

v=spf1 – this is an SPF record, version 1. There is no version 2, don’t go looking for it.
include:spf.protection.outlook.com – trust the servers listed by Microsoft 365 to send mail for this domain.
-all – anything not explicitly listed above should be rejected outright.

Simple, clean, and exactly one guest list entry. Most SPF records don’t stay this tidy for long, but we’ll get into that in the next article.

What SPF Does Not Do

This is the part that trips people up, so let’s be blunt about it:

SPF does not verify the “From” address a human actually sees in their inbox.
SPF does not stop spoofing on its own.
SPF does not guarantee a message is legitimate.
SPF does not survive email forwarding well SPF Breaking During Forwarding.

SPF checks the envelope sender, which is a technical field most people never see. This is why SPF alone is not enough. It needs to work alongside DKIM (which verifies the message wasn’t tampered with) and DMARC (which ties the two together and tells receiving servers what to do when something fails).

SPF is one bouncer. DKIM and DMARC are the rest of building security. You need all of them working together, not just the one guy checking the guest list at the door.

Why SPF Still Matters

Even with its limitations, a properly configured SPF record:

Reduces the chance of your domain being used to spoof outgoing spam
Improves mail deliverability, since many receiving servers score unauthenticated mail lower
Is required (or strongly expected) by most modern email authentication policies, including DMARC enforcement

Skipping SPF entirely is like removing the bouncer altogether and hoping nobody sketchy shows up. They will show up. They always do.

Janitor Tip 🧹

If you’ve never checked your own SPF record, do it now. Run a quick DNS TXT lookup on your domain and look for v=spf1. If you find more than one SPF record, congratulations, you already have a problem, and article two is calling your name.