Free tool
Build your SPF record
Tick whoever sends email on your behalf and the record writes itself on the right. The counter follows the ten DNS lookups RFC 7208 allows for a whole check: that is what breaks real companies' records, long before syntax ever does.
Your record
v=spf1 -all
- This record authorizes nobody. Published as it stands on a domain that sends email, it makes every message fail. Tick at least your mailbox provider — unless the domain sends nothing at all, in which case “v=spf1 -all” is the right answer.
Where to publish it
- Type
- TXT
- Name
- @
- Value
- v=spf1 -all
- TTL
- 3600
SPF goes at the root of the domain, in a TXT record. It REPLACES the one already there: two SPF records on one name make the check fail instead of adding up (RFC 7208 § 3.2). If you already have one, merge the two into a single record before you publish.
The mechanism
An include isn't a line, it's a door
The builder's counter sees what you write. The server receiving your message opens each include, then the includes behind those, and keeps going. Unfold the tree and you're doing its job — that total is the one measured against the limit.
What you wrote
5
DNS lookups
What the server has to resolve
5
DNS lookups — limit: 10
v=spf1
include:_spf.example.comyour mailbox providerinclude:_spf.example.netyour newsletter toolinclude:_spf.example.orgyour invoicing softwaremxthe servers listed in your MXayour domain's own address
-all
5 lookups out of ten. There's room left — right up until one of your providers adds an include on their side, which they'll do without telling you.
The limit of ten terms that cost a DNS query — include, a, mx, ptr, exists, redirect — is set by RFC 7208, § 4.6.4; past it, the checker has to return permerror. The ip4, ip6 and all mechanisms cost no lookup. The names above are examples (RFC 2606): a provider's internal structure changes without notice.
A correct SPF record is not enough on its own
SPF says who is allowed to send. It doesn't tell the recipient what to do when the check fails, and it doesn't survive a forwarded message. DMARC gives the instruction, DKIM does the signing. The three work together — and the day a contractor replaces your record with their own, not one of them says a word.
What breaks while nobody is looking
You publish an SPF record once and forget it. Then a newsletter tool gets added without touching the zone, a host changes its IP ranges, a contractor overwrites the record while installing a form. Mail still goes out — it just lands in the spam folder, and that's invisible from the inside. DomainVigil rereads your SPF, your DMARC and your DKIM keys around the clock, and writes to you when one of the three moves.
The limit
Ten lookups. The eleventh voids the record.
RFC 7208 caps a whole SPF check at ten DNS lookups. Past that, the verifier returns a permanent error: neither a pass nor a fail, and nothing left to hold against a spoofed sender.
- 10DNS lookups for the whole check
- 0lookups charged by ip4, ip6 and all
- 2void lookups are enough to break it
Reading the result
Three things to watch while you tick.
- The lookup counter, green
- Six lookups or fewer: you have room to spare, even if your includes hide more. That's the comfortable zone.
- The counter, amber
- Seven or more lookups at the first level. The real count is almost always higher, because an include pulls in the provider's entire SPF record, nested includes and all. Time to swap an include for the address ranges it publishes.
- The counter, red
- More than ten lookups. The check stops on a permanent error, and the result is neither a pass nor a fail: it's as if you had no SPF at all, except your DMARC reports fill up with errors.
- The length
- Under 255 characters, the record fits in a single TXT string and works everywhere. Above that, your host has to split it — most do.
- “This record authorizes nobody”
- You picked a verdict without listing a single sender. That's the right answer for a domain that sends nothing, and a total mail outage for every other one.
- The “where to publish it” summary
- Type TXT, name at the root, value as shown. The part that trips people up is written underneath: an SPF record replaces the previous one, it doesn't add to it.
The mistakes that break an SPF record
All five turn up in real records, and none of them throws a visible error when you publish.
Two SPF records on the same domain
What causes it: A contractor added theirs next to the existing one instead of merging. Both are syntactically valid, and the zone editor takes both.
What fixes it: RFC 7208 § 3.2 is explicit: several records give a permanent error, not a union. Merge the terms of both into one record and delete the other.
The ten-lookup limit is exceeded and nobody knows
What causes it: Each include pulls in the provider's complete SPF record, including the includes inside it. Four includes at the first level can cost twelve.
What fixes it: Count the real total, not the number of lines. Swap the includes of services with stable address ranges for ip4 mechanisms, which cost nothing.
The “ptr” mechanism is still there
What causes it: It comes from old tutorials. It asks the recipient to resolve the reverse name of the sending address, which is slow and easy to fool.
What fixes it: RFC 7208 § 5.5 says this mechanism SHOULD NOT be published. Take it out and list the addresses instead.
A domain that sends nothing has no SPF record
What causes it: SPF only gets published on domains that send, which leaves the rest — redirect domains, defensive registrations, retired brands — free to be spoofed.
What fixes it: Publish “v=spf1 -all” on each of them, with a DMARC record at “p=reject”. Nobody is allowed to send on their behalf, and that's exactly what you mean.
SPF is correct and the mail still lands in spam
What causes it: SPF doesn't survive forwarding: a forwarded message arrives from the server that forwarded it, an address you never listed. Without DKIM, nothing is left to attest to the origin.
What fixes it: Sign your mail with DKIM and publish a DMARC record. DMARC accepts a message where SPF OR DKIM passes: the signature survives forwarding, the address doesn't.
SPF mechanisms and what each one costs
The limit is ten DNS lookups for the whole check (RFC 7208 § 4.6.4). When an SPF record stops working, this column is the only one that matters.
| Term | What it authorizes | DNS lookups |
|---|---|---|
| ip4: | One IPv4 address or a range, written with its prefix length. | 0 |
| ip6: | One IPv6 address or a range. | 0 |
| a | The current domain's own address. “a:other.example” points at another domain. | 1 |
| mx | The addresses of the servers listed in the domain's MX records. Convenient, and rarely accurate: your inbound servers aren't necessarily your outbound ones. | 1, plus resolving each MX |
| include: | Another domain's SPF record, evaluated in full. This is the one your provider hands you. | 1 per include, plus the cost of the included record |
| exists: | True if the name built from the sending address resolves. Used by providers with too many addresses to list. | 1 |
| ptr | The reverse name of the sending address. RFC 7208 § 5.5 asks you not to publish it. | 1 |
| redirect= | Replaces this record entirely with another domain's. A modifier, not a mechanism: its only use is centralizing one SPF record across several domains. | 1 |
| exp= | The name carrying the explanation returned when a message is rejected. | 0, evaluated only on failure |
Two more limits, rarely mentioned and just as fatal: an “mx” mechanism can't resolve more than ten servers, and two lookups that come back empty (“void lookups”) are enough to trigger a permanent error.
The four qualifiers
A qualifier goes in front of any mechanism. In front of “all”, it decides what happens to everything you didn't list.
| Qualifier | Result | What the recipient does with it |
|---|---|---|
| + | Pass | Authorized. This is the default: a mechanism with no qualifier means “+”. |
| - | Fail | Rejected. The message is refused or dropped. The only setting that protects a name from spoofing. |
| ~ | SoftFail | Accepted but marked. The message arrives, often in the spam folder, and the failure shows up in DMARC reports. The transition setting. |
| ? | Neutral | No instruction at all. Treated as though there were no SPF record. |
Three other results never appear in the record but do turn up in reports: “None” when no SPF record exists, “TempError” when a DNS lookup failed temporarily, “PermError” when the record is broken — two SPF records published, or more than ten lookups.
Common questions
How do I create an SPF record?
Tick above whoever sends on your behalf, copy the value it produces, and publish it in your DNS zone as a TXT record at the root of the domain. One SPF record per domain: if one already exists, merge it with the new one rather than adding a second. Give it about an hour before the new value is visible everywhere.
Should I use “-all” or “~all”?
“-all” once your list is complete, and that's the goal. “~all” while you make sure no legitimate sender was forgotten: you'll see the failures in DMARC reports without breaking any sending. The trap is staying on “~all” forever, which leaves your name spoofable.
How many includes can an SPF record have?
As many as you like, as long as the total stays under ten DNS lookups. An include costs at least one lookup, and usually more because it contains includes of its own. In practice, four or five is a sensible ceiling. Past that, swap the ones with stable address ranges for ip4 mechanisms.
What happens if my SPF record goes over ten DNS lookups?
The check stops on a permanent error and the result is “PermError”. That's neither a pass nor a fail: most recipients treat the message as though there were no SPF record at all, and your DMARC policy is left resting on DKIM alone. The protection disappears without a single message being rejected, so nobody notices.
Do I need an SPF record on a domain that sends no email?
Yes, and it's the quickest one to write: “v=spf1 -all”. Without it, anyone can send mail as your redirect domain or your retired brand. Add a DMARC record at “p=reject” on the same domain so the instruction is complete.
Do I still need DKIM and DMARC if SPF passes?
You do — the three cover three different things. SPF authorizes IP addresses. DKIM signs the message, and the signature survives forwarding. DMARC tells the recipient what to do when both fail, and gets reports sent back to you. SPF on its own, with no DMARC record, produces no usable instruction.
The closed question
Can a domain publish two SPF records?
No.
RFC 7208 § 3.2 leaves no room: when several SPF records answer on the same name, the check returns a permanent error. The two don't add up, they cancel each other out. Your DNS panel accepts both without a word, and your mail keeps going out — which is what makes the mistake last so long.
What to do instead
Merge the terms
One record carries the mechanisms of both: the includes of one follow the includes of the other, the address ranges gather in one place, and a single final qualifier decides.
Count the lookups again
Merging adds the costs together too. If each record cost six DNS lookups, the merged one costs twelve, and you're past the limit of ten.
Delete the old one
Once the new record is published, the old one keeps returning a permanent error for as long as it sits in the zone. Check that only one is left before you move on.
The counter
Bringing the count down
Three moves that take DNS lookups off the count, and a fourth that checks the number on screen is telling the truth.
Replace an include with the addresses it publishes
The ip4 and ip6 mechanisms cost no lookup; an include costs one, plus the cost of the record it pulls in. The move works for services whose ranges are stable and documented, not for a provider that changes its own without notice.Drop the ptr mechanism
RFC 7208 § 5.5 says it should not be published. It costs a lookup, it's slow, and it's easy to fool. Replace it with the addresses it was authorizing.Do without mx when the sending servers are known
The mx mechanism costs one lookup, plus resolving every server listed. It also authorizes your inbound servers, which aren't necessarily the ones that send.Check the real total before publishing
The generator's counter only sees the first level. An include pointing at a provider that contains three of its own costs four. The email authentication tool queries DNS and gives you the full total.
Twenty checks, no sign-up
- Has my DNS change propagated yet?
- Is this domain blacklisted?
- What security headers does this site send?
- A domain's full health report
- When does this domain expire?
- Is this SSL certificate valid, and when does it expire?
- Are your SPF, DKIM and DMARC set up right?
- Is this domain or its mail server blacklisted?
- Which servers receive mail for this domain?
- Which nameservers answer for this domain?
- What do this domain's TXT records do?
- Where does this CNAME end up?