SPF Record Generator: Fix Email Deliverability and Prevent Spam Issues

Key takeaways:

• An SPF record tells receiving mail servers which servers are authorized to send email from your domain — without one, your emails are more likely to land in spam or get rejected outright.
• A free SPF record generator handles the syntax so you don’t have to learn the format by hand — you select your sending sources, copy the output, and publish it in DNS.
• SPF has a hard limit of 10 DNS lookups. Exceed it and your record fails silently — a problem most people don’t discover until deliverability drops.

If you’ve ever had emails land in spam despite doing everything else right — good copy, verified list, warmed domain — the problem might be something you can’t see: your SPF record is missing, broken, or misconfigured.

SPF — Sender Policy Framework — is one of the three foundational email authentication protocols, alongside DKIM and DMARC. It works by publishing a list of authorized mail servers in your domain’s DNS. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to see if the sending server is on that list. If it’s not, the email fails authentication — and depending on how the receiving server is configured, it may end up in spam or get rejected entirely.

Setting up SPF correctly isn’t complicated, but it does require getting the syntax right and understanding a few rules that aren’t obvious. An SPF record generator takes care of the formatting — you select your sending sources, the tool builds the record, you publish it.

This guide covers what SPF actually does, how to use the generator to build your record, how to publish it correctly, and how to avoid the mistakes — especially the 10-lookup limit — that break SPF quietly and are hard to diagnose after the fact.

Why SPF matters for email deliverability

SPF is one of the first things receiving mail servers check when deciding what to do with an incoming email. Not the only thing — reputation, content, engagement signals all play a role — but it’s a foundational check that happens before most others.

Without a valid SPF record, your domain has no way of telling receiving servers which sends are legitimate. The result:

• Increased spam filtering. Many mail servers treat email from domains without SPF as inherently less trustworthy. Even if your content is clean and your list is verified, missing SPF creates a signal that works against you.
• Failed authentication in DMARC. If you have or plan to set up DMARC, SPF is one of the two authentication mechanisms it depends on. Email that fails both SPF and DKIM will fail DMARC — and if you’ve set a quarantine or reject policy, those emails won’t be delivered.
• Domain spoofing vulnerability. Without SPF, anyone can send email that appears to come from your domain. Spoofed emails that generate spam complaints or phishing reports can damage your domain reputation even though you didn’t send them.
• Compliance gaps with major providers. Google and Yahoo now require valid SPF for bulk senders. Missing SPF means your emails to Gmail and Yahoo addresses are more likely to be filtered or rejected before a recipient ever sees them.

The good news: SPF is one of the simpler authentication records to set up. One TXT record in your DNS, published correctly, and you’re done. The SPF record generator handles the formatting — you just need to know which sending sources to include.

How an SPF record generator works

An SPF record is a TXT record published at your domain root — yourdomain.com. It follows a specific syntax that lists your authorized sending sources in a format receiving servers can parse. A single mistake in the formatting causes the record to fail or be ignored.

An SPF record generator removes that risk. You select your sending sources from a list of options, choose your enforcement setting, and the tool produces a correctly formatted record string ready to publish.

Here’s what that looks like in practice. Use the generator below:

The generator will ask you to specify your sending sources and policy. Here’s what each part of the record means:

v=spf1 Every SPF record starts with this. It identifies the record type and version.

include: mechanisms These reference the SPF records of third-party sending services. When you send email through Google Workspace, for example, you add include:_spf.google.com to authorize Google’s servers.

Common includes for business email:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• Mailchimp: include:servers.mcsv.net
• SendGrid: include:sendgrid.net
• Reply.io: check your account settings for the specific include

ip4: and ip6: mechanisms If you send email from a specific server with a known IP address, add it directly. Format: ip4:203.0.113.1 or ip4:203.0.113.0/24 for a range.

a and mx mechanisms a authorizes the IP addresses associated with your domain’s A record. mx authorizes the servers listed in your domain’s MX records. Both are common for domains that send directly from their web server or through their mail server.

