SPF Record Generator

Introduction:

Email domains often send from more places than one DNS record remembers. Staff mail may leave through Microsoft 365 or Google Workspace, forms may use a web host, alerts may use an on-premises relay, and newsletters may come from a marketing provider. Sender Policy Framework, or SPF, gives receivers a DNS-published list of the hosts and delegated policies that are allowed to send for an SMTP envelope domain.

The envelope domain is not always the visible From address a person sees in a mail client. SPF evaluates the MAIL FROM identity, and in some cases the HELO identity, used by the sending server during SMTP delivery. DMARC then checks whether the authenticated SPF domain, or a valid DKIM signing domain, aligns with the visible From domain. That is why a message can pass SPF and still fail DMARC.

Envelope domain

The SMTP identity SPF evaluates, often later visible as the return-path domain.

Authorized source

An IP range, provider include, A host, MX host, or redirected SPF policy that can match a sender.

Terminal policy

The final all decision for senders that did not match any earlier SPF term.

Lookup budget

The limit on DNS-query-causing SPF terms during receiver evaluation.

SPF policy design is mostly inventory work. Provider includes are convenient because a service can maintain its own sender ranges, but each include costs at least one lookup and may hide more lookups behind it. A and MX mechanisms are compact, but they authorize whatever those DNS answers resolve to later. Direct IP ranges are easier to audit, but they must be updated whenever the sending network changes.

A sound SPF record is singular, specific, and maintainable. It belongs at the owner name receivers query, it should be the only TXT record at that owner name that starts with v=spf1, and it should leave enough lookup headroom for provider changes and future mail streams.

How to Use This Tool:

Start from a sender inventory, then use the generated TXT value, publish target, and audit rows as a DNS change checklist.

1. Enter Domain as the envelope domain that will publish SPF. Use a bare domain or subdomain such as example.com or mail.example.com, without a protocol, path, or mailbox address.
2. Choose a Sender preset only when it matches your real sender inventory. The Google, Microsoft, combined-provider, on-prem relay, dual-stack, parked-domain, and redirect starters are editable drafts, not proof of coverage.
3. Add provider policy domains in Include domains without the include: prefix. Add stable relay addresses or networks in Authorized IPv4 CIDRs and Authorized IPv6 CIDRs.
4. Turn on Allow domain MX hosts or Allow domain A/AAAA hosts only when those DNS records identify approved outbound senders. Use Additional A mechanisms and Additional MX mechanisms for named hosts or delegated domains that need separate review rows.
   A and MX mechanisms follow live DNS answers. If a host or mail-exchanger changes later, SPF authorization can change with it.
5. Set a Redirect domain only when unmatched SPF evaluation should move to a centrally maintained policy you control. When redirect is present, the generated record uses redirect= and omits the selected terminal all policy.
6. Choose Terminal policy for rollout. ~all is safer while you confirm senders, -all is stricter after coverage is proven, ?all is neutral, and +all should not be used for normal production domains.
   Use the Include depth factor as a planning reserve when provider includes may contain nested SPF work.
7. Open Publish Plan and copy the Host / name field, Owner FQDN, SPF TXT value, and Quoted TXT strings in the form your DNS provider expects.
8. Review Mechanism Audit and Rollout Checklist before publication. If the status shows Fix inputs before publish, Lookup budget exceeded, or Record size needs review, resolve that warning before changing DNS.

Interpreting Results:

Read Owner FQDN and SPF TXT value together. A valid-looking TXT value at the wrong owner name will not authorize the intended envelope domain, and two separate SPF TXT records at the same owner name can produce a permanent SPF error.

The readiness status checks the current draft for syntax, owner mapping, lookup estimate, size, and policy cautions. It does not prove that every sender was inventoried, that live vendor includes are under the DNS lookup limit, or that DMARC alignment will pass for real messages.

The most common false confidence is a clean record that omits a real sender. Before moving from ~all to -all, send representative mail from every platform and inspect authentication results for both SPF and DMARC alignment.

Technical Details:

