The SPF record format is one line of text in a DNS TXT record: it starts with v=spf1, lists the servers allowed to send email for your domain, and ends with a rule such as ~all for everyone else. A domain can have only one SPF record, and checking it may take no more than 10 DNS lookups. Build or check yours below.
Use the exact include your provider documents. Each counts as at least 1 lookup.
IPv4 or IPv6, with an optional /range. IPs cost 0 lookups.
Your SPF record (TXT, host @)
Quotes are fine. If you paste two records starting v=spf1, the tool flags it.
Nothing you type is stored or sent anywhere. The tool runs in your browser and makes no DNS queries.
How to use the SPF record builder
Tick every service that sends email with your domain in the From address: your inbox provider, your newsletter or cold email tool, your help desk, your CRM. Add any other include your providers give you, then the IP addresses of servers you run yourself.
The record updates as you type. Copy it and publish it as a TXT record on the root of your domain (the host is usually @). If you already have an SPF record, replace it. Do not add a second one.
Already have a record? Open the Check a record tab and paste it. The tool counts the lookups, flags syntax mistakes and tells you if you have two SPF records.
SPF record format: the parts of a record
Every SPF record follows the same pattern, set out in RFC 7208, the standard that defines SPF:
v=spf1 [mechanisms that list senders] [what to do with everyone else]
| Term | What it means | DNS lookups |
|---|---|---|
v=spf1 |
Marks the record as SPF. Must come first. | 0 |
ip4: / ip6:
|
An IP address or range that may send. | 0 |
include: |
Uses another domain's SPF record, such as your email provider's. | 1, plus anything inside it |
a |
The servers in your domain's A record may send. | 1 |
mx |
Your inbound mail servers may send. | 1 |
exists: |
Advanced check used by some providers, Salesforce among them. | 1 |
ptr |
Reverse DNS check. The standard says not to use it. | 1 |
redirect= |
Hands the whole check to another domain's record. | 1, plus anything inside it |
-all / ~all / ?all
|
Fail, soft fail or neutral for any server not listed. | 0 |
Each mechanism can carry a qualifier in front: + pass (the default), - fail, ~ soft fail, ? neutral. That is why a bare all is dangerous. It means +all, which lets any server pass as you.
How it works: the rules the tool checks
The tool applies the limits in RFC 7208. Here they are, so you can check a record by hand.
-
One record per domain. If a domain has more than one TXT record starting
v=spf1, the result is a permanent error (section 4.5). Each subdomain that sends mail needs its own record. -
No more than 10 DNS lookups.
include,a,mx,ptr,existsandredirecteach count as one.ip4,ip6andallcount as zero. Lookups inside an include count too (section 4.6.4). Go over 10 and SPF fails with a permanent error. - Strings of 255 characters. A single quoted string in a TXT record holds up to 255 characters. Longer records are split into several strings in the same record, which receivers join with no spaces (section 3.3).
-
No match means neutral. If nothing matches and there is no
allorredirect, the result is neutral, as if the record ended in?all(section 4.7). -
Anything after
allis ignored, andredirectis ignored when the record also hasall.
The lookup count for each listed provider is what its include actually used when we resolved it on 10 October 2026, nested includes and all. Mailgun's include:mailgun.org used 5 of your 10 on its own, because it pulls in two more records that each contain further includes. Providers change these records without notice, so recheck before you add a sender to a record that is already near the limit.

Worked example: four senders and the lookup limit
This is an example, not a real company. Example Ltd sends mail through Google Workspace, SendGrid for product email, Mailgun for its newsletter and Salesforce for sales email. Using the counts above:
- Google Workspace: 1
- SendGrid: 2
- Mailgun: 5
- Salesforce: 2
1 + 2 + 5 + 2 = 10 lookups. That is exactly the limit, so the record still passes. Now the support team adds Zendesk, which uses 1 more. 10 + 1 = 11, and every message from the domain fails SPF, including ordinary staff email.
The fix is to move the newsletter to a subdomain such as news.example.com, with its own record for Mailgun. The root record drops to 1 + 2 + 2 + 1 = 6 lookups, and the subdomain record uses 5. Both are inside the limit, with room to grow.
Google and Microsoft 365 SPF records
If Google Workspace is your only sender, Google's own help page gives the record v=spf1 include:_spf.google.com ~all (Google Workspace: set up SPF). For Microsoft 365, Microsoft gives v=spf1 include:spf.protection.outlook.com -all and recommends -all over ~all (Microsoft: set up SPF). Microsoft also advises against swapping its include for a list of IPs, because its addresses change often.
Moving to Google from Microsoft, or using both during a migration? List both includes in one record. Never publish one record per provider. The same applies to GoDaddy and other DNS hosts: their panel is just where you paste the record, and the format does not change.
What good looks like, and what to do next
A healthy record lists every real sender, uses 8 lookups or fewer so you have room for the next tool, has no ptr, and ends in ~all or -all. Domains that never send email should publish v=spf1 -all so nobody can pass as them.
SPF is one of three checks. Set up DKIM signing in each sending tool, then publish a DMARC record so receivers know what to do when a message fails. For cold email, those three checks decide whether you reach the inbox before anyone reads a word. Our guide to why cold emails go to spam covers the rest of the setup. Then run your copy through the spam words checker, start from one of these B2B cold email templates, and clean your contact list before you send, because bounces hurt your sender reputation too.
Need people to send to? Our find customers tools give you verified B2B contacts and decision makers, so the mail your new SPF record protects reaches real inboxes.
FAQ
What is the correct SPF record format?
One TXT record that starts with v=spf1, then the senders you allow (ip4, ip6, include, a or mx), then a final rule for everyone else, usually ~all or -all. For example: v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all. Separate the terms with single spaces and publish only one SPF record per domain or subdomain.
How do I combine two SPF records into one?
Keep one v=spf1 at the start, copy every include, ip4 and ip6 term from both records into it, drop the duplicates, and end with a single all. Then delete the second record. Two SPF records on the same domain give a permanent error, so SPF fails for every message until they are merged.
What happens if my SPF record has more than 10 lookups?
Receivers stop checking and return a permanent error, which counts as an SPF failure. With DMARC in place, that can send legitimate mail to spam or get it rejected. Cut the count by removing tools you no longer use, moving one sender to a subdomain with its own record, or replacing a stable include with the provider's IP ranges.
Should I use ~all or -all?
Start with ~all while you confirm every service that sends as you, then move to -all once your reports show nothing legitimate failing. Microsoft recommends -all for Microsoft 365 domains. Never use +all or a bare all, because that lets any server in the world pass SPF for your domain.
Does the order of terms in an SPF record matter?
Partly. Receivers read terms from left to right and stop at the first match, and anything after all is never read. So all must come last. Putting ip4 and ip6 entries before includes can save lookups for mail from those servers, but every include still counts toward the limit of 10 if the check reaches it.
Leave a comment: