Pick the services that send mail for your domain and get a valid SPF record with the real number of DNS lookups. Load the record you publish today, merge it with the new one, check it against live DNS. Free, no sign-up.
An SPF record is a TXT record in the DNS of a domain that lists which mail servers may send mail for that domain. Receiving servers compare the sending server with that list and treat mail from anyone else as suspicious or reject it. SPF is defined in RFC 7208 and always starts with v=spf1.
The generator on this page builds that record from the services you actually use, counts the DNS lookups it causes and warns before it crosses the limit of ten, the most common reason an SPF record that looks correct does not work at all.
1. Tell the generator who sends your mail. Tick your mailbox provider, your newsletter tool and every other service that sends with your domain in the sender address: the shop, the help desk, the CRM, the invoicing tool. If your own server sends mail, tick mx or enter its address under IPv4.
2. Publish one TXT record. Copy the value into the DNS of your domain as a TXT record on the domain itself. If a record starting with v=spf1 already exists, replace it. Do not add a second one: two SPF records are an error, and receivers then ignore SPF entirely.
3. Check it. “Check with live DNS” resolves every include of the new record and counts the lookups the way a receiver does. After publishing, the Email Security Check reads SPF together with DKIM and DMARC and shows whether the three agree.
Already have a record? Enter your domain at the top and press “Load published record”. The generator reads what you publish today, ticks the services it recognises and keeps everything else, so you extend the record instead of starting over and losing a sender nobody remembered.
Every DNS panel asks for the same three things: a type, a name and a value. Only the name field differs, because panels disagree about how to write “the domain itself”.
| What your panel shows | What to enter as name | Seen at |
|---|---|---|
| A field “Name” or “Host” | @ |
Cloudflare, IONOS, GoDaddy, Namecheap |
| A name field with the domain already appended | leave it empty | Plesk, AWS Route 53, many hosting panels |
| A field that wants the full name | example.com. with the trailing dot |
BIND-style editors, some registrars |
| A zone file | example.com. 3600 IN TXT "v=spf1 ..." |
your own name server |
Type is always TXT. The old record type SPF (type 99) was retired in 2014 and is ignored by receivers; if your panel still offers it, do not use it. The TTL can stay at the default. Enter the value without quotes unless the panel asks for them, and if it splits a long value into several quoted strings, that is fine: receivers join them back together without a space.
A receiver evaluating SPF may perform at most ten DNS lookups for one record (RFC 7208, section 4.6.4). It counts every include, every a, mx, ptr and exists, and the redirect modifier, and it counts them across the whole tree: an include that contains three more includes costs four. At the eleventh lookup the receiver stops and returns permerror, which most receivers treat exactly like a missing SPF record.
The trap is that nothing looks wrong. The record is short, the syntax is valid, every service is listed. It breaks when a provider adds one more include to its own record, which you never see. This is why the generator shows the cost next to every service, and why “Check with live DNS” recounts the whole tree the moment you press it.
include:, a, mx, ptr, exists: and redirect=, each occurrence, including those inside every included record. A second, separate limit applies to void lookups: names that return no record at all. More than two of them are also a permerror.
ip4:, ip6: and all. Listing your own server as an address instead of a or mx saves a lookup each, at the price of having to update the record when the address changes.
Measured on 19 October 2026 against public DNS, counted the way a receiver counts. A provider can change its record any day, so treat these as a snapshot and let the live check have the last word.
| Service | Include | Lookups |
|---|---|---|
| Microsoft 365 | spf.protection.outlook.com |
1 |
| Google Workspace | _spf.google.com |
1 |
| IONOS | _spf-eu.ionos.com |
1 |
| Brevo | spf.brevo.com |
1 |
| SendGrid | sendgrid.net |
2 |
| Proton Mail | _spf.protonmail.ch |
2 |
| GoDaddy | secureserver.net |
3 |
| Namecheap Private Email | spf.privateemail.com |
4 |
| Mailgun | mailgun.org |
5 |
| Zoho Mail | zoho.com |
5 |
| Freshdesk | email.freshdesk.com |
7 |
Freshdesk alone uses seven of ten. Combined with Zoho Mail and anything else, the record is over the limit before a single own server is listed. The generator has 34 services with their measured cost; for a domain it does not know, the live check counts the real number.
We read the SPF records of the 1,000 highest-ranked .de domains in the Tranco list (list 467YX) on 19 October 2026, with the same counting rules the generator uses.
| Finding | Domains |
|---|---|
| No SPF record at all | 112 |
Ends with -all |
507 |
Ends with ~all |
320 |
Ends with ?all, which protects nothing |
22 |
Only a redirect= to another record |
33 |
| More than 10 lookups, so SPF fails everywhere | 17 |
| 8 to 10 lookups, one change away from failing | 144 |
| Longer than 255 characters | 79 |
Seventeen large German domains publish an SPF record that no receiver can evaluate, and almost every sixth record with SPF sits at eight to ten lookups. None of them would have passed the generator without a warning. The method and the raw data are documented; the count follows RFC 7208 exactly as described above.
The last term tells receivers what to do with a server that is not on the list.
~all (softfail) marks such mail as suspicious but asks the receiver not to reject it outright. It is the right choice while you are still finding every service that sends for you, because a forgotten sender then lands in spam instead of disappearing.
-all (fail) says: whoever is not listed is not us. Switch to it once the DMARC aggregate reports of a few weeks show no legitimate source failing SPF. Under DMARC the difference shrinks, because DMARC decides on its own policy; without DMARC, -all is the stronger statement.
?all (neutral) and +all make the record pointless. +all even authorises every server on the internet to send as your domain. The generator does not offer it.
ip4 range with a /33 or an IPv6 address under ip4 is left out of the record and reported, instead of breaking it.SPF checks the envelope sender, the address servers use among themselves for bounces. It does not check the From line a reader sees in the mail program. A forged message can pass SPF for the attacker’s own domain and still show your name in From.
What closes that gap is DMARC: it requires the domain in From to match a domain that passed SPF or DKIM, and it tells receivers what to do when it does not. SPF also breaks when mail is forwarded, because the forwarding server is not on your list; a DKIM signature survives forwarding. A domain is only properly protected with all three: SPF, DKIM and DMARC.
No. A domain may publish exactly one TXT record that starts with v=spf1. With two or more, receivers return permerror and ignore SPF for the domain completely. If several services each tell you to “add their SPF record”, combine their include entries into one record, which is what the generator does.
Start with ~all while you are still collecting every service that sends mail for you, so a forgotten sender lands in spam instead of being rejected. Switch to -all once DMARC reports show that all legitimate mail passes. With DMARC at quarantine or reject, the policy there matters more than the qualifier here.
The receiver stops at the eleventh lookup and returns permerror. Most receivers then treat the domain as if it had no SPF record, and DMARC can only pass through DKIM. Remove services you no longer use, or replace a service include with the ip4 and ip6 ranges it stands for, accepting that you then have to follow its changes yourself.
No. The record is built in your browser. Only the two buttons that need DNS ask our server: “Load published record” reads the public TXT record of the domain, and “Check with live DNS” resolves the includes of your record. Neither stores the record. Usage is counted per tool without your address.
Wait until the change has reached the resolvers, usually minutes, sometimes a few hours depending on the TTL of the old record. Then load the record here again or run the Email Security Check, which validates SPF together with DKIM and DMARC. The DNS Checker shows whether resolvers worldwide already see the new value.
Only if those servers send mail. mx authorises the servers in your MX record, which receive mail and often do not send any; a in turn authorises the web server, which matters if a contact form or a shop sends directly from it. Each costs one lookup, so leave out what you do not need.
No. SPF only checks the envelope sender, not the From address a reader sees. Without DMARC, an attacker can still put your domain in the From line. SPF is the first of three records; DKIM signs the message and DMARC decides what happens when neither matches your domain.
The record is assembled in the browser from the services, addresses and the qualifier you choose. Lookup costs for the 34 presets were measured on 19 October 2026 by resolving each include recursively against public DNS. For any other include the generator counts one lookup and marks the total as a minimum until you run the live check.
“Load published record” queries the TXT records of the domain through our resolver and runs the same validator as the Email Security Check, including the recursive lookup count. “Check with live DNS” resolves every include of the record you built, in parallel and with a loop guard, and reports the cost of each one, which is the number a receiver will see today. Both requests count against the daily limit of the free tools.
What the tool cannot know: which services really send for your domain. A service that sends with your address and is missing from the record fails SPF, and no checker can tell that from DNS alone. The DMARC aggregate reports can, which is the reason to set up DMARC right after SPF.