9 SPF Record Examples to Improve Deliverability in 2026

Do not index

Your Emails Are Going to Spam. Is Your SPF Record to Blame? Seeing carefully crafted emails land in spam isn't just frustrating. It cuts into pipeline, onboarding, reply rates, and sender reputation. Before blaming the copy or the list, the problem is often technical. A broken or misconfigured SPF record can tell receiving mail servers that the domain isn't trustworthy.

This is why SPF record examples matter. They aren't just DNS syntax. They shape how mailbox providers evaluate whether a message should reach the inbox, get filtered, or fail authentication entirely. This guide gives practical SPF record examples for common setups, explains the trade-offs behind each one, and shows what to validate before a bad record hurts deliverability.

For teams shipping product emails, sales outreach, or newsletters, a fast diagnosis matters more than raw DNS output. That's where a live tool helps. mailX by Mailwarm checks SPF, DKIM, DMARC, MX, blacklist status, SMTP, IMAP, and related DNS signals in one place, then explains what to fix in plain English. It is built for humans, developers, and AI agents that need live deliverability checks inside real workflows.

A useful companion read on the broader problem is preventing email spam issues for digital products.

Table of Contents

Quick Answer 1. Example 1 Basic SPF for a Single Mail Provider e.g. Google Workspace Record example Why this works Where it breaks 2. Example 2 SPF for Multiple Providers with Strict Enforcement Record example Why teams choose this record 3. Example 3 SPF with a Specific IP Address or Range CIDR Record example When direct IP authorization makes sense 4. Example 4 SPF for a Subdomain e.g. marketing.yourdomain.com Record example Why subdomain SPF improves control 5. Example 5 SPF for Forwarding Services e.g. Hey.com and custom aliases Record example Why forwarding breaks SPF 6. Example 6 Using the redirect modifier for managed services Record example When redirect is the right choice 7. Example 7 An Empty SPF Record to Block All Email Record example Best use case for non-sending domains 8. Example 8 SPF with the exp modifier for custom error messages Record example Why teams use it The trade-offs to understand first Practical guidance 9. Example 9 The Ultimate SPF Validation and Maintenance Checklist Ongoing checks that prevent silent failures A practical workflow with mailX 9-Point SPF Record Comparison FAQ What is an SPF record Why do SPF record examples matter for deliverability What's the difference between ~all and -all How does a team check whether an SPF record is broken Can AI agents check SPF automatically From Confusing Data to Clear Action

Quick Answer

An SPF record is a DNS TXT record that tells receiving mail servers which providers are allowed to send email for a domain.

A valid SPF record must start with v=spf1, and each fully qualified domain name can have only one SPF record. If the version tag is missing, or if multiple SPF records exist for the same domain name, receiving servers can return a permerror and SPF validation fails, as explained in this SPF syntax reference.

For inbox placement, the practical rules are simple:

Authorize every real sender: Google Workspace, Microsoft 365, SendGrid, Mailgun, forwarding providers, and any app server that sends mail.

Keep the policy clear: -all is strict. ~all is transitional.

Watch DNS complexity: SPF has a hard limit of 10 DNS lookups.

Check the rest of the stack: SPF alone doesn't solve deliverability. DKIM, DMARC, MX, blacklist status, and SMTP behavior still matter.

1. Example 1 Basic SPF for a Single Mail Provider e.g. Google Workspace

A typical early-stage setup looks like this: the company sends employee mail, support replies, and basic outbound from Google Workspace, and nowhere else. In that case, the SPF record should be short, readable, and easy to audit.

Record example

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

This record authorizes Google's sending infrastructure and ends with ~all, which marks mail from unauthorized sources as suspicious instead of issuing a hard fail. The difference between ~all and -all is explained clearly in dmarcian's SPF syntax table.

Why this works

For a single-provider domain, this is the clean starting point. It covers the actual sender, keeps lookup usage low, and avoids unnecessary complexity that later causes SPF permerrors or troubleshooting delays.

It also gives teams room to verify their mail flow before switching to a stricter policy. That matters in practice because “single provider” often turns out to mean “Google Workspace plus one forgotten app that sends invoices or form notifications.”

Where it breaks

The failure point is rarely Google. It is incomplete sender inventory.

A soft-fail record can stay in place for months because nobody wants to risk breaking legitimate mail. As noted in this discussion of common SPF record problems, teams often leave ~all in production longer than they should. That is safer operationally in the short term, but weaker for spoofing control and less disciplined from a deliverability standpoint.

There is also a strategic trade-off here. This record is simple now because it uses one include. If the business later adds a CRM, a ticketing platform, and a marketing tool, lookup count and policy drift become real risks. SPF has a hard limit of 10 DNS lookups, so the best time to keep the record clean is before it grows.

Use this example when:

One provider sends all legitimate mail: Google Workspace or Microsoft 365 handles employee and operational mail.

The sender inventory is still being confirmed: The team wants a safe starting policy while checking for hidden systems.

The domain is not ready for hard fail yet: DKIM and DMARC may still be in transition, and operations need time to verify alignment.

What to check next:

Confirm there is only one SPF record: Multiple SPF TXT records on the same domain can cause a permerror.

Verify every real sender: Check forms, billing tools, CRMs, support platforms, and any server that sends as your domain.

Run a live SPF check: Use mailX to inspect the DNS response, syntax, includes, and effective policy before you tighten enforcement.

If Google Workspace is the only sender, this example is often the right first record. Once that is verified, the next decision is whether the domain is ready to move from ~all to -all.

2. Example 2 SPF for Multiple Providers with Strict Enforcement

A common failure point appears right after a company adds its second or third mail platform. Google Workspace handles employee mail, SendGrid sends product notifications, and Mailgun runs lifecycle campaigns. SPF has to authorize the full sending stack, or strict enforcement will block legitimate mail.

Record example

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org -all

This record authorizes three providers and ends with -all. That tells receiving servers to reject mail from any source not explicitly listed.

Why teams choose this record

This pattern fits domains that already know who should be sending mail and want tighter spoofing control. The business benefit is straightforward. Fewer unauthorized sources can impersonate the domain, and that helps protect both brand trust and inbox placement.

The catch is operational discipline.

A hard fail policy only works when the sender inventory is complete and maintained. If finance uses a billing platform nobody documented, or support sends from a help desk system added two years ago, those messages can fail SPF the moment -all goes live. In practice, the problem is rarely syntax. It is missing systems, old vendors, and subdomains that were never reviewed.

Fortra reported broad growth in SPF adoption among domains with MX records in its DMARC and SPF adoption analysis. Adoption is not the same as clean execution. I see plenty of domains with technically valid SPF that still break real mail flows because nobody checked every sender before tightening policy.

Another risk sits under the surface. Each include can trigger DNS lookups, and SPF has a hard limit of 10. Three providers may be fine today. Add a CRM, a support platform, a survey tool, and a forwarding service, and the record can drift into permerror territory. At that point, a record meant to improve trust starts creating authentication failures.

Use this setup when:

Multiple approved providers send for the same domain: Employee mail, app mail, and marketing or lifecycle mail all use the root domain.

The team has verified every active sender: The inventory includes business tools, legacy systems, and any outsourced service that sends as the domain.

The domain is ready for strict enforcement: SPF, DKIM, and DMARC are being monitored closely enough that failures will be caught fast.

What to validate before publishing -all:

Count lookup pressure, not just includes: Nested includes can consume the 10-lookup limit faster than the top-level record suggests.

Check domain alignment by sender type: A provider may pass SPF for its own envelope domain while still failing DMARC alignment for yours.

Test each live mail stream: Send from Workspace, transactional systems, support tools, and marketing platforms before enforcing rejection.

Review delegated senders and forgotten tools: Old CRMs, invoicing systems, affiliate platforms, and forwarded aliases are common blind spots.

mailX is useful here because it shows the effective SPF result, follows includes, and surfaces lookup issues before a strict policy causes real message loss. That makes it easier to confirm whether this record is safe to deploy, not just valid on paper.

3. Example 3 SPF with a Specific IP Address or Range CIDR

A company sometimes sends mail from its own server. That could be an app server, a ticketing system, a private SMTP relay, or a legacy mail host that still handles notifications. In those cases, the SPF record should authorize the sending IP directly.

Record example

v=spf1 ip4:203.0.113.10 -all

Or, if a provider gives a network range:

v=spf1 ip4:203.0.113.0/24 -all

When direct IP authorization makes sense

This is often the cleanest SPF record example because it avoids extra DNS lookups from nested include chains. It can also be easier to audit. If mail should only come from one relay or one controlled network, direct authorization is precise.

The downside is maintenance. If the server IP changes and DNS isn't updated, mail can start failing SPF immediately. This is especially common after cloud migrations, failover events, or infrastructure changes handled by another team.

A safe review process includes:

Match the sending IP to the SMTP host: The authorized IP has to be the one sending mail.

Check reverse DNS and server identity: SPF is only one signal. Mailbox providers also look at infrastructure consistency.

Validate transactional paths: Password resets, invoice emails, and invite emails often use a different server than sales outreach.

Mailbox providers don't judge mail only by content. They judge whether the infrastructure looks stable, intentional, and authenticated. If a transactional message fails SPF from an app server, onboarding breaks and users stop trusting the product.

Teams running custom infrastructure should also use tools beyond TXT lookup. A proper check should include MX, PTR, SMTP connectivity, and blacklist status. mailX is useful here because it combines those checks instead of forcing operators to piece together results from separate tools.

4. Example 4 SPF for a Subdomain e.g. marketing.yourdomain.com

Separating mail streams by subdomain is one of the cleaner ways to protect reputation. A newsletter domain doesn't need to share the same identity surface as executive mail or support replies.

Record example

For marketing.yourdomain.com:

v=spf1 include:sendgrid.net -all

That record belongs on the subdomain itself, not only on the root domain.

Why subdomain SPF improves control

A common mistake is assuming the root domain SPF record automatically covers every subdomain in the way a team expects. Operationally, each sending subdomain should be treated as its own mail identity and configured intentionally.

This improves deliverability in a few ways:

Reputation separation: Marketing volume and engagement patterns don't mix with executive or transactional mail.

Cleaner troubleshooting: If one stream starts landing in spam, the team can isolate the issue faster.

Safer enforcement: A strict policy on a dedicated subdomain is easier to manage than a crowded root domain used by many teams.

Subdomain design also helps with DMARC alignment and reporting clarity. For example, a company might send newsletters from marketing.example.com, app alerts from notify.example.com, and employee mail from example.com. Each stream can have its own SPF, DKIM selector setup, and sending rules.

Before publishing, check these points:

Publish the SPF record on the actual sending subdomain: Not just the parent domain.

Use matching DKIM and return-path settings where possible: Misalignment can still cause filtering.

Review MX and DNS records for the same subdomain: Inconsistencies slow down debugging.

For teams managing multiple brands or environments, mailX is especially useful because it supports live SPF analysis across multi-domain setups and shows what each subdomain is returning.

5. Example 5 SPF for Forwarding Services e.g. Hey.com and custom aliases

Forwarding creates confusion because the visible sender and the server doing the forwarding aren't the same thing. A message can be legitimate and still fail SPF after it passes through a forwarding hop.

Record example

A forwarding-aware setup might look like this:

v=spf1 include:_spf.google.com include:forwarding-provider.example -all

The exact include depends on the forwarding service. Some alias providers document what to authorize. Others rely more heavily on DKIM surviving the forward.

Why forwarding breaks SPF

SPF checks whether the connecting server is allowed to send on behalf of the domain. In a forwarding scenario, the forwarder becomes the connecting server. If that infrastructure isn't authorized, SPF can fail even when the original sender was legitimate.

This is why forwarding should never be diagnosed with SPF alone. Teams should also check:

Whether DKIM survives forwarding: DKIM often carries the trust signal when SPF breaks during forward.

Whether DMARC still aligns: SPF failure isn't always fatal if DKIM passes and aligns.

Whether the forwarder rewrites the envelope sender: Some services mitigate SPF problems this way.

Real-world symptom patterns include alias services, founder inbox routing, and support aliases that receive on one domain and forward to another. The team sees intermittent spam placement and blames content, when the underlying issue is authentication loss during forwarding.

A practical fix is to map the forwarding path, then test the exact destination mailbox flow. mailX helps by combining SPF, DKIM, DMARC, and infrastructure checks into one report, which is much more useful than validating the TXT record in isolation.

6. Example 6 Using the redirect modifier for managed services

A common failure pattern looks like this. A company hands outbound mail to one managed provider, keeps adding include statements over time, then hits SPF lookup limits without noticing until mail starts failing authentication at some receivers. If one service controls all sending for the domain, redirect is often the cleaner fix.

Record example

v=spf1 redirect=_spf.service-provider.example

With redirect, the receiver stops evaluating the local domain's SPF policy and uses the target policy as the full answer.

When redirect is the right choice

Use redirect when a managed service owns the entire sending footprint for that domain. That usually means no on-prem relay, no app server sending alerts, no second ESP, and no one-off transactional IPs sitting outside the provider's published SPF.

That trade-off matters. include says, "also check this policy." redirect says, "this other policy is the policy." If even one legitimate sender exists outside the provider, redirect can break mail that used to pass.

redirect also helps contain SPF sprawl. The protocol allows only 10 DNS lookups during evaluation, and nested includes can burn through that limit faster than teams expect. In a large analysis of SPF deployments, researchers found many domains crossing that threshold and triggering SPF errors, according to this SPF adoption and validation analysis.

A practical rule is simple:

Use redirect when one provider manages all sending for the domain.

Use include when the domain sends through multiple authorized systems.

Avoid mixing local mechanisms with redirect unless you are certain the provider's policy accounts for every sender you need.

This is less about syntax and more about control. If the provider wants to update infrastructure without asking customers to edit DNS every time, redirect gives them that control. If your team needs exceptions, local flexibility usually matters more than centralization.

Validate it before publishing. A quick check with mailX will show whether the redirected policy resolves cleanly, how many lookups it consumes, and whether the final SPF result matches the actual mail flow. That is the difference between a tidy DNS record and a policy that still protects inbox placement.

7. Example 7 An Empty SPF Record to Block All Email

A parked domain gets registered for a campaign, never launches, and six months later someone spoofs it. That is a common gap in domain portfolios. If a domain should never send mail, say so in DNS.

Record example

v=spf1 -all

This record tells receivers that no server is allowed to send mail for the domain.

Best use case for non-sending domains

Use this on parked domains, defensive registrations, typo domains, event microsites, and any brand asset that exists only to hold a name. It is one of the simplest SPF record examples, but it solves a real security problem. Attackers look for domains with no clear sending policy because ambiguity gives them room to operate.

The value is operational, not theoretical:

It cuts spoofing opportunities: forged mail has no authorized path to pass SPF.

It gives receivers a clear signal: mail claiming to come from that domain should fail.

It keeps domain portfolios organized: each domain has a defined role instead of an undocumented default.

There is also a deliverability angle. If a dormant domain gets abused, the cleanup work often spills into the rest of the brand. Security teams investigate, support teams answer confused customers, and mailbox providers see another domain tied to suspicious traffic. A one-line SPF record will not stop every spoofing attempt, but it removes one easy opening.

The practical trade-off is simple. v=spf1 -all is safe only when the domain does not send. If a form tool, ticket system, or forgotten SaaS platform still uses that domain in the Return-Path, legitimate mail will fail SPF. That is why I always recommend an inventory first. Mark each domain as sends mail, receives mail only, or does neither, then publish SPF to match its actual use case.

Validation should be immediate. Check the live TXT record, confirm there is only one SPF record on the name, and verify that no active service still depends on the domain. A free SPF checker is useful for a quick pass, and mailX helps with the broader audit by showing live DNS and authentication status across the domains you own.

8. Example 8 SPF with the exp modifier for custom error messages

A common scenario is a strict SPF policy that works as intended, but the receiving server returns a generic failure that leaves admins guessing. The exp modifier exists for that case. It lets you publish a human-readable explanation for SPF failures on receivers that still surface it.

Record example

v=spf1 include:_spf.google.com -all exp=spf-errors.example.com

The host named in exp then publishes a TXT record with the explanation text, such as contact instructions or a short reason for the rejection.

Why teams use it

exp is about troubleshooting, not inbox placement. It does not make mail more likely to land in the inbox, and it does not strengthen a weak SPF policy. What it can do is shorten the time between a failure and the fix when an admin, customer, or partner mail system exposes the explanation string.

That makes it useful in controlled environments. I see it make sense most often for B2B senders with partner-specific routing, internal IT teams handling multiple business units, or organizations that want clearer support signals when unauthorized systems try to send mail.

The trade-offs to understand first

Support for exp is inconsistent. Some receivers ignore it completely. Others show only part of the message. If the rest of your SPF record is messy, the explanation will not help much.

There is also a maintenance cost. The exp target is another DNS record to keep live and accurate. If you forget about it during a migration, the explanation can go stale and confuse the people who are trying to diagnose a real problem.

Critically, exp does nothing to solve the failures that hurt deliverability:

a broken include chain

too many DNS lookups

multiple SPF records on one hostname

missing senders in the policy

an overly permissive rule such as +all

That is the core business point. Clearer error text may reduce support friction, but sender authorization still has to be correct or legitimate mail will fail.

Practical guidance

Use exp only after the core SPF record is stable and verified. Check the record with a free SPF checker, confirm that lookup depth stays within SPF limits, and make sure every active sender is accounted for. Then test whether the explanation is visible on the receiving systems your team deals with.

If you want the message, keep it short and operational. Include a contact path or a simple statement that the server is not authorized to send for the domain. Avoid long prose. The admins who see these failures need a fast answer, not marketing copy.

mailX is useful here for instant validation of the live DNS record and the broader authentication setup, especially when SPF, DKIM, and DMARC need to be checked together after a change.

9. Example 9 The Ultimate SPF Validation and Maintenance Checklist

A common failure pattern looks like this. SPF passes during setup, everyone signs off, and three months later a new sending tool goes live without any DNS update. The campaign underperforms, support replies disappear, or invoices stop reaching customers. SPF maintenance protects revenue because inbox placement drops fast when authorized senders and live DNS drift out of sync.

Use this checklist as an operating routine, not just a launch task.

Ongoing checks that prevent silent failures

One SPF record per hostname: Each fully qualified domain name should return exactly one SPF TXT record. Multiple SPF records produce a permerror, and receivers may treat mail as unauthenticated.

Correct version string: The record must start with v=spf1. Anything else fails before policy evaluation even starts.

Every real sender included: Review Google Workspace, Microsoft 365, SendGrid, Mailgun, HubSpot, Zendesk, app servers, ticketing tools, and any platform that can send with your domain in the Return-Path or envelope sender.

The enforcement level still fits reality: ~all is useful during rollout, but teams often leave it in place long after the sender inventory is stable. If the domain is fully mapped, decide whether -all is the safer policy.

DNS lookups stay under the SPF limit: Includes, redirects, a, mx, and exists mechanisms all count. A record can look clean in DNS and still fail during evaluation because the lookup chain is too deep.

Unused vendors are removed: Old ESPs and retired SaaS tools widen the attack surface and make troubleshooting harder.

Subdomains are checked separately: Marketing, billing, and transactional subdomains often need different SPF policies because they use different providers and carry different reputation risk.

SPF is validated with DKIM and DMARC: SPF alone is not enough to judge alignment or policy enforcement. Check all three together after any DNS or provider change.

Live DNS is verified after edits: Confirm what public resolvers are returning after propagation, not just what appears in the DNS control panel.

The trade-off is straightforward. A permissive record is easier to maintain, but it gives spoofing more room. A strict record is safer, but only if the sender inventory is accurate and someone owns the process.

A practical workflow with mailX

A useful review flow starts with the record itself, then moves outward to the rest of the mail stack:

Validate SPF syntax and logic: Confirm the record parses correctly, includes the right services, and stays within the 10-lookup limit.

Check active sender coverage: Compare the SPF policy against the actual tools used by marketing, support, finance, product, and engineering teams.

Verify DKIM signing and alignment: A sender may be authorized by SPF but still fail DMARC if DKIM is broken or misaligned.

Review DMARC policy and reporting: p=none, p=quarantine, and p=reject have different operational consequences. Make sure the policy matches your enforcement goal.

Inspect MX and general DNS health: DNS issues can create symptoms that look like authentication failures.

Check blacklist status and sender reputation: Valid SPF does not fix a poor sending reputation.

Test mail services directly: SMTP and IMAP checks help separate authentication issues from server or access problems.

Run one combined audit after changes: A single pass across SPF, DKIM, DMARC, DNS, and reputation catches the dependencies that piecemeal checks miss.

For quick spot checks, a simple external validator still helps, such as this free SPF checker. For operational work, mailX is useful because it checks live SPF, DKIM, DMARC, BIMI, MX, TXT, CNAME, PTR, blacklist status, SMTP, IMAP, and domain configuration in one report, then points to the exact issue to fix.

That is the essential value of an SPF checklist. It turns SPF from a static DNS record into a repeatable control for inbox placement.

9-Point SPF Record Comparison

Example	Implementation complexity	Resource requirements	Expected outcomes	Ideal use cases	Key advantages
Example 1: Basic SPF for a Single Mail Provider (Google Workspace)	Low	Single DNS TXT edit; one include; basic validation	Basic SPF protection with soft-fail (~all)	Small teams or startups using one cloud mail provider	Very easy to set up; cautious rollout with softfail
Example 2: SPF for Multiple Providers with Strict Enforcement	Medium–High	Multiple includes; monitor DNS lookup count (≤10); validation tools	Strong protection; unauthorized mail rejected (-all)	Businesses using cloud mail + transactional + marketing services	High anti-spoofing effectiveness when correctly maintained
Example 3: SPF with a Specific IP Address or Range (CIDR)	Medium	Know public static IP(s); DNS TXT update; reverse DNS checks	Precise authorization with efficient mechanisms (ip4/ip6)	On‑prem mail servers or apps sending from static IPs	Accurate control; no extra DNS lookups for ip mechanisms
Example 4: SPF for a Subdomain (marketing.yourdomain.com)	Low–Medium	Separate DNS entry for subdomain; include only needed services	Isolates reputation; subdomain-specific enforcement	Marketing or transactional streams using subdomains	Contains deliverability issues to a subdomain; clearer policies
Example 5: SPF for Forwarding Services (Hey.com, aliases)	Medium	Add forwarding service include; test forwarded messages	Reduces SPF failures caused by forwarding (not foolproof)	Users of email forwarding or alias providers	Improves deliverability when forwarding is used; integrates forwarder auth
Example 6: Using the `redirect` Modifier for Managed Services	Low	Single DNS TXT pointing to provider; rely on third party	Delegated policy; simplified record with single lookup	Domains fully managed by one external provider	Minimal maintenance; single-source policy management
Example 7: An Empty SPF Record to Block All Email	Very Low	Single DNS TXT with "-all"	Rejects all mail from the domain; blocks spoofing	Parked domains or domains that never send email	Strong, simple anti-spoofing for non‑sending domains
Example 8: SPF with the `exp` Modifier for Custom Error Messages	High	Main SPF TXT + separate explanation TXT subdomain; testing	Provides diagnostic message on SPF failure (limited support)	Large orgs or providers wanting automated diagnostics	Useful server-to-server feedback for administrators
Example 9: The Ultimate SPF Validation & Maintenance Checklist	Ongoing / Medium	Regular audits and monitoring tools (SPF checker, lookup counts)	Maintains valid SPF, prevents regressions and deliverability loss	Any team responsible for email infrastructure	Proactive maintenance; reduces future authentication failures

FAQ

What is an SPF record

An SPF record is a DNS TXT record that tells receiving mail servers which providers and servers are allowed to send email for a domain.

Why do SPF record examples matter for deliverability

They show how to authorize real sending infrastructure correctly. If SPF doesn't match actual senders, mailbox providers can treat mail as suspicious, which can hurt inbox placement and domain reputation.

What's the difference between `~all` and `-all`

~all is soft fail. Unauthorized mail is usually accepted but marked suspicious. -all is hard fail. Unauthorized mail is meant to be rejected.

How does a team check whether an SPF record is broken

The team should verify that there is only one SPF record, confirm that it starts with v=spf1, review all authorized senders, and test the record live alongside DKIM and DMARC.

Can AI agents check SPF automatically

Yes. AI agents can validate SPF and related deliverability signals, but they shouldn't send blindly. They need live tools that can inspect authentication, blacklist status, DNS, and infrastructure before campaigns go out.

From Confusing Data to Clear Action

Fixing an SPF record isn't about memorizing syntax. It is about sending a clear signal of trust to mailbox providers like Google and Microsoft. A correct record tells receivers which infrastructure is legitimate, but that is only one part of the deliverability picture. DKIM, DMARC, MX records, blacklist status, SMTP behavior, and domain reputation still shape whether mail reaches the inbox.

That is why SPF record examples should be used as playbooks, not copy-paste shortcuts. A basic Google Workspace record can work well for a small team. A strict multi-provider record can tighten control for a larger operation. A direct IP authorization can make sense for app servers. A subdomain policy can isolate reputation. A redirect policy can simplify managed infrastructure. A v=spf1 -all record can protect parked domains. Each example solves a different operational problem.

What hurts teams most isn't lack of data. It is unclear data. A domain can have a syntactically valid SPF record and still fail in production because the wrong sender is missing, the include chain is too deep, the subdomain wasn't configured, or forwarding broke alignment. That is where a combined diagnostic workflow matters more than a standalone TXT lookup.

mailX fits that workflow well because it isn't just a DNS checker. It is a free deliverability diagnostic layer for humans, developers, and AI agents. It runs live checks across SPF, DKIM, DMARC, BIMI, MX, blacklist status, DNS records, SMTP and IMAP connectivity, and domain configuration, while also explaining what is broken, why it matters for inbox placement, and what to fix next.

That matters for modern teams because email operations are no longer handled by one admin editing DNS a few times a year. Founders launch outbound campaigns. Marketers add tools. Developers wire up transactional flows. Agencies manage multiple domains. AI agents are starting to write, send, monitor, and optimize emails. None of those workflows should run blind. They need live deliverability checks built into the process.

The fastest way to stop guessing is to run a live audit. Check the domain, confirm which senders are authorized, inspect authentication alignment, and fix the issues that are dragging messages into spam. That gives emails a better chance of reaching the inbox and protects sender reputation before small DNS mistakes turn into larger business problems.

Run a free audit with mailX to check SPF, DKIM, DMARC, blacklist status, and email infrastructure in one place. It gives instant results, plain-English explanations, and exact remediation steps, with no signup and no stored data.

9 SPF Record Examples to Improve Deliverability in 2026

Quick Answer

1. Example 1 Basic SPF for a Single Mail Provider e.g. Google Workspace

Record example

Why this works

Where it breaks

2. Example 2 SPF for Multiple Providers with Strict Enforcement

Record example

Why teams choose this record

3. Example 3 SPF with a Specific IP Address or Range CIDR

Record example

When direct IP authorization makes sense

4. Example 4 SPF for a Subdomain e.g. marketing.yourdomain.com

Record example

Why subdomain SPF improves control

5. Example 5 SPF for Forwarding Services e.g. Hey.com and custom aliases

Record example

Why forwarding breaks SPF

6. Example 6 Using the redirect modifier for managed services

Record example

When redirect is the right choice

7. Example 7 An Empty SPF Record to Block All Email

Record example

Best use case for non-sending domains

8. Example 8 SPF with the exp modifier for custom error messages

Record example

Why teams use it

The trade-offs to understand first

Practical guidance

9. Example 9 The Ultimate SPF Validation and Maintenance Checklist

Ongoing checks that prevent silent failures

A practical workflow with mailX

9-Point SPF Record Comparison

FAQ

What is an SPF record

Why do SPF record examples matter for deliverability

What's the difference between ~all and -all

How does a team check whether an SPF record is broken

Can AI agents check SPF automatically

From Confusing Data to Clear Action

Most senders lose 30–70% of their emails to spam without knowing it.

Check if your emails are landing in spam

What's the difference between `~all` and `-all`