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.

[alterable_spf_record_generator]

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:

  1. Your mail server(s): If you send mail from your own server, add the IP addresses or hostname using ip4:, ip6:, or a: mechanisms.
  2. 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.
  3. Enforcement level (the all qualifier): 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 you@yourdomain.com, 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 we’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.

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.