DNS SPF Record Builder & Explainer

DNS SPF Record Builder & Explainer

Build, validate, and optimize RFC 7208 compliant SPF TXT records with IPv4/IPv6 CIDR ranges, MX, A, include mechanisms, and soft/hard fail policies.

Presets:
DNS Query Mechanisms (a, mx, include, exists)
Common Email Service ProvidersPopular Email & SaaS Presets
Authorized Third-Party Includes (include:)
include:_spf.google.cominclude:sendgrid.net
Authorized IPv4 Addresses & CIDR (ip4:)
ip4:198.51.100.24/32
Authorized IPv6 Addresses & CIDR (ip6:)
Mechanisms: 6DNS Lookups: 3 / 10
Length: 80 / 255 Chars:Grade A+
DNS TXT Value
80 chars
v=spf1 mx ip4:198.51.100.24/32 include:_spf.google.com include:sendgrid.net ~all
DNS Management Fields (Cloudflare, Route 53, GoDaddy, Namecheap)
Record Type (TXT)TXT
Host / Subdomain Name (@ for apex)@ (or mycompany.io)
TTL (Time to Live in seconds)3600 (1 hour recommended)
BIND Zone File Syntax
; RFC 7208 SPF TXT Resource Record for mycompany.io
; Host/Name: @ (or mycompany.io.)
; Record Type: TXT
; TTL: 3600 seconds ({t.lbl1HourRecommended || "1 hour recommended"})

mycompany.io.    IN    TXT    "v=spf1 mx ip4:198.51.100.24/32 include:_spf.google.com include:sendgrid.net ~all"

; --- Cloudflare DNS API / Web Dashboard ---
; Type: TXT
; Name: @
; Content: v=spf1 mx ip4:198.51.100.24/32 include:_spf.google.com include:sendgrid.net ~all
; TTL: Auto (or 3600)
; Proxy status: DNS only
Policy:~all
Lookups: 3 / 10 Ready
DNS Lookups3 / 10 UsedRFC 7208 Section 4.6.4
Character LengthSoftFail (~all)DMARC Alignment Compatible
Enforcement PolicyClass A+ (100/100)Zero Data Exfiltration

100% Client-Side Evaluation & Privacy

Your domains, internal mail server IPs, and sending configurations are evaluated strictly inside your browser sandbox. Zero DNS queries or mail infrastructure telemetry are sent to any external server.

RFC 7208 Conformance & 10-Lookup Budget

Enforces strict RFC 7208 compliance: detects whether your policy exceeds the 10 DNS lookup limit (preventing PermError email rejections), validates 255-character string boundaries, and flags deprecated ptr mechanisms.

SaaS Presets, BIND & CLI Diagnostics

Includes battle-tested SaaS presets for Google Workspace, Microsoft 365, SendGrid, Amazon SES, and Mailgun. Exports clean DNS TXT values, BIND zone syntax, and dig/nslookup verification commands.

Technical Reference & Architecture Guide

DNS SPF (Sender Policy Framework) Record Builder & Explainer — Reference Guide

Build, analyze, and validate RFC 7208 compliant SPF TXT records with IPv4/IPv6 CIDR blocks, MX, A, include mechanisms, and soft/hard fail enforcement policies.

Key Parameters & Controls

All Mechanism Policy (~all / -all / ?all / +all)enum ('~all' | '-all' | '?all' | '+all')

Specifies the default enforcement qualifier for senders that do not match preceding mechanisms. '~all' (SoftFail) accepts but marks suspicious mail; '-all' (HardFail) instructs receiving MTAs to reject unauthorized messages outright.

Default: ~all
Include Mechanisms (include:domain)string[] (space-separated FQDNs)

Authorizes third-party mail service providers (e.g. Google Workspace, SendGrid, Microsoft 365) by querying their published SPF records. Each include mechanism consumes at least one DNS lookup toward the RFC 7208 limit of 10.

