SPF Record Generator

Getting the record right

The first rule is to list everyone who sends as your domain. A service you forget is mail that starts failing authentication. People usually remember the mailbox provider and the marketing platform, then forget transactional mail from the application, CRM notifications, and the support desk replying from its own address.

The second rule is to leave nothing stale. An include left over from a service you no longer use burns one of your ten lookups and keeps authorisation with someone who should not have it.

About the ten-lookup limit

RFC 7208 permits at most ten DNS lookups per evaluation. The include, a, mx, ptr, exists mechanisms and the redirect modifier each cost one. ip4 and ip6 are free, costing no DNS query is involved.

Go over and evaluation returns permerror, which receivers treat as an SPF failure even though the record looks entirely normal. A counter showing eight or nine means the headroom is gone: one more service will break it.

Choosing a policy

• -all — anything unlisted is rejected. The recommended end state.
• ~all — marked suspicious but delivered. Sensible during rollout.
• ?all — gives receivers no signal, so there is little point to it.
• +all — authorises the entire internet. Deliberately not offered here: it is worse than having no SPF at all.

The ten-lookup limit

The real constraint on SPF is not record length but the number of DNS lookups needed to expand it. The include, a, mx, ptr and exists mechanisms and the redirect modifier each spend one, counted recursively, somebody else's include may hide three more inside it.

At the eleventh lookup the check returns permerror and SPF fails for everyone. What makes it treacherous is the timing: the breakage does not appear when you edit the record, but on the day some service quietly adds an include to theirs, and yours stops working on its own.

The practical ceiling is three or four sending services. When that is not enough: drop includes you no longer use, move some sending onto a subdomain with its own record, or replace an include with explicit ip4 ranges where the provider publishes a stable list.

What SPF does not do

SPF validates the envelope address — Return-Path — not the From the recipient actually sees. The two can differ, and SPF does not catch forgery of the visible sender: a message with someone else's From passes happily as long as the envelope belongs to the sender.

Second, SPF breaks on forwarding. A recipient forwards to another mailbox, the message arrives from the forwarding server's IP, that IP is not in your record, and the check fails. This is exactly why DMARC accepts a pass from either mechanism: DKIM survives forwarding, SPF does not.

One record per domain

Two v=spf1 records on the same name do not add up, and they produce a permerror, and SPF then fails for everyone. The situation is typical after connecting a second sending service: instead of editing the existing record, someone adds another one beside it.

The correct approach is a single line: one v=spf1, every required include in sequence, one terminating mechanism. Subdomains do not inherit the parent record either, news.example.com without its own SPF record counts as a domain with no SPF at all.

What to do when you blow the budget

• Remove what is unused. Services abandoned years ago sit in the record spending lookups.
• Split sending across subdomains: transactional from one, marketing from another. Each gets its own record and its own budget.
• Replace an include with explicit ip4 ranges where the provider publishes a stable list. That is SPF flattening, and it it works, but it means watching for changes on their side.

Which mechanism to reach for

Four cover essentially everything. include delegates to another domain's record and is what every sending service hands you, so it is also the one that spends your lookup budget. ip4 and ip6 name addresses or ranges directly and cost nothing, which makes them the right choice for your own mail server on a fixed address.

a and mx authorise whatever the domain's own A or MX records point at. Convenient when mail leaves from the same host that receives it, and quietly dangerous otherwise: change hosting and the SPF record silently starts authorising a different machine.

ptr is deprecated. It is slow, unreliable, and several providers ignore it outright. If a vendor guide still tells you to use it, that guide has not been updated in a decade.