SPF Records That Do Not Over-Permit Senders

SPF is a TXT record that lists who may send mail for a domain. Receivers look up that record when they accept a message and compare it to the connecting IP. A missing record is a problem. A record that ends in +all or includes every SaaS you ever evaluated is a bigger problem: anyone who can send from those networks can pass SPF as you.

What SPF actually authorizes

SPF authorizes the envelope sender (the MAIL FROM / Return-Path), not the visible From header. That distinction matters for forwarding and for bounce addresses. A typical transactional setup uses MAIL FROM in the same domain as From, so a tight SPF helps DMARC later. If you bounce to a different domain, that other domain needs its own SPF.

Mechanisms you will actually use:

• ip4 and ip6: pin a specific sending address. Best when this VPS is a known sender.
• include: pull another organization's SPF (Google Workspace, SES, Mailgun). Each include costs DNS lookups.
• mx and a: authorize whatever the MX or A record currently points at. Convenient and easy to get wrong when the website IP is not the mail IP.
• redirect: replace this record with another domain's record. Rare for small setups.
• all: the default for everyone else. Use -all (fail) or ~all (softfail) in production. Never +all.

The ten-lookup cap is real

RFC 7208 says a receiver may abort SPF after ten DNS mechanisms that cause lookups (include, a, mx, ptr, exists, and nested includes). Go over ten and the result is permerror, which DMARC treats as a failure. Marketing tools love to hand you include:vendor.example.net. Three vendors plus Google plus your own mx already sit near the cap.

Count before you publish. Flattening (replacing an include with the ip4 records it currently resolves to) lowers lookup count but means you must refresh when the vendor changes IPs. Prefer ip4 of your own VPS plus one or two includes you truly send through.

Publish one TXT, not a pile

There must be exactly one SPF TXT on the name you send as. Two SPF records make permerror. Merge mechanisms into a single string. Keep the string under 255 characters per TXT chunk; most zones accept a quoted record under 450 characters total if you split quotes, but short is better.

# Check what is live before you edit
dig +short TXT example.com
# Example of a tight record for one VPS plus Google Workspace
# v=spf1 ip4:203.0.113.40 include:_spf.google.com -all

If this domain never sends from the VPS and only uses an ESP, do not list the VPS IP. Listing an IP is a promise that mail from that address is you. A compromised WordPress box on that IP then passes SPF.

Qualifiers: -all versus ~all versus ?all

-all means fail: this IP is not us. ~all means softfail: receivers usually still accept and mark. ?all means neutral, which is close to having no policy. During a migration, ~all for a week is reasonable while you watch DMARC reports. Staying on ~all for years trains receivers that your SPF does not mean anything.

+all and ip4:0.0.0.0/0 are how domains get used in phishing kits. Do not copy a vendor snippet that ends that way. ptr: is deprecated and costs lookups; do not use it.

; good: one VPS sender, fail everyone else
example.com.  IN TXT  "v=spf1 ip4:203.0.113.40 -all"

; good: VPS plus one ESP include
example.com.  IN TXT  "v=spf1 ip4:203.0.113.40 include:mailgun.org -all"

; bad: authorizes the web A record, every MX, and the world
example.com.  IN TXT  "v=spf1 +a +mx +all"

Operational checks

After publishing, send a message and read Authentication-Results on the received copy. You want spf=pass and the smtp.mailfrom matching the domain you intended. Tools such as open-spf checkers still help, but a real Gmail header is the ground truth.

If you host mail-from on a subdomain (bounce.example.com) keep SPF there too. A 404 on that name is a fail, not a pass. And remember: SPF does not survive arbitrary forwarding. That is why DKIM and DMARC exist. SPF is necessary and not sufficient.

Takeaway

List only the IPs and includes that truly send, stay under ten lookups, and end with -all once you have watched a week of traffic. You can spin up an Ubuntu 24.04 instance on Netbay in under 60 seconds, pin its static Lucknow IP in SPF, and leave every other network out — netbayhosts.in.