Free SPF generator tool. Create custom SPF DNS records to authorize mail servers and prevent email spoofing.
SPF (Sender Policy Framework) is an email authentication protocol that allows domain owners to specify which mail servers are authorized to send email on behalf of their domain. Published as a DNS TXT record, SPF helps receiving mail servers distinguish legitimate messages from spoofed ones—making it a critical defense against email spoofing, phishing, and business email compromise.
Without SPF, any server in the world can claim to send email from your domain, and the receiving server has no way to verify the claim. SPF addresses this by creating a publicly queryable list of authorized sending sources. When configured alongside DKIM and DMARC, SPF forms part of the email authentication triad that protects organizations from domain impersonation.
An SPF record is a DNS TXT record published at the domain's root. When a mail server receives a message, it extracts the sender's domain from the MAIL FROM (envelope sender) and queries DNS for the SPF record. It then evaluates the sending server's IP address against the authorized sources listed in the record.
SPF record syntax:
| Mechanism | Meaning | Example |
|---|---|---|
| ip4: | Authorize an IPv4 address or range | ip4:203.0.113.0/24 |
| ip6: | Authorize an IPv6 address or range | ip6:2001:db8::/32 |
| a | Authorize the domain's A record IPs | a |
| mx | Authorize the domain's MX record IPs | mx |
| include: | Include another domain's SPF record | include:_spf.google.com |
| redirect= | Use another domain's SPF record entirely | redirect=_spf.example.com |
| all | Catch-all for non-matching IPs | -all (hard fail) |
Qualifier prefixes:
+ (pass) — Default; IP is authorized- (hard fail) — IP is NOT authorized; reject the message~ (soft fail) — IP is NOT authorized; accept but flag? (neutral) — No policy assertionExample SPF record:
v=spf1 ip4:203.0.113.5 include:_spf.google.com include:sendgrid.net -all
This authorizes: one specific IP, Google Workspace servers, SendGrid servers, and hard-fails everything else.
Sender Policy Framework (SPF) is DNS TXT record listing authorized mail servers for your domain. Format: v=spf1 ip4:192.0.2.0 include:_spf.google.com ~all. Recipient mail servers check if sending IP matches SPF record. Prevents email spoofing by validating sender. Mechanisms: ip4/ip6 (IP addresses/ranges), include (third-party SPF), a/mx (domain A/MX records), all (default policy). Essential email authentication with DKIM/DMARC.
List all mail servers sending from your domain: your mail server IPs, email service providers (Google, Microsoft), marketing tools (Mailchimp, SendGrid). Format: v=spf1 [mechanisms] [qualifier]all. Example: v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:spf.protection.outlook.com ~all. Add TXT record at root domain. Test: send email, check headers for SPF pass. Limit: 10 DNS lookups max. Use include: for third parties, not nested includes.
SPF qualifiers define handling for matching mechanisms. Four types: + (pass) - explicitly allowed, default if omitted. - (fail) - hard fail, reject email. ~ (softfail) - accept but mark suspicious. ? (neutral) - no policy. Example: v=spf1 ip4:192.0.2.0 ~all (allow IP, soft fail others). Recommendation: use ~all (softfail) initially, upgrade to -all (hard fail) after testing. Too strict -all causes false positives from forwarding.
SPF RFC limits DNS lookups to 10 to prevent DoS attacks. Mechanisms requiring lookups: include, a, mx, ptr (avoid ptr), exists. Does not count: ip4, ip6, all. Exceeding limit causes SPF permanent error (treated as no SPF). Solutions: flatten SPF (replace includes with IPs), use SPF flattening services, remove unnecessary includes, consolidate third-party senders. Monitor: SPF record size (<450 chars recommended), lookup count.
Use include: mechanism for third-party email services. Example: include:_spf.google.com for Google Workspace, include:spf.protection.outlook.com for Microsoft 365, include:servers.mcsv.net for Mailchimp. Each include counts toward 10 lookup limit. Order does not matter for includes. Verify: third party provides SPF include record. Multiple includes allowed. Test after adding: dig TXT domain.com, check SPF syntax, send test emails.
SPF failure means sending IP not authorized in SPF record. Result depends on: SPF qualifier (-all vs ~all), DMARC policy (none/quarantine/reject), receiving server policy. Outcomes: email rejected (DMARC p=reject), marked spam (p=quarantine), delivered with warning (~all). Legitimate failures: forwarding (breaks SPF, but DKIM survives), misconfigured SPF, missing include. Fix: update SPF record, configure forwarding (SRS), implement DKIM.
Start with ~all (softfail) for testing - accepts email but marks suspicious. Allows identifying legitimate senders missing from SPF. After 2-4 weeks monitoring: no false positives? Upgrade to -all (hard fail) for stronger protection. Use -all only if: confident SPF is complete, DKIM configured (survives forwarding), monitoring DMARC reports. Email forwarding breaks SPF - ~all prevents false positives. Modern approach: -all with DMARC alignment.
Forwarding breaks SPF - forwarded email sent from different IP than SPF authorizes. Solutions: 1) SRS (Sender Rewriting Scheme) - rewrites envelope sender to forwarder domain. 2) DKIM - survives forwarding, provides authentication. 3) Use ~all instead of -all in SPF. 4) Configure forwarders to use SRS. Best: implement SPF, DKIM, and DMARC. DMARC requires only one (SPF or DKIM) to pass. DKIM alignment handles forwarding.