Want to learn more?
Learn SPF record syntax, mechanisms, and how to create records that prevent email spoofing.
Read the guide+1 more fields
SPF Record Too Complex?
Our team optimizes SPF records, manages DNS lookups, and prevents authentication failures.
What Is SPF (Sender Policy Framework)
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.
How SPF Works
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 assertion
Example 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.
Common Use Cases
- Email security: Prevent attackers from spoofing your domain in phishing emails sent to customers and partners
- Email deliverability: Properly configured SPF reduces the chance of legitimate emails being marked as spam
- Compliance: Standards like NIST 800-177 and CMMC require SPF as part of email security controls
- Vendor onboarding: Verify that third-party services (CRM, marketing, support) are included in your SPF record before they send on your behalf
- Domain reputation management: SPF failures contribute to poor domain reputation scores at major email providers
Best Practices
- Always end with -all (hard fail) — This tells receivers to reject unauthorized senders; ~all (soft fail) is weaker and should only be used during initial deployment
- Stay under 10 DNS lookups — SPF is limited to 10 DNS lookups; use ip4/ip6 mechanisms instead of nested includes where possible
- Include all legitimate senders — Missing a third-party sender (marketing platform, ticketing system) causes their emails to fail SPF
- Flatten SPF records if needed — Use SPF flattening tools to resolve includes into IP addresses, reducing DNS lookup count
- Combine with DKIM and DMARC — SPF alone is incomplete; DKIM prevents message tampering and DMARC provides policy enforcement and reporting
References & Citations
- Internet Engineering Task Force (IETF). (2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in Email - RFC 7208. Retrieved from https://datatracker.ietf.org/doc/html/rfc7208 (accessed January 2025)
- Cloudflare. (2024). SPF Record Syntax. Retrieved from https://www.cloudflare.com/learning/dns/dns-records/dns-spf-record/ (accessed January 2025)
- Google. (2024). Email authentication best practices. Retrieved from https://support.google.com/a/answer/33786 (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Key Security Terms
Understand the essential concepts behind this tool
SPF (Sender Policy Framework)
Email authentication method that specifies which mail servers are authorized to send email on behalf of your domain.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Email validation system that builds on SPF and DKIM to prevent email spoofing and provide reporting on email authentication failures.
Frequently Asked Questions
Common questions about the SPF Generator
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.