Create SPF Record Without Hitting the 10-Lookup Limit

If you need to create SPF record settings for a domain, the goal is simple: authorize the right senders without building a DNS mess that breaks six months later. Most failures start the same way. One vendor gets added. Then another. Then Microsoft throws a 550 5.7.515, Google throws a 550 5.7.26, and now you’re digging through TXT records at 11 p.m.

That’s the problem. SPF looks easy until it isn’t. A root-domain record turns into a dumping ground, recursive includes pile up, and one extra lookup tips the whole thing into PermError. If you run a company domain, client stack, or multi-brand setup, that’s not a minor issue. It’s a hard mail failure. If you want the bigger picture on domain setup, read business email for small business first.

This guide gives you the pattern that holds up: keep corporate mail on the root domain, isolate bulk and app mail on subdomains, and treat lookup budget like a finite resource. That’s how you create SPF record entries once without rewriting them every quarter.

Why Most SPF Records Break

SPF breaks because receivers only allow a limited number of DNS lookups during evaluation. When you create SPF record values by stacking too many includes on one domain, the check can exceed the limit, return PermError, and get mail rejected even if your syntax looks fine at a glance.

RFC 7208 is blunt here. The terms that trigger DNS queries include include, a, mx, ptr, exists, and redirect. Receivers must cap those lookups at 10. Go past that and the result is permanent error, not a warning. The same RFC also says multiple SPF records on one domain cause PermError.

That’s why the usual advice fails. Generic guides tell you to create SPF record text by stuffing every sender into one TXT value on @. That feels tidy. It isn’t. It turns your root domain into shared infrastructure for newsletters, support systems, app alerts, cold outreach tools, and human mailboxes. One vendor bloats its include chain and your whole domain pays for it.

Bad pattern: one root SPF record trying to authorize every tool your company has ever touched.

Google’s sender guidance also pushes the same direction operationally: authenticate properly and keep alignment clean, especially for bulk mail. SPF is only part of the picture, but broken SPF is often the first obvious failure.

The Real Constraint: The 10-Lookup Budget

The hard rule is this: when you create SPF record syntax, you are spending from a fixed lookup budget of 10. That budget is recursive. If one include expands into three more terms that trigger lookups, those count too. Your DNS provider doesn’t save you from bad SPF math.

What counts toward the budget:

• include
• a
• mx
• ptr (don’t use it)
• exists
• redirect

What does not count toward the budget:

• ip4
• ip6
• all

The void-lookup trap matters too. RFC 7208 says receivers should limit void lookups to two. A typo in an include target can burn part of that allowance. Two bad references can turn a normal SPF check into another PermError.

If you need to create SPF record values for a domain that sends through four or five vendors, you are already close to trouble. Not because SPF is fragile. Because your design is.

Create SPF Record With the Split-Stack Pattern

The safest way to create SPF record settings is to separate human mail from bulk or app mail. Put your primary mailbox provider on the root domain. Move marketing, support platforms, and app senders to subdomains. That gives each stream its own SPF budget and stops one vendor from breaking everything else.

This is the pattern:

1. Root domain @ for human-to-human mail only.
2. Subdomains for newsletters, support, transactional alerts, and other specialized senders.
3. One SPF record per hostname. No duplicates. No leftovers.

Example root-domain record for TrekMail managed sending:

v=spf1 include:spf.trekmail.net -all

That is clean. One include. Clear policy. Easy to audit.

Example marketing subdomain:

v=spf1 include:servers.mcsv.net include:hubspot.com -all

Now Mailchimp and HubSpot burn lookup budget on marketing.example.com, not on your root corporate identity. If they expand their infrastructure later, your staff mailboxes at example.com keep working.

This is also where TrekMail fits cleanly. TrekMail’s domain setup docs show the base SPF include as include:spf.trekmail.net, and its DNS checker flags conflicts before you chase ghosts in production. If you’re still adding mailboxes and DNS, see Adding a Domain to TrekMail and Checking DNS Status.

Step-by-Step: How to Create SPF Record Values Without Guessing

