Enter Your Domain
Start by entering the domain you want to create an SPF record for.
What is SPF?
SPF (Sender Policy Framework) is an email authentication protocol defined in RFC 7208. It works by publishing a DNS TXT record under your domain listing every IP address or hostname allowed to send mail "from" that domain. When a receiving mail server gets a message claiming to be from you, it queries your DNS to verify whether the sending server's IP is on your approved list.
Without SPF, anyone can forge the return-path (envelope From) of an email and make it appear to come from your domain — a technique commonly used in phishing and spam campaigns.
Why do you need SPF?
1Prevents spoofing
Stops bad actors forging your domain as the sending address
2Improves deliverability
Receiving servers trust authorized senders and reduce spam scores
3Required for DMARC
SPF is one of two mechanisms DMARC relies on for alignment
4Reputation protection
Unauthorized senders can't damage your domain's sending reputation
How SPF works — step by step
You publish a TXT record at `_your-domain.com` listing authorized IPs and includes.
Your mail server sends an email; the envelope "From" address carries your domain.
The receiving server extracts the sending IP and the envelope From domain.
It queries your DNS for the SPF record and checks if the sending IP is listed.
Result is `pass`, `fail`, `softfail`, `neutral`, or `permerror` — used in spam filtering decisions.
SPF record syntax
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net -allMechanism breakdown
v=spf1— version, always firstip4:— authorize an IPv4 address/rangeip6:— authorize an IPv6 address/rangeinclude:— inherit another domain's SPFa— authorize the domain's A record IPmx— authorize the domain's MX serversredirect=— delegate to another domain's full SPFQualifiers (prefix each mechanism)
+ (default)Pass — authorized-Fail — reject unauthorized senders~SoftFail — mark as suspicious, don't reject?Neutral — no assertionCommon SPF failures and fixes
Too many DNS lookups
Flatten your SPF record by replacing includes with raw IPs, or use an SPF flattening service
Missing a sending service
Add the service's include: tag (e.g. Mailchimp, Zendesk) to your SPF record
Multiple SPF records
Only ONE TXT record with v=spf1 is allowed — merge them into a single record
Forwarded emails
SPF breaks on forwarding because the forwarding server's IP isn't in your list — DKIM solves this
Frequently Asked Questions
Creating a valid SPF record involves identifying every service that sends email for your domain (e.g., Google Workspace, Shopify, Zendesk). Use our generator to add these as 'include' mechanisms. Always end your record with a catch-all mechanism like ~all or -all to define what happens to unauthorized mail.
You can authorize specific IP addresses using the 'ip4:' or 'ip6:' mechanisms. For example, ip4:1.2.3.4 authorizes a single IP, while ip4:1.2.3.4/24 authorizes a whole range. This is often the most efficient way to authorize your own web servers or internal mail relays without adding to the DNS lookup limit.
The most common mechanisms are 'v=spf1' (version), 'include' (authorize another domain's SPF), 'ip4'/'ip6' (authorize specific IPs), 'a' (authorize domain's A record), and 'mx' (authorize domain's MX servers). Understanding these allows you to build a comprehensive and accurate record that covers all your sending scenarios.
Whenever possible, use 'ip4' or 'ip6' for your own servers. These mechanisms do not require a DNS lookup, helping you stay well below the 10-lookup limit. Use 'include' only for third-party services (like Mailchimp or HubSpot) where the service provider's IP addresses might change frequently.
You simply list multiple 'include' mechanisms in a single record. For example: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Just be careful not to exceed the 10 DNS lookup limit. If you have too many providers, you may need to use subdomains for some services or implement an SPF flattening solution.
Both tell receivers what to do with mail from servers not listed in your SPF record. -all (hard fail) instructs them to reject unauthorized mail, while ~all (soft fail) tells them to accept but mark it suspicious. Use ~all while testing and move to -all once you're confident every legitimate sender is included.
SPF changes usually propagate within a few minutes to a couple of hours, but can take up to 24 to 48 hours depending on your DNS provider's TTL setting. Lowering the TTL before making changes helps updates take effect faster.
Publish the record in your DNS, then run an SPF checker to confirm it resolves, stays within the 10 DNS-lookup limit, and authorizes all your sending sources. Sending a test email to a seed address and checking the headers for spf=pass is the final confirmation.