How it works
This tool assembles a syntactically valid SPF (Sender Policy Framework) TXT record from the senders you authorize. Tick a to authorize whatever IPs your domain's own A record points to, and mx to authorize the hosts listed in your MX records. Add ip4 and ip6 entries for individual servers or CIDR ranges that send mail directly, and add an include for every third-party provider that sends on your behalf (Google Workspace uses _spf.google.com, Microsoft 365 uses spf.protection.outlook.com). Finally, pick your all policy. The record updates live as you type.
Publish the result as a single TXT record on the root of your domain (host @, or the bare domain name). A domain may have only one v=spf1 record, do not create a second. After publishing, wait for DNS to propagate, then send a test message and inspect the Authentication-Results header of the received mail: spf=pass means the sending IP matched a mechanism before the all.
Reading the DNS-lookup warning: SPF evaluation is capped at 10 mechanisms that require a DNS lookup. This tool counts one for a, one for mx, and one for each include; ip4, ip6 and all cost nothing. If your total exceeds 10 the tool warns you, because a real receiver will return PermError and may treat the record as if it failed. Note the count is cumulative through nested includes, a provider's include can itself pull in several more lookups, so stay well under the limit.
SPF mechanisms & qualifiers reference
| Mechanism | Authorizes | DNS lookups | Example |
|---|---|---|---|
ip4 | An IPv4 address or CIDR range | 0 | ip4:203.0.113.0/24 |
ip6 | An IPv6 address or CIDR range | 0 | ip6:2001:db8::/32 |
a | The IPs in the domain's A/AAAA record | 1 | a |
mx | The IPs of the domain's MX hosts | 1 | mx |
include | Another domain's SPF record (nested) | 1 + nested | include:_spf.google.com |
all | Everything: the catch-all, placed last | 0 | -all |
Every mechanism can carry a qualifier that decides the result when it matches. If none is written, + is assumed.
| Qualifier | Result | Receiver behaviour |
|---|---|---|
+ | Pass | Accept (the default if omitted) |
- | Fail | Reject as unauthorized, used as -all |
~ | SoftFail | Accept but mark suspicious, used as ~all |
? | Neutral | No assertion either way |
Frequently asked questions
Why does SPF limit me to 10 DNS lookups?
RFC 7208 caps the number of mechanisms requiring DNS resolution at 10 to prevent a single SPF check from triggering unbounded queries. Exceeding it produces a PermError, and many receivers then treat the message as if SPF failed. If you legitimately need more senders, "flatten" some includes into explicit ip4/ip6 ranges, which cost no lookups.
Should I use -all or ~all?
Use -all (Fail) once you are confident every legitimate sender is listed, it tells receivers to reject spoofed mail outright. Use ~all (SoftFail) as a temporary safety net while you audit your senders, since it lets unmatched mail through but flagged. Avoid +all, which authorizes the entire internet to send as your domain.
Do ip4 and ip6 entries count toward the lookup limit?
No. Literal ip4 and ip6 addresses are matched directly against the connecting IP with no DNS query, so they are free. Only a, mx, include, ptr, exists and the redirect modifier consume lookups. This is why converting includes to fixed IP ranges is the standard fix for over-limit records.
Can I publish more than one SPF record?
No, a domain must have exactly one v=spf1 TXT record. Two or more cause a PermError and SPF stops working entirely. Merge all your senders into a single record instead of adding a second one.
Is SPF enough on its own?
No. SPF only validates the envelope sender's IP and does not survive most forwarding. Pair it with DKIM (a cryptographic signature) and DMARC (which ties the two to the visible From address and sets a reporting and enforcement policy) for real anti-spoofing protection.
-all.