If you’ve ever had an email bounce with a message about SPF failure, or found your newsletter sitting in spam despite a clean list, there’s a good chance your SPF record is either missing, misconfigured, or out of date. SPF (Sender Policy Framework) is one of the foundational pieces of email authentication, and it’s been around long enough that mailbox providers treat a missing record as a red flag.
This free SPF record generator builds the DNS TXT record for you. Add your sending sources, choose your enforcement level, and copy the result directly into your DNS.
Your Domain
Sending Sources
Add every server or service authorised to send email for your domain.
No mechanisms added yet. Use the controls above to add sending sources.
Default Policy (all)
Defines what to do with email sent from servers not listed above.
Your SPF Record
v=spf1 ~all
How to publish this record
- Log in to your DNS provider (Cloudflare, Namecheap, GoDaddy, Route 53, etc.)
- Create a new TXT record on the root domain (
@or blank host). - Paste the generated value above into the Value / Content field.
- Set TTL to 3600 (1 hour) or leave as default.
- Save and allow up to 48 hours for propagation.
Tip: You can only have one SPF TXT record per domain. If one already exists, edit it rather than creating a new one.
Existing Record Lookup
Check whether a domain already has an SPF record published.
How to use this SPF record generator
SPF works by listing, in a DNS record, every source that’s authorized to send email from your domain. The generator takes your inputs and formats them correctly. Here’s what to provide:
- Your mail server(s): If you send mail from your own server, add the IP addresses or hostname using
ip4:,ip6:, ora:mechanisms. - Third-party senders: For every ESP, CRM, or platform that sends on your behalf, think Mailchimp, HubSpot, Postmark, Salesforce, Google Workspace, you’ll use an
include:reference to their SPF record. Check each platform’s documentation for the exact value to use. - Enforcement level (the
allqualifier): This is what happens to mail that doesn’t match any authorized source.
Once you’ve added your sources, copy the generated record and publish it as a TXT record at your root domain (yourdomain.com) in your DNS.
What is an SPF record, and why does every domain need one?
SPF stands for Sender Policy Framework. It’s a DNS record that lists the IP addresses and servers authorized to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from [email protected], it checks your DNS for an SPF record and compares the sending IP against your authorized list.
If the IP matches: pass. If it doesn’t: fail (or softfail, depending on your policy). That result feeds into the receiving server’s filtering decisions, and into your DMARC policy, if you have one set up.
SPF doesn’t stop spam on its own. But without it, your domain has no way of asserting who is and isn’t authorized to send on your behalf. That ambiguity is what spammers and phishers exploit.
Since Google and Yahoo’s 2024 bulk sender requirements, SPF has gone from strongly recommended to functionally required for senders above certain volume thresholds. Even below those thresholds, the deliverability case for having a valid SPF record is straightforward.
Understanding the all mechanism
The all mechanism at the end of an SPF record is where senders make a choice, and I’ve seen a lot of records get this wrong. Here’s what each option means:
~all (softfail): Mail from unauthorized sources is marked as suspicious but usually delivered. Most receiving servers treat this as a warning signal rather than a hard failure. This is where many senders sit, and it’s a reasonable starting point if you’re not sure you’ve captured all your sending sources yet.
-all (hardfail): Mail from unauthorized sources should be rejected. This is the stricter, more protective setting. If you’re confident your SPF record includes everything that legitimately sends on your behalf, -all is the right choice.
?all (neutral): No policy. The record essentially says “I have an SPF record but I’m not making any claims about non-matching sources.” Avoid this, it defeats the purpose.
+all (pass all): Never use this. It authorizes any server to send on your behalf, which makes the record meaningless. If you see this in a record, something went wrong.
The practical question is: how confident are you that your SPF record is complete? If you’re just getting started, ~all gives you some protection without risking legitimate mail being rejected while you’re still finding all your sending sources. Once you’ve audited your setup, move to -all.
The 10-lookup limit: the thing most people run into
SPF has a technical constraint that trips up a lot of senders: you’re limited to 10 DNS lookups per SPF evaluation. Every include:, a:, mx:, and redirect= mechanism triggers a lookup. Add a few ESPs, a CRM, a transactional provider, and a marketing automation tool, and you can hit that limit faster than you’d expect.
When you exceed 10 lookups, the SPF check results in a permerror, which many receiving servers treat the same as a failure. Your record technically exists, it just can’t be fully evaluated.
If you’re hitting this limit, a few options:
- Audit and remove inactive senders. It’s common to have
include:entries for platforms you no longer use. - Use SPF flattening. This replaces nested
include:chains with the actual IP addresses they resolve to, reducing lookup count. Some tools automate this, though flattened records need periodic updating as provider IPs change. - Check if your providers have consolidated their SPF records. Some large ESPs publish compact records specifically to reduce lookup depth.
SPF and DMARC: how they work together
SPF alone doesn’t enforce much. The real protection kicks in when SPF is combined with DMARC. Here’s why: DMARC checks whether the domain in the From: header aligns with the domain that passed SPF. This alignment requirement is what prevents a spammer from passing SPF on their own domain while spoofing your From: address.
So the flow is: SPF verifies the sending source → DMARC checks alignment → your DMARC policy decides what to do with failures.
If you haven’t set up a DMARC record yet, our free DMARC record generator will walk you through it. The two tools are designed to be used together.
Frequently asked questions
How do I find what to include in my SPF record?
Start with what sends email from your domain. That typically includes: your mail server or Google/Microsoft Workspace, your ESP (the platform you use for newsletters and campaigns), your transactional email provider, and any CRM or marketing platform that sends emails on your behalf. Each of these should have documentation listing the include: value for their SPF.
Can I have multiple SPF records for one domain?
No. You can only have one SPF record per domain, and it must be a single TXT record. If you publish two, SPF evaluation will fail with a permerror. If you need to authorize multiple senders, they all go in the same record, separated by spaces.
How long does SPF propagation take?
DNS changes typically take a few hours to propagate fully, though it can be up to 48 hours in some cases. You can test your SPF record immediately after publishing using our Email Deliverability Test.
What does an SPF failure actually mean for deliverability?
On its own, an SPF failure is a signal, not a definitive block. Most mailbox providers factor it into a broader spam scoring assessment. The impact depends on your overall sending reputation, whether you have DMARC configured, and whether the receiving server weights authentication failures heavily. That said, consistent SPF failures erode trust with mailbox providers over time. It’s worth fixing.
Does SPF work for forwarded emails?
This is a known limitation of SPF. When an email is forwarded, the forwarding server’s IP won’t be in the original sender’s SPF record, so the check fails. This is one of the reasons DKIM exists — DKIM signatures survive forwarding. It’s also why DMARC with only an SPF alignment requirement can cause problems for forwarded mail. Most setups rely on DKIM alignment for DMARC when forwarding is a concern.
My SPF record already exists, can I just edit it?
Yes. If you already have an SPF record, you shouldn’t create a new one, edit the existing TXT record to add new mechanisms. Creating a second SPF record will break SPF evaluation for your domain.
SPF is one layer. The full picture includes DKIM (which your ESP typically handles) and DMARC (which ties everything together and gives you reporting). Once you’ve published your SPF record, check your whole setup with our free Email Deliverability Test — it verifies SPF, DKIM, and DMARC in one pass and shows you what receivers actually see.
If you send personalized, real-time content through Alterable, a clean authentication setup is what gives those campaigns the best chance of landing in the inbox. Build the foundation first.