SPF tells receiving mail servers which hosts are allowed to send mail for your domain, and a malformed SPF record is worse than none at all: it can reject legitimate mail or silently fail open. The record is a single TXT string with its own grammar of mechanisms and qualifiers, and writing it by hand invites misplaced spaces and wrong qualifiers. This builder assembles the record from your sending sources: IP addresses, an include for a provider, the a and mx mechanisms, and a final all mechanism that decides what happens to everything else. The result is a valid TXT value ready to publish.
Quick Answer: Enter your sending sources, choose the final policy, and click Build SPF Record.
Free Online Tool
SPF Record Builder
Build a structured SPF TXT record from mechanisms and qualifiers, with syntax validation.
How to Use the SPF Record Builder
- Enter any IPv4 addresses or ranges allowed to send mail.
- Add an include for each third-party sender, such as your mail provider.
- Tick the a mechanism if your domain A record sends mail, and mx if your MX hosts do.
- Choose the final qualifier: -all is strict, ~all is soft-fail.
- Click Build SPF Record.
- Publish the value as a TXT record at your domain and test it before relying on it.
Key Features
- Assembles mechanisms in the standard order.
- Validates IPv4 syntax before including an ip4 mechanism.
- Supports ip4, ip6, a, mx, include, and exists mechanisms.
- Explains each qualifier: plus, minus, tilde, and question mark.
- Warns about the ten DNS lookup limit that breaks many records.
- Runs entirely in the browser; nothing is published automatically.
What the Result Means
The record starts with v=spf1, which identifies it as SPF version one, followed by your mechanisms in order and ending with the all mechanism. A mechanism that matches authorises the sender; the first match decides, so order matters. The qualifier on all is the policy for senders that match nothing: -all says reject them, ~all says accept but mark them, and +all says accept everything, which defeats the purpose. If your record needs more than ten DNS lookups through includes, receivers may return a permanent error, so keep includes few.
Worked Example
A small business sends mail from its own server at 192.0.2.10 and from a newsletter provider at _spf.provider.example. Entering those two sources and choosing -all produces: v=spf1 ip4:192.0.2.10 include:_spf.provider.example -all. Receivers check the sending IP against that list, accept mail from either source, and reject the rest. If the newsletter provider changes its sending range, only the include needs updating, because the provider maintains its own record.
Best Practices and Tips
- Start with ~all while testing, then move to -all once legitimate mail passes.
- Count DNS lookups: each include, a, mx, and exists counts, and ten is the limit.
- Include every legitimate sender, including your website contact forms and CRM.
- Keep the record under 255 characters per string; split it if a provider requires it.
- Test with an SPF checker after publishing, before announcing the change.
Common Mistakes to Avoid
- Ending with +all, which authorises the whole internet.
- Forgetting a provider that sends on your behalf, such as a newsletter service.
- Exceeding ten DNS lookups with nested includes.
- Publishing two SPF records for one domain, which is invalid.
Frequently Asked Questions
What does -all mean?
It means any sender not listed in the record should be rejected. It is the strictest and most protective ending.
What is the difference between ~all and -all?
Soft-fail (~all) asks receivers to accept but flag unmatched mail; hard-fail (-all) asks them to reject it.
Do I need an SPF record if I use a provider?
Yes, and you usually include the provider domain so its servers are authorised for your domain.
How many SPF records can a domain have?
Exactly one. Two records make SPF invalid, so merge all mechanisms into a single record.