all — the enforcement qualifier This is the most important part of the record after v=spf1. It tells receiving servers what to do with email that doesn’t match any of the authorized sources.

• ~all (softfail) — Mark failing email as suspicious but deliver it. The right starting point while you’re confirming your sending sources.
• -all (hardfail) — Reject failing email. The goal once you’ve confirmed everything is set up correctly.
• ?all (neutral) — No action on failure. Not recommended for production domains.

A complete SPF record for a domain using Google Workspace and SendGrid looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

The generator builds this for you based on your selections. You don’t need to write it from scratch.

The 10-lookup limit — the most common SPF mistake

This is the part of SPF that trips up even technically experienced teams, so it’s worth explaining clearly before you generate spf record configuration.

Every include: mechanism in your SPF record requires a DNS lookup when a receiving server validates it. SPF has a hard limit of 10 DNS lookups per validation check. Exceed that limit and your SPF record fails — not with an error message, but silently. From the outside, it looks like authentication failure with no obvious cause.

The problem compounds because include: references can chain. When you include _spf.google.com, Google’s SPF record may itself contain multiple includes, each of which counts toward your limit. A record that looks like it has 5 includes might actually consume 12 lookups by the time the chain resolves.

How to stay under the limit:

• Use the ip4: mechanism directly for servers with static IPs instead of include: references where possible
• Remove sending sources you’re no longer using — old includes that aren’t needed anymore still consume lookups
• Use an SPF flattening tool to resolve include chains into direct IP addresses — this eliminates the lookup overhead entirely
• Audit your SPF record regularly, especially after adding new sending tools to your stack

Most SPF record generators will flag when you’re approaching or exceeding the 10-lookup limit. If yours does, take it seriously — a record that exceeds the limit is broken, even if it looks correct.

How to use a free SPF record generator and publish your record

Here’s the full process from opening the tool to having a working SPF record live in your DNS.

Step 1: List every service that sends email from your domain

Before you open the generator, make a complete list of every tool and service that sends email on behalf of your domain. Missing a sending source means email from that source will fail SPF authentication.

Common sources people forget:

• Transactional email services (SendGrid, Mailgun, Postmark)
• Marketing platforms (Mailchimp, HubSpot, Marketo)
• CRM email sends (Salesforce, Pipedrive)
• Outreach and sales engagement tools (Reply.io)
• Help desk tools (Zendesk, Intercom)
• Your web server if it sends notification or form emails

If you’re not sure what’s sending as your domain, check your DMARC reports if you have DMARC set up — they’ll show every IP that’s sent email claiming to be from your domain.

Step 2: Open the SPF generator and add your sources

Open the free spf record generator and add each sending source. For major platforms, select them from the built-in list — the generator knows the correct include reference for each one. For custom servers or IP addresses, enter them directly using the ip4: field.

Set your qualifier to ~all (softfail) to start. You’ll move to -all after you’ve confirmed everything is working correctly.

Step 3: Check the lookup count

Before you copy the output, check how many DNS lookups the generated record requires. A good spf builder will display this count automatically. If you’re at or above 10, you need to reduce includes — either by removing unused sources or by using direct IP addresses instead of include references.

Step 4: Copy the generated record

Copy the complete record string exactly as generated. Don’t modify it manually — SPF syntax is precise and a small formatting error can invalidate the entire record.

Step 5: Publish in your DNS

Log into your DNS management interface and add a new TXT record:

• Host/Name: @ or your domain name (varies by provider — some use @ for the domain root, others want the full domain)
• Type: TXT
• Value: the full SPF record string
• TTL: 3600 is fine

Important: You can only have one SPF record per domain. If you already have an SPF record, edit the existing record rather than adding a new one. Two SPF records on the same domain causes both to fail.

Save the record and wait for DNS propagation — usually a few hours, up to 48 in some cases.

Step 6: Verify the record is live and working

Use MXToolbox SPF Lookup or Google Admin Toolbox to check your published record. Confirm:

• The record is found at your domain
• The syntax is valid
• The lookup count is under 10
• All your intended sending sources are included

