Build your SPF record
What the record actually says
An SPF record is one line of text published as a TXT record on the domain. It lists the servers allowed to send mail with an address at that domain, and it ends by saying what to do about everybody else.
- v=spf1
- Marks the line as an SPF record. A TXT record that does not start with this is not SPF and is ignored.
- ip4, ip6
- A single address or a range that may send. These cost no DNS lookup, which makes them the cheapest way to authorise your own server.
- a, mx
- The addresses of the domain itself, and the hosts named in its MX records. One DNS lookup each.
- include
- Hands the question over to the record of another domain, which is how a mail provider keeps its own sending addresses up to date. At least one DNS lookup, often several.
- -all, ~all
- The closing term. Everything that did not match one of the mechanisms before it falls to this one.
The terms are read from left to right and the first one that matches decides the answer, so the record puts the addresses first and the includes after them.
How this SPF record generator counts DNS lookups
RFC 7208 allows no more than ten DNS lookups while a record is evaluated, and the lookups made inside an include count towards the same ten. Some providers publish one flat record that costs exactly one lookup. Others include further records of their own, and then a single line in your record can quietly cost half of the ten by itself.
That is why this page does not stop at writing the line out. It follows the record it has just built, expands every include the way a receiving mail server would, and prints the running total with the cost of each entry next to it. The number is measured on the spot, not guessed from a table, because provider records change without telling anyone. Cross the limit and receivers return permerror, which most of them treat exactly like a failed check, so a record over the limit protects nothing and breaks delivery at the same time.
If the count comes back close to ten, the way out is usually one of two things: remove a service that is no longer in use, or replace one include with the ip4 ranges behind it. Ranges cost nothing to evaluate, but they stop being correct the day the provider changes them, so keep them for your own servers.
Only one record, and never +all
A domain may publish exactly one SPF record. Two of them are a permerror for every receiver, even when each line is correct on its own, and this is the single most common way a working setup gets broken: a new service is added, its record is pasted in next to the old one, and mail starts failing for everything. When a service is added, its include goes into the record that is already there.
The builder refuses two things on purpose. It will not put a second v=spf1 line into a record, and it will not write +all. A record ending in +all authorises every server on the internet to send mail as your domain, which is the same as publishing no record at all, except that it also looks deliberate.
Start with ~all, finish with -all
With -all you state that no other server is authorised, and receivers may refuse the message outright. With ~all the message is accepted and marked as suspicious, which usually means the spam folder.
The order that works is: publish the record with the senders you know about, watch what actually fails for a week or two, then switch the last term to -all. Domains lose real mail by going to -all before anyone has checked the invoicing system, the newsletter tool and the contact form on the website. Those are the three that get forgotten.
Do not use ?all. It says the record has no opinion, which is what receivers assume in the absence of a record anyway.
After you publish it
Add the record in the DNS zone of the domain as a TXT record on the name @, which is the domain itself, and give a resolver as long as the TTL to notice it.
- Check the published record to see what a receiver reads, with the whole include chain expanded.
- Generate a DKIM record. SPF stops matching as soon as a message is forwarded, DKIM survives it.
- Check the DMARC policy. Without DMARC nobody acts on the two results above, and no reports come back.
- Look at the MX records if you are not sure which service receives mail for the domain in the first place.