What is SPF? The guest list for your domain's email

Sender Policy Framework (SPF) is the oldest of the three main email authentication standards, and the easiest to explain: it is a guest list. You publish, in your domain's DNS, a list of the servers permitted to send email on your domain's behalf. Receiving mail servers check arriving mail against the list. On it: pass. Not on it: fail.

Simple in concept. In practice, SPF records are among the most commonly broken pieces of configuration we see - usually silently, and usually because of one specific limit that almost nobody knows about until it bites. Let us walk through it.

How SPF works

When your organisation sends an email, it travels from a sending server (your mail provider's, or that of a service sending on your behalf) to the recipient's server. The receiving server looks at the domain in the message's return address, fetches that domain's SPF record from DNS, and asks one question: is the server that delivered this message on the list?

A typical record looks like this:

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

Reading it in plain English: "Microsoft 365 may send for us; our CRM platform may send for us; nobody else may." Each include: pulls in another provider's list of servers. The final tag matters:

• -all - anything not listed should fail (the strict, correct ending);
• ~all - anything not listed is a "softfail", treated with suspicion but usually delivered (a sensible stage while testing);
• +all - anyone may send as us (this appears in real records more often than you would hope, and it makes the entire record pointless).

The 10-lookup limit: how SPF breaks silently

Here is the trap. The SPF standard caps the number of DNS lookups a receiving server will perform while evaluating your record at ten. Every include: costs at least one lookup - and many providers' includes contain further includes inside them, each costing more.

A growing business accumulates senders: the mail provider, the newsletter tool, the accounting package, the helpdesk, the e-signature platform, the recruitment system. Each one's setup guide says "add our include to your SPF record", and each addition is individually reasonable. Then one day the record quietly crosses ten lookups - and from that moment, evaluation fails with a "permerror". Depending on the receiver, your legitimate email may start failing authentication.

Nothing announces this. No alert fires. Email mostly still arrives, until it increasingly does not - landing in spam, or failing DMARC checks. We regularly find long-broken SPF records on domains whose owners were certain everything was fine. It is one of the first things the SealedMail health check examines.

Other common mistakes

• Two SPF records. A domain must have exactly one. Two records (often one from the mail provider and one from a marketing tool, each pasted in separately) cause a permanent error. The fix is merging them into one.
• Forgotten senders. A legitimate service nobody added to the list, whose mail fails - often discovered only when invoices stop arriving.
• Stale includes. Entries for services the business stopped using years ago, wasting lookups and authorising infrastructure you no longer control.
• Ending in +all or omitting the all tag - both leave the door open.

What an SPF failure actually means

When a message fails SPF, the receiving server learns that the delivering server was not on your list. By itself, SPF does not dictate what happens next - some receivers junk the message, some just score it negatively, some deliver it anyway. That indecision is one of SPF's fundamental limits.

And a failure is not always an attack. Forwarding is the classic false alarm: when someone auto-forwards your genuine email onwards, the final delivering server is the forwarder's - not on your list - so SPF fails on a perfectly legitimate message.

Why SPF alone is not enough

Three structural gaps mean SPF cannot carry email security by itself:

1. It checks the wrong address. SPF validates the hidden technical return address (the "envelope from"), not the From address your recipient actually sees. A fraudster can pass SPF using their own domain in the envelope while displaying your domain to the victim.
2. Forwarding breaks it, as above - so receivers cannot treat SPF failure as proof of fraud.
3. It gives you no feedback. SPF reports nothing back to the domain owner. You cannot see who is failing, who is spoofing, or whether your own record has broken.

The answers come from the other two standards. DKIM (DomainKeys Identified Mail) adds a cryptographic signature that survives forwarding - explained in What is DKIM?. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties both checks to the visible From address, tells receivers what to do on failure, and sends you daily reports - explained in What is DMARC?. SPF is a necessary layer of that stack, not a substitute for it.

Check yours in two minutes

Most SPF problems - the lookup limit, duplicate records, stale includes, a soft ending - are invisible until something fails. SealedMail's Free Domain Health Check audits your SPF record alongside DKIM, DMARC, MTA-STS, TLS-RPT, BIMI and blacklist status, and emails you a clear, scored certificate explaining what is right, what is broken and what it means. Free, no sign-up, no sales call.