To create SPF record values that stay maintainable, inventory every sender first, assign each one to the right hostname, and only then build the TXT record. Don’t start in DNS. Start with sender ownership. That stops random includes from piling up on the root domain.

Use this workflow:

1. List every service that sends mail as your domain.
2. Mark each sender as corporate, transactional, support, or marketing.
3. Decide which hostname each sender should use.
4. Use the smallest valid SPF policy for that hostname.
5. Publish one TXT record per hostname.

Then build the actual record.

TrekMail managed SMTP pattern:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

TrekMail plus BYO SMTP pattern on the Nano plan or hybrid setups:

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

If you’re using TrekMail on the Nano plan, outbound mail requires your own SMTP provider. TrekMail’s client settings docs make that explicit, and the BYO model is part of the product by design. If you want the sending side handled for you, paid plans start at $3.50/month and include managed SMTP. The Nano plan is always free. Paid plans also have a 14-day free trial, and that trial requires a credit card. For setup details, see custom SMTP (BYO) and managed TrekMail SMTP.

Publish and Verify the Record

After you create SPF record text, publish it as a TXT record and verify what public DNS actually returns. Don’t trust a registrar UI, cached dashboard state, or a green badge inside one vendor tool. Query the domain directly and check for one valid SPF record only.

Mac or Linux:

dig txt example.com +short

Windows:

nslookup -type=txt example.com

You want to see one SPF value that starts with v=spf1. Not two. Not one current record plus one forgotten record from a migration three years ago.

Quick checks:

• Starts with v=spf1
• Ends with -all once you’re done testing
• Contains only the senders you really use
• Exists once per hostname, not multiple times

If you’re moving off another provider, this is where migrations go sideways. Old MX and SPF records often linger together. TrekMail’s DNS docs call this out directly. If you’re doing a broader platform move, these guides help: how to create email with domain and multi domain email hosting.

Common SPF Errors and the Fast Fix

Most SPF failures come down to four things: too many lookups, multiple SPF records, wrong sending hostnames, or typos in includes. When you create SPF record entries with a clear sender map, these become easy to spot. When you improvise, troubleshooting gets expensive fast.

Two practical rules save a lot of pain:

1. Use ip4 for any static sender you fully control. It costs zero lookups.
2. Never let a marketing platform send from the same hostname as executive mail unless you have a very good reason.

Google’s sender documentation is useful here because it frames the real target correctly: authentication plus alignment, not SPF in isolation. SPF can pass and mail can still fail policy if the visible From domain doesn’t line up the way receivers expect. Read Google’s email sender guidelines FAQ if you’re troubleshooting bulk delivery.

When TrekMail Makes This Easier

TrekMail helps when you want to create SPF record setups that stay simple across many domains. The core advantage is operational: one clean include for TrekMail, pooled storage, no per-user billing, built-in IMAP migration, and the choice between BYO SMTP or managed SMTP depending on plan and sending model.

For solo founders, the win is simplicity. You can keep root mail clean, use TrekMail for mailbox hosting, and avoid paying per seat. For teams, it’s easier onboarding and fewer DNS mistakes. For agencies and MSPs, it’s a standard pattern you can reuse across dozens or hundreds of domains without rebuilding mail from scratch each time.

If the old way is “every client gets a different fragile SPF stack,” the new way is “one repeatable architecture, one dashboard, and one known-good root include.” That’s a better operating model. Not just a better TXT string.

If you want to test it without committing, the Nano plan gives you 10 domains, 5GB pooled storage, and BYO SMTP with no card required. If you need managed sending, higher limits, and less DNS babysitting, TrekMail’s paid plans start at $3.50/month, with a 14-day free trial that requires a credit card. See TrekMail pricing for the current plan breakdown.

Conclusion: Create SPF Record Once, Then Stop Touching It

To create SPF record settings that last, stop thinking in terms of one giant allowlist on the root domain. Think in terms of architecture. Root for human mail. Subdomains for specialized senders. Minimal includes. Explicit -all. Direct verification after publish.

That approach keeps you under lookup limits, reduces surprise breakage, and makes future vendor changes boring. That’s the goal. If you’re rebuilding your mail stack anyway, start at TrekMail and use a model that doesn’t punish growth.