Free Tool
Free SPF record generator
Create your SPF record in minutes
Build a valid SPF TXT record to authorize your senders and protect your deliverability. Pick your providers, add your own IPs, and copy a record that is correct on the first try.
No signup required. Real-time validation.
Select your email providers
Start with providers that clearly require root-domain SPF includes. Many others are setup-dependent: default modes usually rely on DKIM, while custom Return-Path or MAIL FROM modes may need SPF on a sender subdomain.
Common root-domain SPF includes
These providers commonly require SPF includes on your main domain record.
Advanced: add custom includes
Use this only when provider documentation explicitly requires an SPF include for your chosen setup (for example custom Return-Path or custom MAIL FROM).
Comma-separated. Includes count toward the 10 DNS lookup limit and may belong on a sender subdomain.
Setup-dependent providers
Default setups often use provider-owned Return-Path domains and DKIM. If you enable custom Return-Path or MAIL FROM, SPF may be required (often on a subdomain).
Transactional email
Default MAIL FROM uses amazonses.com; custom MAIL FROM needs SPF on that subdomain
Automatic CNAME mode usually handles SPF; custom return-path/manual mode may need SPF
SPF usually needed on your sending domain/subdomain
Default provider Return-Path; custom Return-Path supports SPF alignment
DKIM-first setup; some domain modes still require SPF include
Marketing, sales & support
Usually DKIM-based; check docs when custom bounce domain is enabled
Usually DKIM-based; SPF needs depend on plan and sending mode
Email sending domain setup can include SPF requirements
Add include:_spf.salesforce.com when Salesforce sends email for your domain
Can require SPF include when sending on behalf of your domain
SPF may be needed depending on mailbox/authentication setup
Usually provider SPF; custom return-path option can affect SPF alignment
Add custom IP addresses (Optional)
Comma-separated. Supports CIDR notation (e.g., 192.0.2.0/24).
Comma-separated. Supports CIDR notation (e.g., 2001:db8::/32).
Choose your SPF policy
RFC 7208 Warning: These mechanisms are discouraged because they consume DNS lookups and can cause reliability issues. Use ip4/ip6 instead when possible.
Generated SPF record
TXTv=spf1 ~all
Warning: SPF records are limited to 10 DNS lookups. Reduce includes or use IP addresses directly.
How to deploy
- 1 Login to your DNS provider (GoDaddy, Cloudflare, Namecheap, etc).
- 2 Create a TXT record.
-
3
Host:
@or leave empty - 4 Value: Paste the record above.
Verification
Check your SPF configurationYour SPF record is only step one
Publishing SPF does not tell you whether it actually works. DMARC reports show you every source sending as your domain, which ones pass, and which ones fail, so you can fix problems before they hit the inbox.
What is an SPF record?
Sender Policy Framework (SPF) is an email authentication standard that names the mail servers allowed to send for your domain. You publish that list as a single DNS TXT record starting with v=spf1, and receiving servers read it to decide whether a connecting server is allowed to use your domain.
When a server receives your mail, it reads the SPF record on the envelope sender's domain and checks whether the connecting IP is on the list. A match passes SPF. This is one of the signals receivers use to fight email spoofing and decide whether your mail reaches the inbox.
SPF record format and syntax
An SPF record is one line of text with a fixed shape. It opens with the version term v=spf1, then a space-separated list of terms. A receiving server reads the terms left to right and stops at the first one that matches the connecting IP, so the order matters. Each term is an optional qualifier followed by a mechanism. For example, ~all is the qualifier ~ on the mechanism all.
Two terms have a special job. The v=spf1 version term comes first. The all mechanism goes last, because it matches everything the earlier terms did not. Everything in between, the includes, IP ranges, and other mechanisms, is where you list who is allowed to send.
One record per domain. A domain must publish exactly one TXT record that starts with v=spf1. Publish two and a receiver cannot tell which one to trust, so SPF returns a PermError and the check fails (RFC 7208 §4.5). If a single string runs past 255 characters, split the value across multiple quoted strings inside the same TXT record. The receiver joins them with no added spaces (RFC 7208 §3.3).
The full grammar lives in RFC 7208, the standard that defines SPF.
SPF mechanisms reference
SPF defines eight mechanisms (RFC 7208 §5). The right-hand column is the one most broken records miss: each lookup-causing mechanism spends part of your 10-lookup budget, and going over that budget makes SPF fail. The generator above counts this column live as you build.
| Mechanism | Syntax forms | What it matches | DNS lookups |
|---|---|---|---|
all |
all | Always matches. Placed last to set the default result for senders not listed above it. | 0 |
include |
include:domain | Authorizes every sender in another domain's SPF record. The usual way to add a provider such as Google or SendGrid. | 1 |
a |
a a/prefix a:domain a:domain/prefix | The A or AAAA address of the domain (the current domain if none is given), optionally a whole CIDR range. | 1 |
mx |
mx mx/prefix mx:domain mx:domain/prefix | The addresses of the domain's mail servers (its MX hosts), optionally a whole CIDR range. | 1+ |
ptr |
ptr ptr:domain | The connecting IP if its reverse DNS name ends in your domain. RFC 7208 §5.5 says this mechanism SHOULD NOT be published. | 1 |
ip4 |
ip4:address ip4:range/prefix | One IPv4 address or CIDR range. No DNS query, so it costs nothing against the budget. | 0 |
ip6 |
ip6:address ip6:range/prefix | One IPv6 address or CIDR range. Like ip4, it costs nothing against the budget. | 0 |
exists |
exists:domain | Matches if a DNS query for the (usually macro-built) domain returns an A record. Used for advanced macro setups. | 1 |
The mx mechanism shows "1+" because the receiver looks up the MX record and then resolves each named mail host, and every one of those resolutions counts. Prefer ip4 and ip6 for fixed addresses. They match exactly and cost nothing against the budget.
SPF qualifiers: + - ~ ?
A qualifier is the single character in front of a mechanism. It decides the result when that mechanism matches the connecting IP. Leave it off and SPF assumes + (pass), so include:_spf.google.com means the same as +include:_spf.google.com (RFC 7208 §4.6.2).
| Qualifier | Result | What it tells the receiver |
|---|---|---|
+ |
Pass | The sender is authorized. This is the default, so you almost never write it. You usually only put a qualifier on the all mechanism at the end. |
- |
Fail | The sender is not authorized; reject the mail. Written as -all, this is a hard fail. |
~ |
Softfail | The sender is probably not authorized; accept the mail but treat it as suspicious. Written as ~all. |
? |
Neutral | No statement either way, the same as having no policy. Written as ?all. |
~all vs -all: start with ~all (softfail) while you read your DMARC reports and confirm every legitimate sender is listed. Move to -all (fail) once the list is complete. A premature -all rejects any sender you forgot, and it can also break mail that was forwarded, because forwarding changes the sending server.
Modifiers: redirect and exp
Most generators skip these two, but they are part of the standard and you will meet them in real records (RFC 7208 §6). A modifier is written as name=value and, unlike a mechanism, appears at most once.
redirect=domain
Hands evaluation to another domain's SPF record and uses its result, including its all mechanism. Useful when many domains share one policy. It counts as one DNS lookup against your budget, and it is ignored if the record already has an all mechanism (RFC 7208 §6.1).
exp=domain
Points to a TXT record holding a human-readable explanation that a receiver may show when SPF fails. It does not change the result, and its lookup does not count toward the 10-lookup limit (RFC 7208 §6.2, §4.6.4).
The 10 DNS-lookup limit
SPF caps how much DNS work a receiver will do for your record. At most 10 lookup-causing terms may run during evaluation (RFC 7208 §4.6.4). The mechanisms include, a, mx, ptr, and exists, plus the redirect modifier, each count. The terms ip4, ip6, all, and exp do not.
The catch is that an include pulls in another record, and that record's own includes count too. So three or four provider includes on your own line can quietly add up to more than ten. Cross the limit and SPF returns a PermError. Receivers treat that as a failure, which means SPF cannot pass and your DMARC SPF alignment fails with it.
Void lookups. There is a second, quieter limit. A receiver SHOULD stop after two "void" lookups, queries that return no record at all (RFC 7208 §4.6.4). A typo in an include or a provider that dropped its SPF record can trip this even when your total is under ten.
How we count this in production
The generator on this page counts the lookup column live as you tick providers and add IPs, so you stay under the budget before you ever publish. We run the same logic on real domains. Our analyzer implements RFC 7208 §4.6.4, counts the full nested total an include expands to, tracks void lookups against the limit of two, and excludes exp from the count as the standard requires. When a record is already over the limit, the usual fixes in order of effort are: drop includes for providers you no longer use, swap stable includes for explicit ip4 and ip6 ranges, and only then reach for SPF flattening, which our Pro plan runs automatically every 30 minutes to keep a flattened record fresh.
How SPF, DKIM, and DMARC fit together
SPF rarely stands alone. It is one of three records that work together, and a receiver reads all three. Here is the division of labor:
SPF authorizes the sending server
It answers "is this IP allowed to send for the envelope domain?" SPF checks the envelope sender (the Return-Path or MAIL FROM) and the HELO name, not the From address your reader sees (RFC 7208 §2.4).
DKIM signs the message
Your server adds a cryptographic signature in a header, and the receiver verifies it against a public key in your DNS. A valid signature proves the message was not altered in transit and that it really came from your domain.
DMARC ties them to the visible From
DMARC passes when SPF or DKIM verifies AND aligns with the domain in the From header your reader sees. It also tells receivers what to do on failure (none, quarantine, or reject) and where to send reports.
SPF is the first leg. Build the second with our DMARC record generator, then follow the DMARC setup checklist to take your domain from no protection to a reject policy without breaking delivery.
What a real SPF record looks like
Here is a record for a domain that sends through Google Workspace, SendGrid, and one server of its own:
v=spf1
Marks this as an SPF record. Every record opens with it, and a domain may publish only one.
include:_spf.google.com
Pulls in Google's published list of sending IPs. Each include is one DNS lookup against the 10-lookup budget.
include:sendgrid.net
Authorizes SendGrid the same way. Two includes so far means two lookups used.
ip4:198.51.100.10
Authorizes one server you run directly by its address. An ip4 or ip6 mechanism costs zero lookups, so favor it for fixed IPs.
~all
Catches every sender not listed above and softfails it. Mechanisms are read left to right, so the all term always comes last.
How SPF authentication works
Receivers run SPF during the SMTP conversation, before they accept the message:
A server connects
Your mail server opens a connection to the recipient's server and presents an envelope sender address and a source IP.
The receiver looks up SPF
It takes the domain from the Return-Path (the envelope sender) and queries DNS for that domain's SPF record.
The IP is checked
It walks the record's mechanisms in order and asks whether the connecting IP is authorized by any of them.
A result is assigned
The match and your trailing qualifier produce a verdict: pass, fail, softfail, or neutral.
The verdict feeds filtering
SPF joins DKIM and DMARC as inputs to the receiver's spam and authentication decision.
Why your domain needs SPF
A domain without SPF is easier to impersonate and harder to deliver from. What you get by publishing one:
Harder to spoof
SPF names the servers allowed to send for you. Without it, anyone can forge your address from any server and recipients have no way to tell.
Better deliverability
Gmail, Microsoft, and Yahoo all read SPF. Mail from a domain with no SPF is more likely to land in spam or be turned away.
Meets bulk-sender rules
Since February 2024, Google and Yahoo require bulk senders (roughly 5,000+ messages a day) to publish SPF, DKIM, and a DMARC record. SPF is one leg of that requirement.
Feeds DMARC alignment
DMARC passes when SPF or DKIM aligns with your From domain. SPF is one of the two paths, so it directly affects whether DMARC protects you.
Protects your reputation
When someone spoofs your domain, the recipients who get the phishing blame your brand. SPF is part of shutting that down.
Common SPF mistakes to avoid
Most broken SPF records fail for one of these reasons:
Crossing 10 DNS lookups
Each include, a, mx, ptr, exists, and redirect counts toward the limit of 10. Go over and SPF returns PermError. Swap includes for ip4/ip6 where the IPs are stable.
Publishing two SPF records
A domain may have exactly one record starting with v=spf1. Two of them is an automatic PermError. Merge everything into a single record.
Adding includes you do not need
Many providers send from their own Return-Path, so a root-domain include just burns a lookup. Add one only when the provider's docs say to, usually for custom Return-Path or MAIL FROM.
Reaching for -all too soon
Hardfail rejects any sender you forgot to list, including your own. Stay on ~all with DMARC monitoring until your reports show every legitimate source.
Forgetting your own servers
Contact forms, app notifications, and monitoring scripts send mail too. If a server of yours sends, its IP belongs in the record.
Subdomains need their own record
SPF does not cascade. A record on example.com says nothing about mail sent from mail.example.com or news.example.com. Every subdomain that sends email needs its own SPF record at its own name.
For a subdomain that never sends mail, publish a record that authorizes nothing: v=spf1 -all. That hardfails anyone who forges mail from it, which closes a path attackers like to use.
Test it after you publish
DNS changes take time to propagate, from a few minutes to a few hours. Once the record is live, read it back from the command line before you trust it:
macOS or Linux
Windows
A correct result echoes the exact string you published, for example:
Prefer a browser? Run the same check on our free domain checker for a plain-language verdict on SPF, DKIM, and DMARC.
How to create an SPF record for your domain
Tick the providers that require a root-domain include, add the IPs of any servers you run, add provider includes from their docs when needed, and choose a policy. The tool builds valid SPF as you go and you copy the result into DNS.
For many transactional and marketing providers, a root-domain include is optional. They send from their own Return-Path and rely on DKIM for DMARC alignment. Add an include only when you switch on custom Return-Path or MAIL FROM, and then it usually belongs on the sending subdomain.
SPF is one step. Follow the DMARC setup checklist to take your domain from no protection to a reject policy without breaking delivery.
Frequently asked questions
What is an SPF record and why do I need one for email?
An SPF record (Sender Policy Framework) is a DNS TXT record that lists the mail servers allowed to send email for your domain. Without it, receivers like Gmail and Outlook are more likely to mark your mail as spam or reject it. Since February 2024, Google and Yahoo require SPF for bulk senders.
How do I generate an SPF record for my domain?
Enter your domain in the tool above, select the providers that send mail for you (Google Workspace, Microsoft 365, and so on), add any custom IP addresses, choose a policy, and copy. The generator assembles correct SPF syntax for you.
Where do I add my SPF record in DNS?
Add it as a TXT record at your domain root (host @ or blank). Log into your DNS provider (GoDaddy, Cloudflare, Namecheap, Route 53, and the like), create one TXT record, and paste the generated value. Publish only one record starting with v=spf1.
What is the SPF 10 DNS lookup limit?
An SPF record may trigger at most 10 DNS lookups when a receiver evaluates it. The include, a, mx, ptr, exists, and redirect mechanisms count; ip4, ip6, and all do not. Cross 10 and SPF returns a PermError, which receivers treat as a failure. The counter on this page tracks your total live.
What is the difference between ~all and -all in SPF?
~all (softfail): receivers accept mail that fails SPF but treat it as suspicious. This is the right setting while you watch DMARC reports, because DMARC makes the final call.
-all (fail): receivers reject mail that fails SPF. The strictest option, and worth moving to once every legitimate sender is listed. It can break some forwarding.
?all (neutral): the result carries no weight, which is the same as having no policy. Avoid it in production.
Why does SPF check the Return-Path instead of the From address?
SPF authenticates the envelope sender, the Return-Path or MAIL FROM, plus the HELO name. It does not look at the visible "From" header your recipients read. Many providers put their own domain in the Return-Path (for example mcsv.net for Mailchimp), so the SPF check runs against their servers, not yours.
DMARC needs alignment to pass. Default provider setups usually get there through DKIM signing with your domain, which means no extra SPF include on your root.
This is setup-dependent. Switch on a custom Return-Path or MAIL FROM on your own domain or subdomain and SPF becomes required for that sender domain.
Learn more about Return-Path and provider SPF requirements →
How do I check which Return-Path my provider uses?
Send yourself a test message through the provider and read the headers:
- Gmail: open the message, click the three-dot menu, choose "Show original".
- Outlook: open the message, then File → Properties → "Internet headers".
Find the Return-Path line. If it shows your domain or a subdomain you control (such as [email protected]), that sender domain needs SPF. If it shows the provider's domain (such as [email protected]), the provider handles SPF and DKIM is your alignment path.
Where can I find official SPF documentation for each provider?
Each provider documents its own SPF setup. Direct links:
Email platforms
Transactional email
Marketing email
Support & CRM
What is an SPF PermError?
A PermError (permanent error) means a receiver could not evaluate your SPF record. The usual cause is crossing the 10-lookup limit; a second cause is publishing two records that start with v=spf1. Receivers treat a PermError as a failure, so DMARC alignment on SPF fails with it.
Fix it in order of effort:
- Drop includes for providers you no longer use.
- Replace stable includes with explicit
ip4/ip6mechanisms. - Use SPF flattening for providers with dynamic IP ranges. Our Pro plan automates this.
How do I fix SPF too many DNS lookups?
SPF returns PermError once the record needs more than 10 DNS lookups. To get back under the limit:
- Count every
include,a,mx,ptr,exists, andredirectin your record. Each is one lookup. - Remove senders you no longer use.
- Replace heavy includes with
ip4/ip6where the IPs hold steady. - For providers with changing IPs, use SPF flattening so the record is rebuilt automatically.
What is the difference between softfail (~all), neutral (?all), and hardfail (-all)?
~all (softfail): receivers accept unauthorized mail but mark it suspicious. Use it while you monitor with DMARC.
-all (hardfail): receivers reject unauthorized mail outright. Move here once every legitimate sender is in your record.
?all (neutral): receivers act as if no SPF record existed. It defeats the point of publishing one.
How do I read an SPF record?
Read it left to right. The record opens with v=spf1, then each space-separated term is an optional qualifier plus a mechanism. A receiver checks the connecting IP against each term in order and stops at the first match. So v=spf1 include:_spf.google.com ip4:198.51.100.10 ~all means: allow Google's senders, allow that one IP, and softfail everyone else.
What is the difference between an SPF mechanism, qualifier, and modifier?
A mechanism describes who can send (include, ip4, a, mx, and the rest). A qualifier is the + - ~ ? in front of a mechanism that sets its result. A modifier (redirect, exp) is written as name=value and changes how the whole record is evaluated rather than matching an IP.
Complete your email authentication
SPF is just one part of email authentication. Combine it with DKIM and DMARC for complete protection against spoofing and phishing.