An SPF record begins with v=spf1, then lists mechanisms and modifiers that are evaluated left to right. Direct ip4: and ip6: mechanisms match addresses without extra DNS work. include, a, mx, and redirect can require DNS queries, so they consume the SPF lookup budget defined by the standard.

The final policy handles senders that did not match earlier terms. -all is a hard fail, ~all is a soft fail, ?all is neutral, and +all passes any remaining sender. A redirect changes the ending because unmatched evaluation moves to another SPF policy, so the local all term is not emitted when a redirect target is used.

Formula Core:

The lookup estimate separates direct lookup terms from a planning reserve for nested provider includes.

Lest is the estimated lookup total, Ldirect is the number of direct lookup-causing terms, I is the number of include mechanisms, and F is the include depth factor. For example, 2 includes, 1 MX switch, and a factor of 2 gives 3 - 2 + ceil(2 x 2) = 5 estimated lookup terms. Values above 10 are blocked, while 8 through 10 are treated as review territory.

Rule Core:

TXT packaging is separate from SPF logic. One DNS TXT record can contain multiple quoted strings, and those strings are concatenated by receivers. The generator splits long output into quoted strings of no more than 255 characters, warns when more than one quoted string is needed, and treats payloads above 450 characters as needing simplification.

The generated checks do not query live DNS. Lookup counts, chunking, and policy cautions are planning aids derived from the draft. Live validation still belongs after publication, especially when vendor includes, MX expansion, redirects, or DMARC alignment can change the receiver's final result.

Accuracy and Privacy Notes:

This is a draft generator, not a live DNS auditor. It builds the SPF value, owner name, host label, quoted TXT strings, lookup estimate, and rollout warnings from the values entered on the page. It does not resolve provider includes, test propagation, inspect message headers, or prove that receivers will accept the final policy.

• Check live DNS after publication and confirm that only one SPF TXT record exists at the owner name.
• Provider includes and MX answers can change after a vendor or administrator updates DNS.
• Copied or downloaded reports can reveal domain names, IP ranges, vendors, and mail-routing choices.
• After the page loads, draft generation runs in the browser and does not require sending the SPF record to a lookup service.

Worked Examples:

Roll out Microsoft 365 before strict enforcement

A domain using Microsoft 365 starts from the Microsoft preset, keeps Domain as example.com, and confirms that Include domains contains spf.protection.outlook.com. During migration, ~all gives time to check logs and DMARC results before switching to -all.

Keep a parked domain from authorizing mail

A domain that never sends mail uses the parked-domain preset. With no includes, IP ranges, A mechanisms, MX mechanisms, or redirect target, the generated value is a deny-all SPF policy and the status reads No mail should send.

Replace broad A/MX authorization

A self-hosted setup that enables both domain A and MX mechanisms may look compact, but it follows future DNS changes. If the relay addresses are stable, replacing those mechanisms with explicit ip4: or ip6: terms gives a policy that is easier to audit.

Fix a blocking zone mismatch

If Domain is mail.example.com but DNS zone is example.net, the draft is blocked because the zone does not contain the publish domain. Changing the zone to example.com lets the publish plan produce host mail and owner mail.example.com.

FAQ:

Glossary:

Sender Policy Framework

A DNS-based email authentication policy that authorizes sending hosts for an envelope domain.

Envelope domain

The SMTP MAIL FROM, return-path, or HELO identity that SPF evaluates.

Owner FQDN

The full DNS name where the SPF TXT record should be published.

Include

An SPF mechanism that evaluates another domain's SPF policy as part of the current policy.

Redirect

An SPF modifier that sends unmatched evaluation to another policy and replaces the local terminal action.

Terminal policy

The final all decision for senders that did not match earlier mechanisms.

DMARC alignment

The relationship between an authenticated SPF or DKIM domain and the visible From domain.

References:

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, RFC Editor, April 2014.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), RFC Editor, May 2026.
• Set up SPF, Google Workspace Admin Help.
• Set up SPF to identify valid email sources for your Microsoft 365 domain, Microsoft Learn.