Default: _spf.google.com
IPv4 Addresses & CIDR Ranges (ip4:ip/cidr)string[] (IPv4 / CIDR notations)

Designates explicit static IPv4 addresses or CIDR subnets authorized to send email for this domain. Evaluated directly without incurring any DNS queries.

Default: 192.0.2.1/32
IPv6 Addresses & CIDR Ranges (ip6:ip/cidr)string[] (IPv6 / CIDR notations)

Designates explicit static IPv6 addresses or /64 /48 CIDR blocks authorized to transmit outbound mail. Evaluated directly without incurring DNS queries.

Default: 2001:db8::/32
MX Mechanism (mx / mx:domain)boolean | string (optional FQDN)

Authorizes the IP addresses resolved from the domain's MX (Mail Exchange) DNS records to deliver outbound email. Consumes DNS lookups for MX resolution and each host's subsequent A/AAAA resolution.

Default: false
A Mechanism (a / a:domain)boolean | string (optional FQDN)

Authorizes the primary IP addresses mapped to the domain's root A or AAAA records to dispatch outbound mail. Useful if the web server directly runs a local sendmail or postfix daemon.

Default: false

Pro Tips & Best Practices

RFC 7208 Section 4.6.4 limits

RFC 7208 Section 4.6.4 limits SPF evaluations to a maximum of 10 iterative DNS lookups across include, a, mx, ptr, and exists mechanisms. Exceeding 10 results in a 'PermError', causing mail providers like Gmail and Yahoo to treat messages as unauthenticated. Flatten deeply nested includes into static ip4/ip6 ranges whenever possible.

Never configure multiple TXT records

Never configure multiple TXT records starting with 'v=spf1' on the same host or root domain. RFC 7208 Section 3.2 explicitly dictates that if a receiving MTA encounters more than one SPF TXT record, it MUST terminate evaluation with a 'PermError'. Always consolidate all authorized senders into a single unified record.

When migrating towards a strict

When migrating towards a strict DMARC policy (p=reject or p=quarantine), maintain '~all' (SoftFail) in your SPF record instead of immediately switching to '-all'. DMARC treats SPF pass independently from DKIM, and '~all' prevents legitimate emails from being dropped if they pass DKIM during email forwarding or mailing list distribution.

RFC 7208 formally discourages

RFC 7208 formally discourages the 'ptr' mechanism because it demands heavy reverse-DNS (PTR) and forward-DNS lookups that many major mail receivers ignore or penalize. Furthermore, never publish '+all', as it explicitly authorizes every mail server on the entire internet to send authenticated mail on your domain's behalf.

Common Gotchas & Troubleshooting

Receiving mail servers reject incoming messages with '550 5.7.23 SPF PermError: too many DNS lookups'.

Audit your SPF record and reduce nested 'include:' mechanisms. Common SaaS providers (e.g., Salesforce, Zendesk, Mailchimp) frequently chain several internal lookups. Use SPF flattening to convert static third-party ranges into direct 'ip4:' and 'ip6:' mechanisms, or migrate dedicated transactional mail streams to distinct subdomains (e.g. mail.example.com).

Authentication fails with 'SPF PermError: duplicate SPF records found' on validation tests.

Inspect your DNS zone using 'dig +noall +answer TXT example.com' to identify all published TXT records. If multiple records starting with 'v=spf1' exist (e.g., one added by your hosting provider and another by your email marketing tool), delete the duplicates and combine all required 'include:', 'ip4:', and 'ip6:' values into a single TXT entry.

Legitimate emails forwarded by recipients fail SPF validation at their destination inboxes.

SPF checks the RFC 5321 Return-Path (envelope sender) IP address. When an email is automatically forwarded, the forwarding server's IP does not match the original sender's SPF record. To resolve this, deploy DKIM (DomainKeys Identified Mail) cryptographic signing alongside SPF and establish DMARC alignment, which allows forwarded emails to authenticate successfully via DKIM even when SPF breaks.

