{{ result.summaryTitle }}
{{ result.record }}
{{ result.secondaryText }}
{{ result.statusText }} {{ result.policyBadge }} {{ result.ownerBadge }} {{ result.sourceMixBadge }} {{ result.lookupBadge }} {{ result.lengthBadge }}
Use a bare domain such as example.com or mail.example.com.
Enter one domain per line or comma; omit the include: prefix.
Accepts IPv4 addresses or CIDR ranges, for example 203.0.113.0/24.
Accepts IPv6 addresses or CIDR ranges, for example 2001:db8:100::/48.
Use ~all while testing; switch to -all after all senders are covered.
Choose Custom to keep the current field values unchanged.
Use host or host/prefix forms, for example mail.example.com/24.
Enter one delegated hostname per line or comma.
Enter only the target policy domain, for example _spf.example.net.
Leave blank for direct publish; use a parent zone such as example.com for subdomains.
Field Value Copy
{{ row.label }} {{ row.value }}
# Term Lookup Purpose Copy
{{ row.order }} {{ row.token }} {{ row.lookup }} {{ row.purpose }}
Priority Check Current reading Action Copy
{{ row.priority }} {{ row.check }} {{ row.current }} {{ row.action }}

      
:

Introduction:

Sender Policy Framework records tell receiving mail systems which hosts are authorized to send mail for an envelope domain. The record is published as DNS TXT and starts with v=spf1, followed by mechanisms such as ip4, ip6, include, a, mx, redirect, and a final all policy.

SPF is easy to over-publish. Adding every service to the apex domain can mix transactional mail, marketing mail, and helpdesk systems into one reputation surface. Adding too many lookup-causing mechanisms can make SPF fail permanently during evaluation.

SPF record path from sender inventory to DNS publication

A valid SPF record does not prove that mail will pass DMARC by itself. SPF must align with the domain used in the message, and DKIM often carries the more stable authentication signal for forwarded or relayed mail.

Technical Details:

The generated record always starts with v=spf1. Direct IP entries become ip4: or ip6: mechanisms. Include domains become include: mechanisms. Domain A and MX switches add a and mx, while advanced host lists add scoped a: and mx: mechanisms.

SPF mechanism and lookup budget map
SPF elementDNS lookup costImportant limit
ip4 / ip60Stable when sender IP ranges are known.
include1 plus nested policy lookupsCounts toward the SPF 10-lookup limit.
a / mx1 each, with MX fan-out riskOutcomes change when DNS answers change.
redirect1Replaces the local all policy.
all0Defines unmatched sender handling.

The tool normalizes domains, mailbox-like input, URLs, IPv4 and IPv6 CIDR entries, and DNS zone mapping. It estimates direct lookup terms and include nesting with a configurable multiplier, warns near 8 of 10 planned terms, and treats more than 10 as a blocking budget problem. TXT output is chunked when needed but remains one DNS TXT record.

Everyday Use & Decision Guide:

Start from a sender preset only if it matches the real outbound mail inventory. Google Workspace, Microsoft 365, on-prem relays, parked domains, and central redirect policies have different risk profiles.

  • Use direct ip4 and ip6 entries for stable outbound relay addresses.
  • Use include for maintained provider SPF policies, then check nested lookup headroom.
  • Use ~all during rollout when the sender list is still being confirmed.
  • Use -all only when every legitimate sender path is covered.
  • Avoid +all for production because it authorizes any sender.

Publish exactly one SPF TXT record at the owner name. If one already exists, merge the mechanisms instead of adding a second record.

Step-by-Step Guide:

  1. Enter the domain or subdomain that receives mail as the envelope sender domain.
  2. Add provider includes, IPv4 ranges, IPv6 ranges, and domain A or MX switches as needed.
  3. Choose the final all policy, or add a redirect domain for a central policy.
  4. Set the DNS zone when publishing a subdomain from a parent zone.
  5. Review Publish Plan for TXT owner, TTL, quoted TXT, and status.
  6. Use Mechanism Audit and Rollout Checklist before changing DNS.

Interpreting Results:

Ready to publish means the generated syntax and planning checks are acceptable. Review before publish usually points to lookup headroom, chunking, normalization notes, or broad apex scope. Lookup budget exceeded should be fixed before DNS publication.

A short record is not automatically correct. The sender inventory matters more than the string length, and strict -all will reject omitted legitimate senders after propagation.

Worked Examples:

Microsoft 365 domain. A domain using only Microsoft 365 can start with include:spf.protection.outlook.com and a strict or soft policy depending on rollout confidence.

Parked domain. A domain that sends no mail should usually publish v=spf1 -all. The tool labels this as a no-mail posture rather than a sender coverage record.

Lookup pressure. A record with many vendor includes plus A and MX mechanisms can approach the 10-lookup limit. The audit should be simplified before production rollout.

FAQ:

Can I publish multiple SPF records?

No. SPF expects one record at an owner name. Multiple SPF TXT records cause evaluation errors.

What is the difference between ~all and -all?

~all is soft fail and is useful during rollout. -all is hard fail and should wait until all senders are covered.

Does SPF replace DKIM or DMARC?

No. SPF authorizes envelope senders. DKIM and DMARC still matter for authentication and alignment.

Glossary:

Mechanism
An SPF term that matches an authorized sender source.
Lookup limit
The SPF cap of 10 DNS-query-causing terms during evaluation.
Redirect
An SPF modifier that delegates unmatched evaluation to another policy.
Soft fail
The ~all policy for cautious rollout.