SPF Records Explained: Syntax, Examples & Setup (2026)

An SPF record is the DNS entry that tells the world’s mail servers which systems are allowed to send email using your domain. It is the first of the three email-authentication standards — alongside DKIM and DMARC — and since 2024 it is no longer optional: Google, Yahoo and Microsoft now require bulk senders to publish one. This guide explains exactly what an SPF record is, how the SPF record syntax works, how to create an SPF record correctly, the pitfalls that quietly break it, and the best practices we recommend after years of hands-on deliverability work.

What is an SPF record?

SPF stands for Sender Policy Framework. An SPF record is a single DNS TXT record, published on your domain, that lists the IP addresses and services authorized to send mail on your behalf. When a receiving server gets a message claiming to come from your domain, it looks up your SPF record and checks whether the connecting server is on the list. If it is, the message passes SPF; if not, it fails. The standard is defined in RFC 7208, which replaced the older RFC 4408.

One subtlety matters more than any other: SPF authenticates the envelope sender (the SMTP MAIL FROM, also called the Return-Path) — not the From: address your recipient actually sees. That is why SPF alone cannot stop a scammer from putting your brand in the visible From line; binding authentication to the visible sender is DMARC’s job. SPF is a necessary foundation, not a complete solution.

How an SPF record works

1. You publish an SPF policy as a DNS TXT record on your domain.
2. A sending server connects and issues MAIL FROM:<you@yourdomain.com>.
3. The receiver extracts the domain from MAIL FROM and looks up its SPF record.
4. It evaluates each mechanism left to right against the connecting IP address. The first match wins.
5. The matching qualifier decides the result: pass, fail, softfail, or neutral.

Because the check is tied to the connecting IP, SPF breaks when mail is forwarded: the forwarding server’s IP is not in your record, so the message fails SPF at the final destination. This is a known limitation, and it is exactly why DKIM (which survives forwarding) and DMARC (which passes on either SPF or DKIM) exist.

SPF record syntax

Every SPF record starts with v=spf1 and ends with an all mechanism that sets the default for anything not matched earlier. Between them you list the authorized sources. Here is the SPF record syntax broken down by component.

The four qualifiers — + (pass), - (fail), ~ (softfail) and ? (neutral) — can prefix any mechanism, but you will see them most often on all. The deprecated ptr mechanism should not be used (RFC 7208 advises against it), and +all authorizes the entire internet to spoof you, so it must never appear in a real SPF record.

SPF record example

Here is a realistic SPF record example for a company that sends from its own mail server, Google Workspace, and an email service provider:

v=spf1 ip4:198.51.100.25 include:_spf.google.com include:sendgrid.net -all

Reading this SPF record example left to right: authorize the server at 198.51.100.25, then everything in Google’s SPF, then everything in SendGrid’s SPF, and -all means reject anything else. A softfail version would simply end in ~all. Notice there is exactly one record and one v=spf1 — that is mandatory.

How to create an SPF record

1. Inventory every sender. List every system that sends mail as your domain: your mail host, marketing platform, CRM, helpdesk, invoicing tool, and transactional service.
2. Collect each sender’s SPF include or IPs. Reputable providers publish an include: value (e.g. include:_spf.google.com) in their documentation.
3. Build one record. Combine them all into a single v=spf1 … all string. You may only have one SPF record per domain.
4. Choose your default. Use -all (hardfail) or ~all (softfail) — see best practices below.
5. Publish it as a TXT record at your domain’s root, then verify it.

The 10-lookup limit and other SPF record pitfalls

The single most common way an SPF record breaks is the 10-DNS-lookup limit. RFC 7208 allows at most ten mechanisms that trigger a DNS query — include, a, mx, ptr, exists and the redirect modifier. Exceed ten and the record returns a permerror, which fails SPF for all your mail. Chaining several ESP includes is the usual culprit. Note that ip4, ip6 and all do not count, which is why “SPF flattening” (resolving includes down to raw IP ranges) is a common fix.

• Two SPF records. Publishing more than one v=spf1 record is invalid and causes a permerror — merge them into one.
• Forgetting a sender. If a legitimate service is missing and you use -all, its mail gets rejected.
• Using +all or ptr. The first authorizes everyone; the second is deprecated and unreliable.
• Forwarding failures. SPF cannot survive forwarding — rely on DKIM and DMARC to keep forwarded mail authenticated.

SPF flattening and third-party senders

Most organisations send through more services than they realise: a mail host, a marketing platform, a CRM, a helpdesk, an invoicing system, and one or two transactional providers. Each one needs to be authorised, and each include: you add consumes part of your ten-lookup budget — along with every lookup that their record performs, because includes are evaluated recursively. A single ESP include can quietly cost three or four lookups on its own, which is how a record with only four or five visible includes still trips the limit and returns a permerror.

The standard remedy is SPF flattening: you resolve every include down to the raw ip4 and ip6 ranges it ultimately authorises, then publish those ranges directly. Because ip4 and ip6 do not count toward the ten-lookup limit, a flattened record can authorise dozens of servers without ever approaching it. The trade-off is maintenance: when a provider changes its sending IPs, a flattened record does not update automatically, so you must either re-flatten on a schedule or use a managed service that keeps the ranges current. For most senders, the cleaner long-term fix is simply to remove services you no longer use and consolidate sending onto fewer platforms.

Forwarding deserves special mention. When a recipient auto-forwards your message, the forwarding server connects from an IP that is not in your SPF record, so the message fails SPF at its final destination even though you did nothing wrong. Some providers implement the Sender Rewriting Scheme (SRS) to rewrite the Return-Path and keep SPF intact, but you cannot rely on every forwarder doing so. This is the practical reason SPF is never enough on its own: a valid DKIM signature survives forwarding, and DMARC passes whenever either SPF or DKIM is aligned, so the three standards together cover the gaps each one leaves alone.

SPF record best practices

• Keep exactly one SPF record and stay well under the 10-lookup limit; audit your includes periodically.
• Choose your all deliberately. Historically -all was the strict recommendation. With a strong DMARC policy in place, many practitioners now prefer ~all, because some receivers reject on SPF hardfail before DKIM can rescue forwarded mail. Either is defensible — the key is pairing SPF with enforced DMARC.
• Never publish +all and remove any ptr mechanism.
• Treat SPF as one leg of a tripod. Add DKIM and DMARC — SPF alone protects neither forwarded mail nor your visible From address. See our email authentication hub for the full setup order.

That last point matters more than the raw adoption numbers suggest. In our 2026 study of 10,000 top domains, SPF was the most-adopted standard at 84.5% — yet 46.4% of those records still ended in the lenient ~all, which asks receivers to accept unauthorized mail rather than reject it. A published SPF record, on its own, is not the same as protection: it only does real work when it is paired with an enforced DMARC policy.

How to check an SPF record

After you publish or change anything, verify it before you trust it. You can query the record directly from a terminal with dig TXT yourdomain.com (or nslookup -type=txt yourdomain.com on Windows) and confirm that exactly one v=spf1 string comes back. The harder thing to verify by eye is the ten-lookup count, because it depends on what every included record resolves to — that is where a checker that expands the full include tree is worth using. Our free SPF lookup tool does both: it shows the published record and counts the DNS lookups it triggers, so you can catch a permerror before your mail starts failing. Re-check after any change to your sending stack — adding a new marketing platform or helpdesk is the most common moment an SPF record silently breaks.

Related reading

• DKIM records guide
• DMARC records guide
• BIMI records guide
• MTA-STS guide
• TLS-RPT guide

SPF record FAQ

How many SPF records can I have?

Exactly one. A domain must publish a single v=spf1 TXT record. Two or more cause a permerror that breaks SPF entirely, so if you add a new sender you must merge it into your existing record rather than create a second one.

What is the SPF 10-lookup limit?

SPF permits a maximum of ten DNS-lookup-causing mechanisms (include, a, mx, ptr, exists, redirect). Going over ten returns a permerror that fails SPF for all your mail. The ip4, ip6 and all terms do not count toward the limit.

Should I use -all or ~all?

-all (hardfail) tells receivers to reject unauthorized senders; ~all (softfail) tells them to accept but treat as suspicious. With an enforced DMARC policy, ~all often gives equivalent protection while avoiding forwarding-related rejections. It is a trade-off, not a hard rule.

Does an SPF record stop email spoofing on its own?

No. SPF only checks the envelope sender, not the visible From: address, so a spoofer can still forge the name your recipient sees. You need DMARC (built on SPF and DKIM) to protect the visible From address.

Is an SPF record required in 2026?

For bulk senders, yes. Since February 2024, Google and Yahoo require senders of roughly 5,000+ messages a day to personal accounts to publish SPF, DKIM and DMARC, and Microsoft has rolled out the same requirement for Outlook consumer mailboxes. Even below that threshold, SPF is strongly recommended.

Why does my SPF record pass but DMARC still fails?

Because of alignment. DMARC requires the SPF-authenticated domain (the Return-Path) to match your visible From: domain. If your ESP uses its own Return-Path, SPF passes for their domain but is not aligned with yours, so DMARC fails. Aligning the Return-Path — usually by setting a custom bounce domain such as a CNAME on a subdomain of yours — or relying on aligned DKIM fixes it. Our DMARC guide walks through this exact scenario step by step.