If the tool reports warnings or errors, fix them before moving on.

Step 7: Test with a real send

Send a test email to a Gmail or Outlook address and check the email headers. Look for the Authentication-Results header — it will show whether SPF passed or failed and which mechanism matched.

In Gmail: open the email → click the three dots → “Show original” → look for spf=pass.

If SPF is passing, move your qualifier from ~all to -all to enforce the policy fully. Beyond the SPF check itself, running an email reputation check on your domain provides ongoing visibility into how providers score your sends — a separate signal from SPF that affects inbox placement long after authentication is set up correctly.

What to look for in a free SPF record generator

Not every SPF generator is equally useful. Here’s what actually matters.

Lookup count display — The tool should tell you how many DNS lookups your record uses. Without this, you can’t tell if you’re approaching the 10-lookup limit.

Support for common platforms — A good spf record builder includes a list of major sending services with pre-configured include references. This prevents errors from manually typing include strings.

Validation on output — The generator should flag syntax errors before you copy the record, not leave you to discover them after publishing.

Plain text output — The output should be a clean string you can paste directly into your DNS interface without modification.

If you’re already using Reply.io for outbound, check your account settings for the specific SPF include reference you need to add — Reply.io’s documentation lists the exact string required to authorize its sending infrastructure.

Who needs an SPF record?

Best practices

• One SPF record per domain, always — Two SPF records on the same domain cause both to fail. If you need to add a new source, edit the existing record.
• Start with ~all, move to -all after testing — Softfail lets you confirm everything is working before you enforce. Moving to hardfail too early can block legitimate sends.
• Audit your SPF record when you add new sending tools — Every new platform that sends email from your domain needs to be added. Most teams add the tool without updating SPF — then wonder why emails from that tool are failing.
• Check your lookup count every time you make changes — The 10-lookup limit doesn’t announce itself. Count your lookups after every edit and remove or flatten includes that push you over.
• Remove sources you no longer use — Old includes from tools you’ve stopped using still consume lookups. Clean them out regularly.
• Don’t use +all — This authorizes every server in the world to send as your domain. It’s the opposite of what SPF is for and provides zero protection.

Full process at a glance:

Troubleshooting

SPF is failing for emails from a legitimate sending tool. That tool’s sending server isn’t included in your SPF record. Check the tool’s documentation for its required SPF include reference and add it to your record. Re-verify after publishing.

My SPF record lookup is showing “PermError” or “too many DNS lookups.” You’ve exceeded the 10-lookup limit. Audit your includes — remove unused sources, replace include: references with direct ip4: addresses where possible, or use an SPF flattening service to resolve the chain. Re-check the count after each change.

I have two SPF records showing up in DNS. Delete one. Two SPF TXT records on the same domain causes validation to fail for both. Merge the contents of both records into a single record and delete the duplicate.

SPF is passing but emails still land in spam. SPF is one factor in deliverability — not the only one. Check DKIM and DMARC setup, sender reputation, list quality, and content. SPF passing is a necessary condition for good deliverability, not a sufficient one.

I added a new email tool and now my SPF lookup count is over 10. Audit your existing includes and remove any that belong to services you’re no longer using. If that’s not enough, consider SPF flattening — resolving include chains to direct IP addresses — to reduce lookup overhead.

Conclusion

SPF is one of the foundational pieces of email authentication. It’s not complicated to set up — one record, published once, covering all your sending sources. But it does need to be done correctly: the right includes, under the 10-lookup limit, with the right enforcement qualifier, and updated every time you add a new sending tool.

An SPF record generator handles the syntax so the formatting isn’t what breaks it. What breaks SPF is usually the lookup limit — exceeded silently, invisible in normal sending behavior, only apparent when you go looking for it.

Get SPF right, pair it with DKIM and DMARC, and your domain has the authentication foundation that serious outbound email requires.

Reply.io works best on a properly authenticated domain — clean SPF, DKIM, and DMARC setup means your sequences land where they should, not in spam folders.