SPF Record Builder

Build a Sender Policy Framework DNS TXT record for your domain.

Policy: ~allIncludes: 0Record Length: 0

Authorised Senders

mx — servers in your MX recordsa — servers in your A record

ip4: IPv4 addresses or CIDR ranges

ip6: IPv6 addresses or CIDR ranges

include: Third-party senders (e.g. Mailchimp, SendGrid)

Policy (all)

~all (Softfail)

Accept but mark as suspicious — recommended for new setups

-all (Fail)

Reject email from unlisted servers — strict, recommended once stable

?all (Neutral)

No policy statement — not recommended

+all (Pass)

Allow any server — not recommended, disables SPF protection

DNS TXT Record

Add this as a TXT record on your domain — name: @ (or your domain), TTL: 3600.

What is SPF?

SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorised to send email for your domain. When a receiving server gets an email, it checks the SPF record of the From domain to verify the sender. Use ~all (softfail) when first deploying, then switch to -all (hard fail) once you are confident all legitimate senders are listed. Pair with DKIM and DMARC for full email authentication.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Publishing an SPF record for a domain that sends mail through several services.
Adding a new sending service to an existing record correctly.
Choosing between a soft fail and a hard fail policy deliberately.
Counting the DNS lookups a record will cost before publishing it.
Reviewing an inherited record that nobody has audited.

Frequently Asked Questions

What does an SPF record actually authorise?: The envelope sender's domain against the sending IP — not the From address a recipient sees. That gap is exactly why DMARC exists: an attacker can pass SPF for a domain they own while putting your domain in the visible From.
What is the ten-lookup limit?: SPF permits at most ten DNS lookups when evaluating a record, counting every `include`, `a`, `mx`, `ptr` and `redirect` — recursively. Exceeding it is a permanent error and the record fails entirely, which is the commonest way a working SPF quietly stops working after adding one more provider.
Which all mechanism should I use?: `~all` (softfail) while deploying, `-all` (hardfail) once the reports show every legitimate sender is covered. `?all` states no policy and does nothing useful, and `+all` authorises the entire internet, which is worse than having no record at all.
Can a domain have two SPF records?: No — two TXT records beginning `v=spf1` is a permanent error, and evaluators treat it as no valid record. Adding a second provider means merging their `include` into the existing record, which is a step people miss when two teams manage DNS.
Does SPF survive forwarding?: No, and that is its structural weakness. A forwarded message arrives from the forwarder's IP, which your record does not authorise, so SPF fails. DKIM survives forwarding because it signs the message itself, which is why DMARC accepts either passing.

Common errors and gotchas

Exceeding the ten DNS lookup limit, at which point the record fails and every check with it.
Publishing more than one SPF record for a domain, which is invalid and fails outright.
Using `+all`, which authorises the entire internet to send as you.
Forgetting a service that sends on your behalf, which then starts failing silently.
Assuming SPF survives forwarding, which it usually does not — that is what DKIM is for.