SPF Record for Email: Exact Setup for Business Domains

Your email bounced. Not filtered to spam — rejected outright. The server returned 550 5.7.26 or 550 5.7.515, and the message never moved. The reason: your domain is missing a valid SPF record for email, or the one you have is structurally broken.

Since February 2024, Google and Yahoo enforce mandatory sender authentication with no grace period. If your SPF record for email is wrong, your messages hit the gateway and stop. That applies to every business email domain — yours included.

Google: 550 5.7.26 — Unauthenticated email is not accepted

Microsoft: 550 5.7.515 — Sender identity not authenticated

This guide skips the background. You get the exact record for your setup, the hidden traps that make correct-looking configurations fail silently, and the one test that proves everything is actually working. SPF is one piece of a three-part authentication stack — for how it fits with DKIM and DMARC, see the security baseline for business email.

What Is an SPF Record for Email?

An SPF record for email is a DNS TXT entry published on your domain that lists which mail servers are authorized to send on your behalf. When a message arrives at Gmail or Outlook, the receiving server queries your DNS, checks the sending IP against your approved list, and either passes or rejects. Match: pass. No match: fail.

SPF evaluates at the SMTP envelope level — against the MAIL FROM domain, not the visible "From" address in your recipient's inbox. The record lives as a TXT entry at the root of your domain (@). If you're working out how all the DNS pieces fit together, setting up email on your domain walks through the full process from scratch.

The One-Record Rule

RFC 7208 — the SPF specification — mandates exactly one TXT record starting with v=spf1 per domain. If a receiving server finds two SPF records on the same domain, it returns a PermError and authentication fails completely for every outbound message — not a spam score penalty, complete authentication failure, every send, until you fix it.

This is the most common critical failure when adding a new provider to a domain that already has Google Workspace or another host. Someone adds a second record instead of editing the existing one.

Check what's on your domain before touching anything:

dig +short txt yourdomain.com

Count the lines starting with v=spf1. If there are two, you already have a PermError. Fix that first — nothing else matters until it's resolved.

Wrong — two records, guaranteed PermError on every outbound message:

v=spf1 include:_spf.google.com -all
v=spf1 include:spf.trekmail.net -all

Right — merged into a single SPF record for email:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Your SPF Record for Email: The Minimum Viable Setup

The exact content of your SPF record for email depends on which servers actually transmit your mail. Authorize only what you use. Every extra include: burns lookup budget and pulls in IP ranges you don't control.

Scenario A: TrekMail Managed SMTP (Starter and Agency Plans)

If you're on a paid TrekMail plan with managed delivery, one line covers your domain:

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

Scenario B: TrekMail Free Plan (BYO SMTP)

The Nano plan lets you connect your own SMTP provider — Amazon SES, SendGrid, Mailgun. Authorize their IPs, not TrekMail's:

v=spf1 include:amazonses.com -all

Replace include:amazonses.com with whatever your provider specifies in their documentation. Don't authorize IP ranges you're not using.

Scenario C: Hybrid — TrekMail + Google Workspace

Migrating from Google, or running split delivery during transition? Merge both into one record:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

Record Components

Don't use ~all (Soft Fail) on a production domain. It tells receiving servers "this might be unauthorized" — which still delivers the message. Use -all on production. Only use ~all temporarily when debugging a brand-new setup.

The 10-Lookup Limit

The SPF specification (RFC 7208) caps DNS lookups at 10 per evaluation. Every include:, a, mx, and redirect mechanism counts — including any nested lookups inside the records you include. ip4: and ip6: don't count. Exceed 10, and the receiving server returns a PermError on every message.

This is the silent killer. Your SPF record for email passes every syntax validator because the syntax is fine. But when a receiving server walks the chain — your include references their include, which references another — and the total exceeds 10, authentication breaks without warning.

What counts toward the limit:

• include: (and any nested includes inside it)
• a, mx, redirect

What doesn't count:

• ip4: and ip6: — direct IP entries bypass the lookup chain
• all

Check your count before publishing:

dig +short txt yourdomain.com

If you have a long chain of nested includes, flatten the record by replacing include: with direct ip4: entries, or segment your sending across subdomains to split the lookup budget.

Validating Your SPF Record for Email

Don't trust green checkmarks in a DNS dashboard. They test syntax, not delivery. Test your SPF record for email against live SMTP transmission — because that's exactly what Gmail does when it decides whether to accept your message.

1. Send an email from your domain to a Gmail account you control.
2. Open the message in Gmail.
3. Click the three-dot menu → Show original.
4. Search for Authentication-Results.

What a passing result looks like:

spf=pass (google.com: domain of team@yourdomain.com designates 192.0.2.1 as permitted sender)

A permerror means something structurally wrong in your SPF record for email — not a sending IP problem. Fix the structure (duplicate records, lookup count, syntax) before you touch anything else.

Common SPF Mistakes

Most SPF failures come from five mistakes. Every one of them is fixable in under 10 minutes once you know what you're looking at.

The typo mistake is particularly painful because most validators won't catch it — they check syntax, not whether the referenced domain resolves to valid IPs. Always verify against your provider's documentation for the exact include string they require.

Managing Your SPF Record for Email Across Multiple Domains

Managing an SPF record for email on one domain is a 10-minute task. Managing it across 50 client domains is an ongoing liability. Every time a client adds a new marketing tool, their authentication configuration might silently break — and you might not find out until they email you asking why their messages are bouncing.

For agencies and MSPs, the answer is standardization. TrekMail's multi-domain dashboard and built-in SPF/DKIM/DMARC wizard let you apply a consistent configuration across all your client domains. On paid plans starting at $3.50/mo, TrekMail manages SMTP delivery so you're not debugging IP reputation per domain. On the Nano plan, you bring your own SMTP provider and retain full IP reputation control — useful if you have pre-warmed SES or Mailgun accounts with high sending limits.

Instead of maintaining separate SPF configurations with different provider combinations on every client domain, move clients to TrekMail and apply one template. One configuration. Every domain. For more on structuring client email at scale, see client email management for agencies. If you're building a new domain email setup from scratch, creating email with your domain covers the full setup process.

SPF Record for Email: Pre-Publish Checklist

Before you publish your SPF record for email, run through this list in order:

1. Check for existing records: dig +short txt yourdomain.com — one v=spf1 line only.
2. Identify every service that sends email from your domain — transactional, marketing, support tools.
3. Write one record that covers all of them. Merge, don't stack.
4. Use -all, not ~all or +all.
5. Count your DNS lookups — stay under 10.
6. Publish as a TXT entry at @ in your DNS provider.
7. Send a test email to Gmail and check Show original for spf=pass.

Google's Email Sender Guidelines require SPF, DKIM, and DMARC together. Getting your SPF record for email right is the first step. DKIM and DMARC complete the stack — once all three pass, your messages stay in the inbox instead of bouncing at the gateway.

Get your SPF record for email right once and you won't touch it again until you add a new sending provider. Do it wrong, and you're debugging bounce logs while your domain's business email is down. Try TrekMail free — the Nano plan needs no credit card. Paid plans start at $3.50/mo with a 14-day free trial.