Sender Policy Framework (SPF) is a DNS-based mechanism that lets the owner of a domain publish, in an authoritative way, which IP addresses are permitted to send mail on that domain's behalf. It is defined in RFC 7208. The receiving mailbox provider queries the sending domain's SPF record and compares the connecting IP against the permitted list.
SPF alone does not guarantee inbox placement, and it does not authenticate the message contents. Its purpose is narrower: to allow receivers to detect and reject envelope-sender spoofing that would otherwise be indistinguishable from legitimate mail.
Anatomy of an SPF record
An SPF record is a TXT record on the return-path domain. It begins with the version tag v=spf1, followed by a sequence of mechanisms and a required qualifier at the end.
example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.northboundmail.net -all"The most common mechanisms are ip4, ip6, a, mx, include and all. Qualifiers precede a mechanism: '+' pass (default), '~' softfail, '?' neutral, '-' fail. The final mechanism should be either -all (fail) or ~all (softfail) — never +all, which authorises the entire internet.
The 10 DNS lookup limit
SPF evaluation is capped at 10 DNS lookups. Each include, a, mx, ptr and exists counts. Exceed the limit and the record evaluates to PermError, which most receivers treat as no SPF at all. This is the single most common SPF failure mode.
Common causes: multiple ESP includes, a corporate primary domain that has grown organically over years, or aggressive use of include: to organise per-department policies. The fix is not to add more includes but to flatten — resolve the included records to their underlying IP ranges and publish them directly. Flattening must be maintained: when the upstream provider changes their IPs, the flattened record must be regenerated.
Alignment and DMARC
SPF authenticates the envelope sender (Return-Path / MAIL FROM), not the visible From: header. For DMARC, SPF must align — the envelope-sender domain must match the header From domain, either exactly (strict) or on the organisational domain (relaxed). If SPF passes but does not align, DMARC will fail on the SPF axis and rely on DKIM.
What SPF does not do
- Does not sign message contents (DKIM does)
- Does not survive forwarding (the forwarding server becomes the envelope sender)
- Does not authorise senders — only rejects unauthorised ones
- Does not by itself protect against spoofing of the visible From: header
Common failure patterns
PermError from lookup overflow. Multiple SPF records on the same domain (invalid — only one is permitted). SPF records with typos in mechanism names (silently evaluated as none). Delegated sending platforms not included. Third-party notification services (billing, CRM) whose IPs change without notification.
Recommended posture
Publish a single SPF record per sending domain. End with -all for strict policy or ~all where you cannot yet enumerate all senders. Monitor DMARC aggregate reports to catch unauthorised sources before switching to -all. Flatten includes if you are near the 10-lookup limit. Review the record whenever a new ESP or notification service is added.
Related articles
- DKIM ExplainedDomainKeys Identified Mail — how signing works, selector strategy, key length and rotation, and what DKIM cannot do.
- DMARC GuideHow DMARC ties SPF and DKIM together, staged policy rollout from monitor to reject, and how to use aggregate reports.
- Google Postmaster GuideHow to set up Postmaster Tools, what each metric means, and how to interpret the reputation graph.
- PowerMTA OptimizationVMTA design, queue tuning, per-domain policy, and the configuration mistakes that quietly cost inbox rate.
- IP Warm-upHow to warm a new IP without wasting weeks or torching reputation. Volume curves, segmentation, and when to stop.
- Dedicated vs Shared IPWhen each is appropriate, the volume thresholds that make dedicated worthwhile, and the myths on both sides.