SPF Record Generator — Build TXT SPF Policies

SPF is a TXT record at the domain apex (and sometimes per-subdomain) starting with v=spf1 followed by mechanisms describing authorized senders. Receivers evaluate SPF during SMTP, expanding includes recursively up to DNS lookup limits. A final all mechanism declares default handling for everyone not matched — -all means fail, ~all means soft fail, ?all means neutral.

Our generator focuses on the most common production mechanisms: a, mx, ip4, include, and all. That covers typical small-business Google/Microsoft hosting plus one ESP include without learning RFC syntax by heart.

Each include:domain pulls in another domain's SPF policy recursively. SaaS email vendors publish exact include hostnames — paste those strings without the include: prefix; the builder adds it. Stacking multiple includes for CRM, newsletter, and ticketing tools is normal; watch total DNS lookup depth.

Never guess includes from memory. Vendor documentation changes when they migrate infrastructure. After generating, publish to a low-TTL staging subdomain first when your architecture supports test zones.

ip4 entries authorize specific IPv4 addresses or CIDR ranges — common for on-premise appliances with static egress. mx authorizes the A records of your domain's MX hosts. a authorizes the domain's own A record. Toggle mx and a only when mail actually sends from those paths to avoid widening the policy unnecessarily.

The builder emits ip4: entries one per line you supply. CIDR notation depends on your DNS host supporting it in SPF — most do for /32 through reasonable prefixes.

-all is the recommended production default once you confirm all legitimate senders are listed. Receivers should reject or strongly filter mail failing SPF. ~all marks failures as soft fail — still deliverable to spam — useful during migration before you commit to -all.

?all is neutral and offers minimal anti-spoofing value. Use it only during initial monitoring, not as a long-term posture. Our email spoofing test flags permissive all qualifiers as risk factors.

SPF drafting reveals your mail vendor choices and infrastructure IPs. Client-side generation keeps that inventory on your machine — no upload to our API, no logging of includes or ip4 lists. Suitable for regulated environments drafting records before change approval.

Copy the output into password-protected change tickets rather than public pastebins when lists contain sensitive egress IPs.

SPF lives in a single TXT record at the apex unless subdomains publish separate mail streams. Some hosts want quotes around the string; others accept the raw line. Only one SPF TXT per label — merging two v=spf1 strings invalidates both.

After publish, wait for TTL propagation and verify with our SPF/DKIM/DMARC checker or email deliverability checker. Automated tests catch typos like v=spf1 missing or double spaces breaking parsers.

Receivers allow at most ten DNS lookups while evaluating SPF, counting includes and certain mechanisms. Deep include chains cause PermError and SPF failure even when policy intent is correct. Our generator does not count lookups — manually audit includes or use dedicated SPF flattening services if you approach the limit.

Flattening replaces includes with ip4 lists — high maintenance when ESP IPs rotate. Prefer subdomain delegation for large marketing streams when possible.

SPF alone does not stop header From spoofing — DMARC adds domain-level policy aligned with SPF and/or DKIM. Generate SPF here, DKIM keys at your mail host, then use our DMARC record generator for _dmarc TXT policy.

Alignment matters: DMARC may require relaxed or strict SPF alignment between envelope and header domains. Document both when onboarding new senders.

Publishing multiple SPF TXT records, omitting v=spf1, using ptr mechanism (deprecated), or leaving +all implicit through misconfigured includes. Another frequent error is authorizing overly broad ip4 /8 ranges — attackers on the same ISP block could qualify.

Regenerate after every mail vendor migration. Stale includes to decommissioned ESP infrastructure cause legitimate mail to fail SPF after vendors retire old redirect domains.

Complex enterprise deployments with ip6, redirect=, exists:, or macro-heavy policies need manual RFC 7208 authoring or vendor wizards. This tool targets straightforward SMB and agency stacks.

Always validate live DNS after publish — generation correctness does not replace propagation checks.