Frequently Asked Questions

What is SPF and how does it prevent email spoofing?▼

Sender Policy Framework (SPF, RFC 7208) is an open DNS-based email validation standard. Domain owners publish a TXT record specifying authorized sending IP addresses and mail servers. Receiving Mail Transfer Agents (MTAs) inspect the sender's IP during the SMTP transaction against the SPF record of the domain declared in the envelope Return-Path (RFC 5321.MailFrom). If an unlisted IP attempts to deliver mail claiming to be from the domain, receiving servers reject or flag it as spoofed.

What is the practical difference between '~all' (SoftFail) and '-all' (HardFail)?▼

Both qualifiers define what receiving servers should do with mail from unauthorized IPs. '-all' (HardFail) explicitly commands receivers to reject unauthorized messages during the initial SMTP handshake. '~all' (SoftFail) signals that unauthorized emails should be accepted but tagged as suspicious or routed to junk folders. In modern email ecosystems using DMARC, '~all' is widely favored because it prevents false-positive rejections caused by indirect mail flows like email forwarding, while DMARC handles quarantine/reject enforcement.

Why is the 10-DNS-lookup limit so strictly enforced by mail providers?▼

RFC 7208 establishes a hard ceiling of 10 DNS lookups to protect receiving mail systems against Denial-of-Service (DoS) and amplification attacks. Without lookup caps, malicious actors could craft circular or excessively deep SPF records that trigger massive cascades of DNS queries every time an email is received. Any record that requires an 11th DNS query immediately generates an SPF PermError.

Does SPF authenticate the 'From' address visible to human recipients?▼

No. SPF validates only the envelope sender (RFC 5321 'Return-Path' or 'MAIL FROM' address used for bounce messages), NOT the user-facing header address (RFC 5322 'From'). Phishing attackers can send an email with an authorized envelope address while displaying a forged brand name in the visible 'From' field. To prevent this discrepancy, you must implement DMARC (RFC 7489), which enforces alignment between the visible 'From' domain and the authenticated SPF or DKIM domain.

Can I use subdomains with SPF, and do subdomains inherit the root domain's SPF record?▼

Subdomains do NOT automatically inherit the parent domain's SPF record. Under RFC 7208, SPF evaluation is performed against the exact hostname in the Return-Path. If an email is sent from '[email protected]', the receiving server queries the TXT record for 'news.example.com'. If no SPF record exists on the subdomain, it defaults to 'None' (neutral), even if 'example.com' has a strict SPF policy. You must publish dedicated SPF records for all active sending subdomains.

Related Tools & Utilities

All Tools →
DNS DMARC Policy Record Builder & Syntax ValidatorSecurity

Generate RFC 7489 compliant DMARC DNS TXT records with policy enforcement (none/quarantine/reject), rua/ruf aggregate reports, and alignment tags.

Open tool→
DNS CAA (Certification Authority Authorization) Record GeneratorSecurity

Construct RFC 8659 compliant DNS CAA records to restrict SSL/TLS certificate issuance to trusted authorities (Let's Encrypt, DigiCert, Sectigo).

Open tool→
DNS DKIM TXT Record Builder & Selector HelperSecurity

Generate RFC 6376 compliant DNS DKIM TXT records with selector, public key formatting (v=DKIM1; k=rsa; p=...), and verification guidance.

Open tool→
MTA-STS Policy & TLS-RPT DNS Record GeneratorSecurity

Generate RFC 8461 Mail Transfer Agent Strict Transport Security (MTA-STS) policy files and _mta-sts/_smtp._tls DNS TXT records.

Open tool→
JWT Token Decoder & Security InspectorSecurity

Decode JSON Web Tokens, inspect header/payload claims, calculate expiration time and verify integrity locally.

Open tool→
Cryptographically Secure Password GeneratorSecurity

Generate ultra-secure passwords using Web Crypto API with custom length, symbols, and memorability.

Open tool→