SPF Generator

Generate an SPF Record That Counts Your DNS Lookups

An SPF record tells the internet which servers are allowed to send mail using your domain. Get it right and spoofed mail from your domain gets rejected. Get it wrong — and the most common way to get it wrong is silent — and your own legitimate mail starts landing in spam or bouncing outright, for everyone, at once.

This generator builds the record from a provider list and a running DNS lookup counter that is visible at all times. Tick Google Workspace, Microsoft 365, SendGrid, Mailchimp, and the rest from a database of more than 50 email providers; add your own mail server IP addresses and CIDR ranges; pick a terminator policy; and copy a syntactically valid record with the lookup budget already accounted for. It validates as you build, grades the result, and refuses to let a broken record look finished. Everything runs in your browser — no domain is queried and no data is sent anywhere.

The 10-Lookup Limit Is the Whole Problem

RFC 7208 caps an SPF evaluation at 10 DNS lookups. Exceed it and the receiving server returns a permerror, and a permerror is not a soft failure — most receivers treat it as an SPF failure, which means your mail can be rejected or junked even though every server in your record is legitimate. Nothing warns you. The record still looks correct in a DNS query. Mail simply starts failing.

These mechanisms consume lookups: include, a, mx, ptr, and exists. These do not: ip4, ip6, and all. Crucially, the count is recursive — if you include a provider whose own record contains three further includes, you have spent four lookups, not one. That is why a record with only six visible includes can blow the budget.

The counter in this tool warns at 8 and marks the record invalid above 10, because the useful moment to intervene is before you have shipped a record that fails.

Why +all Is Not a Fix

When mail starts failing, the internet is full of advice to “just use +all”. Do not. +all means any server on the internet is authorised to send mail as your domain. It does not merely disable SPF — it publishes an explicit statement that every spoofer has your permission, which is worse than having no SPF record at all. Receivers and security scanners flag it as a misconfiguration, and it hands phishing campaigns a domain with a valid SPF pass. This tool treats +all as a hard error, not a warning.

The legitimate terminators, in order of strictness:

• -all (hard fail) — anything not listed is unauthorised. The correct end state, and what DMARC enforcement expects.
• ~all (soft fail) — treat unlisted senders as suspicious but accept. Useful for a few weeks while you find the sending systems you forgot about.
• ?all (neutral) — no opinion. Provides essentially no protection; only meaningful during initial discovery with DMARC in p=none and reporting switched on.

If mail is failing SPF, the answer is to find the sender and add it, or to remove it from your domain — never to widen the policy until the failure disappears.

How to Use the Generator

1. Paste your existing record if you have one. The tool parses it back into editable mechanisms so you can see where the lookups are being spent.
2. Select your providers. Each entry in the provider database carries its correct include and its known lookup cost, including whether it recurses.
3. Add your own servers as ip4 or ip6. IP addresses and CIDR ranges are validated as you type, and they cost zero lookups.
4. Add custom mechanisms where you need an a, mx, exists, or a non-default qualifier.
5. Choose the terminator. Start at ~all if you are not yet confident you have found every sender; move to -all once DMARC reports are clean.
6. Read the validation panel and the grade. Errors mean the record will not work. Warnings mean it will work today and is fragile.
7. Open the optimizer if you are near the limit — it identifies which mechanisms are costing the most and what can be consolidated.
8. Follow the deployment instructions to publish it as a TXT record at the apex of your domain.

Getting Under the Limit

When the counter is over 10, there are three real fixes and one fake one.

• Subdomain delegation — the best answer. Move bulk and marketing senders onto their own subdomain: send campaigns from mail.example.com or news.example.com, each with its own SPF record and its own fresh 10-lookup budget. The apex record then only has to authorise your corporate mail. This also isolates your primary domain’s reputation from marketing send volume.
• Replace includes with ip4 where you control the addresses. Your own mail relay does not need an a or mx lookup; its IP costs nothing.
• Remove senders you no longer use. Old records accumulate includes for services cancelled years ago. Auditing DMARC reports tells you which includes are actually carrying mail.
• SPF flattening — use with care. Third-party services expand every include into a literal IP list, reducing the count to zero lookups. It works, but the expansion is a snapshot: when your provider changes its sending infrastructure, your flattened record is silently wrong and mail fails. Only use a flattening service that re-resolves and republishes automatically, and never hand-flatten a large provider once and forget it.

One more constraint: a single DNS TXT string is limited to 255 characters. Longer records must be split into multiple strings within the same TXT record, which DNS concatenates on retrieval. This is a valid and common arrangement, but publishing two separate TXT records that both start v=spf1 is not — that is a permerror, and it is the second most common SPF fault after the lookup limit.

SPF Is One of Three

SPF authorises sending IPs. It does not survive forwarding, and it validates the envelope sender (the MAIL FROM), not the From: header the recipient actually sees. On its own it stops very little. It becomes effective as part of a set:

• DKIM cryptographically signs the message, so it survives forwarding and proves the content was not altered.
• DMARC ties SPF and DKIM to the visible From: domain through alignment, tells receivers what to do on failure, and — most usefully — sends you reports showing who is sending as your domain. Build one with the DMARC record generator.

The sequence that works: publish SPF with ~all, enable DKIM signing, publish DMARC at p=none with a reporting address, read the reports for a few weeks until every legitimate sender is accounted for, then tighten to -all and p=quarantine or p=reject. Check the finished configuration with the email authentication validator, and confirm what is actually published using the DNS lookup tool.

Frequently Asked Questions

What happens if my SPF record exceeds 10 DNS lookups?

Receivers return a permerror. Under DMARC that counts as an SPF failure, so depending on your DMARC policy your mail can be quarantined or rejected — including mail from servers you correctly listed. There is no partial credit and no warning; the record simply stops working.

Can I have two SPF records on one domain?

No. Exactly one TXT record beginning v=spf1 is permitted per domain. Two is a permerror. If you need to authorise more senders, merge the mechanisms into a single record — or better, delegate some senders to a subdomain.

Should I use -all or ~all?

-all is the correct destination. Use ~all only as a temporary state while you verify, through DMARC reports, that every legitimate sender is listed. Leaving ~all in place permanently means unauthorised mail is accepted rather than rejected.

Does SPF stop phishing?

Partially. It stops mail claiming to come from your domain’s envelope sender from unauthorised IPs. It does not stop lookalike domains, display-name spoofing, or compromised accounts sending from an authorised server. SPF plus DKIM plus an enforcing DMARC policy is the combination that meaningfully reduces domain spoofing.

Why is my mail failing SPF after being forwarded?

Because forwarding changes the sending IP without changing the envelope sender, so SPF fails by design. DKIM signatures survive forwarding, which is why DMARC accepts a pass from either mechanism. This is the main reason SPF alone is insufficient.

Is SPF flattening safe?

Only when it is automated. Flattening freezes your provider’s current IP ranges into your record; when they change infrastructure, your record becomes wrong and mail fails silently. If you flatten, use a service that re-resolves and republishes on a schedule, and monitor it.

Does the tool query my domain or send my data anywhere?

No. Record generation, lookup counting, and validation all run in JavaScript in your browser. Provider lookup costs come from a bundled database, not from live DNS queries, so nothing about your domain is transmitted.

Where do I publish the record?

As a TXT record at the root of your domain — host @ or the domain name itself, depending on your DNS provider’s interface. Set a low TTL such as 300 seconds while you are testing so mistakes can be corrected quickly, then raise it once the record is stable. Verify it resolves before assuming it is live.