{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Policy: {{ resultsReady ? computation.values.policy : '—' }} Lookup estimate: {{ resultsReady ? `${computation.values.estimated_lookup_terms}/10` : '—' }} Input: {{ isDefaultSample ? 'Example only' : 'Custom' }}
Every preset uses documentation-only domains or addresses and must be replaced with the real sender inventory.
Use a bare domain such as example.com or mail.example.com.
One domain per line or comma; the include: prefix is optional.
Examples: 203.0.113.10 or 203.0.113.0/24.
Example: 2001:db8:100::/48.
Off is safer unless inbound MX hosts are also approved outbound senders.
{{ use_domain_mx ? 'On' : 'Off' }}
Off is safer unless the current A/AAAA hosts are intended outbound senders.
{{ use_domain_a ? 'On' : 'Off' }}
Use ~all during inventory and move to -all only after every legitimate sender path is covered.
One host per line, for example mail.example.com or mail.example.com/24//64.
One delegated domain per line, for example relay.example.net.
Leave blank for a local terminal policy; otherwise enter a domain such as _spf.example.net.
The neutral default is 1.0x; use live DNS validation before publication.
Leave blank to publish at the envelope domain's own zone.
Owner{{ computation.values.owner_fqdn }}
Zone host{{ computation.values.host_label }}
Type / TTLTXT / 3600
{{ computation.values.record }}

Quoted DNS value

{{ computation.values.quoted_txt }}

The chart renderer is unavailable. Exact lookup counts remain available in the mechanism ledger and summary.

OrderSPF termLookup costPurposeCopy
{{ row.order }}{{ row.term }}{{ row.lookup }}{{ row.purpose }}
{{ row.check }}
{{ row.status }}

{{ row.current }}

{{ row.action }}

DKIM DNS Record Generator Build a DKIM TXT record from a selector and public key with validation and DNS string splitting, plus rollout checks before publishing.
DMARC DNS Record Generator Build a current or legacy DMARC TXT record with policy inheritance and reporting destinations plus DNS string splitting and rollout review.
MTA-STS Validator Check an email domain's MTA-STS TXT and HTTPS policy, then review MX patterns and the policy-host certificate before enforcement.
TLS-RPT Record Validator Validate a TLS-RPT policy from live DNS or pasted text, check report destinations and RFC rules, then build a reviewable TXT record.

Every system that sends mail for a domain belongs in one sender inventory. That may include a staff mailbox provider, web-form host, ticketing service, newsletter platform, transactional relay, and on-premises server. Sender Policy Framework (SPF) publishes that inventory as a DNS TXT policy so receiving systems can compare a connecting IP address with the authorized paths.

SPF checks an SMTP envelope identity, usually the MAIL FROM domain and sometimes HELO. It does not directly authenticate the visible From address or the message content. Domain-based Message Authentication, Reporting, and Conformance (DMARC) adds the alignment check between the visible From domain and a domain authenticated by SPF or DKIM.

Sender pathSPF termOperational tradeoff
Stable relay address or networkip4 or ip6No SPF DNS lookup term, but the policy must change when the relay address changes.
Mail service with its own policyincludeThe provider maintains its addresses, but nested policies consume lookup budget.
Hosts named by DNSa or mxAuthorization follows later DNS changes, including changes made for web or inbound-mail reasons.
Central policy shared by subdomainsredirectUnmatched evaluation moves to another policy and replaces the local all term.

Order matters because SPF evaluates mechanisms from left to right until one matches. The final qualifier describes senders that matched nothing earlier: -all is fail, ~all is softfail, ?all is neutral, and +all authorizes every sender. Hard fail belongs after the inventory is complete and tested, not at the beginning of discovery.

A domain should publish one SPF policy record at the owner name receivers query. Adding a second TXT value that begins with v=spf1 does not extend the first; it creates an invalid multiple-record condition. Merge senders into the existing policy and leave headroom for vendor nesting and future changes.

How to Use This Tool:

Build the record from verified outbound paths, then treat the generated result as a DNS change draft that still needs live testing.

  1. Enter the Envelope domain whose MAIL FROM or HELO identity receivers will check. A subdomain can have a separate policy from its parent.
  2. Replace every documentation-only preset value with the real sender inventory. Add provider policy domains under Provider include domains and stable outbound addresses under the IPv4 or IPv6 fields.
  3. Enable envelope-domain MX or A/AAAA only when those live DNS answers are approved outbound senders. Use named A or MX mechanisms for specific delegated hosts when necessary.
  4. Choose the Terminal policy, or add a Redirect policy domain when a maintained central policy should handle unmatched senders. Redirect removes the local all term.
  5. Review the lookup estimate, record length, quoted TXT strings, and mechanism order. A blocked status requires simplification before publication.
  6. Query the existing DNS owner, merge any current SPF policy, publish one TXT record, and test every real sender after propagation for SPF result and DMARC alignment.

Interpreting Results:

Ready for DNS review means the local construction checks passed with planning headroom. It does not mean the provider includes were resolved or that every legitimate sender is represented. Review before publishing appears near the lookup limit, when TXT splitting or normalization needs attention, or when +all is selected.

Lookup budget exceeded means the planning estimate is above 10. Record needs simplification means the policy is longer than the 450-character warning point. A parked-domain result with only v=spf1 -all states that the domain should not send mail.

The direct and estimated counts serve different purposes. Direct count lists the query-causing terms visible in the generated record. The estimate adds a user-selected nesting reserve for includes; only live recursive evaluation can reveal the actual provider expansion.

Technical Details:

An SPF record starts with v=spf1, follows with sender mechanisms, and ends with either an all mechanism or a redirect modifier. DNS names are normalized to lowercase, duplicate list entries are removed, IPv4 and IPv6 CIDR prefixes are checked, and named A/MX mechanisms accept their SPF dual-CIDR suffixes.

Rule Core

Generated orderTermRule
1v=spf1Declares the SPF version.
2Envelope-domain mx, then aAdded only when their switches are enabled.
3ip4 and ip6Direct addresses and CIDR ranges are listed before delegated policies.
4include, named a, named mxEach list keeps its normalized input order after duplicates are removed.
5redirect=domain or qualified allRedirect replaces the selected terminal policy; otherwise the chosen qualifier ends evaluation.

A TXT record is packaged as one resource record containing one or more quoted character strings. Each string is at most 255 characters. When the SPF text is longer, it is split at spaces where possible, but every quoted string must stay inside the same TXT record and in the original order.

Lookup Core

RFC 7208 limits the total number of DNS-query-causing terms encountered during SPF evaluation to 10. Exceeding that limit produces a permanent error. The generated audit counts visible terms and applies a planning factor to includes:

E=A+D+⌈I×F⌉

Here A counts enabled and named A/MX mechanisms, D is 1 when redirect is present and 0 otherwise, I is the number of includes, and F is the selected factor of 1, 1.5, 2, or 3. Direct ip4, ip6, and all terms add zero to this estimate.

ConditionStatus effectMeaning
E > 10BlockedThe planning estimate exceeds the RFC evaluation limit.
E ≥ 8 and ≤ 10ReviewLittle estimated headroom remains for nested provider changes.
Record length > 450 charactersBlockedThe policy crosses the conservative DNS-message sizing warning.
More than one quoted stringReviewPublish all strings as one TXT record and verify provider syntax.

The 450-character check is deliberately conservative and the include factor is a planning heuristic, not an RFC calculation. Neither resolves live DNS, counts nested terms exactly, checks void lookups, proves sender coverage, or verifies that another SPF policy already exists at the owner.

Accuracy and Privacy Notes:

The record is constructed locally from the supplied inventory and does not query DNS. Domains, sender addresses, provider names, and policy choices can reveal infrastructure relationships, so handle exports according to the organization's change-management rules.

  • Provider include contents can change after publication and must be checked with live SPF evaluation.
  • A or MX authorization changes when the referenced DNS answers change.
  • SPF pass alone does not prove DMARC alignment or message legitimacy.
  • Use documentation-only example addresses and domains only for testing; replace them before publication.

Worked Examples:

Provider plus fixed web relay

Add the provider's documented include and the web relay's stable ip4 address, then use ~all during inventory. The include consumes lookup budget; the direct IP does not. Move to -all only after real form mail and staff mail both pass.

Domain that never sends

Leave every sender mechanism empty and choose -all. The resulting v=spf1 -all policy is appropriate only when no legitimate system uses that envelope domain.

References: