SPF explained: how receivers decide who may send as your domain
SPF is the oldest and most widely deployed email authentication standard. It is also the easiest to break without noticing. This guide explains how SPF actually works, the failure modes we see most often on Danish domains, and how to keep a record healthy over years of changing providers.
The problem SPF solves
SMTP, the protocol that carries all email, was designed in an era when the internet was a handful of trusted universities. Nothing in the protocol stops anyone from connecting to a mail server and claiming to be billing@yourcompany.dk. Receivers needed a way to ask: is the server delivering this message actually allowed to send for that domain?
SPF (Sender Policy Framework, RFC 7208) answers that question with DNS. The domain owner publishes a TXT record listing the IP addresses and services authorized to send on its behalf. When a message arrives, the receiving server looks at the envelope sender domain, fetches its SPF record, and checks whether the connecting IP is on the list. The result — pass, fail, softfail, neutral or an error — feeds into the receiver's filtering decision and into DMARC evaluation.
Reading a record
A typical record looks like: v=spf1 include:_spf.google.com include:sendgrid.net ip4:185.12.34.0/24 ~all. It reads left to right: mail from Google's servers passes, mail from SendGrid passes, mail from that IP range passes, and everything else soft-fails.
The include: mechanism is what makes SPF manageable — you delegate to your provider's record, and they keep their IP ranges current. It is also what makes SPF fragile: each include is a DNS lookup, and includes can nest. Your simple three-service record may resolve into a tree of ten domains behind the scenes.
The final "all" mechanism sets the default verdict. -all (hard fail) tells receivers to reject unlisted senders; ~all (soft fail) says treat them with suspicion; ?all provides no signal, and +all — which we still find in the wild — explicitly authorizes the entire internet and is worse than no record at all.
The 10-lookup limit: the silent killer
RFC 7208 caps SPF evaluation at ten DNS lookups. Every include, a, mx, ptr, exists and redirect mechanism costs one, including those inside nested includes. Exceed the limit and evaluation aborts with a permanent error — most receivers then behave as if you had no SPF at all, and your DMARC alignment fails with it.
The limit is hit gradually and invisibly. Marketing signs up for a campaign tool, IT adds a ticketing system, someone pastes in the include for a survey platform — each one works fine, until the one that pushes the tree past ten. Nothing warns you; delivery just degrades. In our audits of Danish SMB domains this is the single most common critical SPF finding.
The remedies are unglamorous but effective: delete includes for services you no longer use (records accumulate them for years), replace includes of providers with stable IP ranges by their ip4:/ip6: values directly, and check the tree before adding anything new. Our free SPF Surveyor renders the whole resolution tree with a per-branch lookup count so you can see exactly where the budget goes.
Common mistakes we flag
Multiple SPF records: a domain must have exactly one record starting with v=spf1. Two records — usually a leftover from a provider migration — cause a permanent error. Merge them into one.
The ptr mechanism: deprecated, slow, and skipped by many receivers. Replace it with explicit IPs or includes.
SPF on the wrong host: the record must sit on the domain that appears in the envelope sender. Sending services that use their own bounce domain (like most newsletter tools) need SPF there, not on your main domain — that is also why SPF alone can't protect your visible From address, and why DKIM and DMARC exist.
Believing SPF is enough: SPF checks the envelope sender, which recipients never see. A phisher can pass SPF for their own domain while displaying yours in the From header. Only DMARC, which ties authentication to the visible From domain, closes that gap.
Maintaining SPF over time
An SPF record is a living inventory of your sending infrastructure — and inventories rot. The practical routine: review the record whenever a service is added or cancelled, keep the tree at seven lookups or fewer so there is headroom, prefer -all once you are confident in the list, and monitor the record for changes you did not make, since DNS tampering and well-meaning colleagues both happen. MonitorBase's monitoring re-resolves your tree daily, alerts on any record change, and warns before the lookup budget runs out.