What Is An SPF Record And How Does It Protect Your Email Domain?

An SPF (Sender Policy Framework) record is a DNS TXT record at the domain apex that declares which IP addresses and servers are authorized to send email on behalf of that domain. When a message arrives at a receiving mail server, the server looks up the SPF record in DNS, parses the authorized list, and compares the connecting IP against it. If the IP is listed, SPF passes. If not, SPF fails and the message is rejected, flagged, or quarantined depending on the sender’s policy and the receiver’s DMARC handling.

A minimal SPF record looks like this:

example.com. IN TXT "v=spf1 include:_spf.google.com ip4:203.0.113.10 -all"

SPF is defined in RFC 7208 and is one of the three core email authentication standards alongside DKIM (RFC 6376) and DMARC (RFC 7489). Without SPF, any attacker can forge email from your domain and it will reach recipients as if it were legitimate.

This guide covers what goes inside an SPF record, how receiving servers evaluate it, the RFC 7208 limits (10 DNS lookups, 2 void lookups, 255 characters per string), and how to verify a published record with a free SPF checker.

What Goes Inside an SPF Record

Think of an SPF record as a public guest list for your domain’s outbound mail. It lives in your DNS TXT record set, and it answers one question for every receiving server that asks: “Is the machine trying to send this message actually allowed to send for this domain?” If the answer is no, the message is treated as a likely forgery - which is exactly the point, because email spoofing works by putting your domain in the “From” address of mail you never sent.

The list itself is built from three kinds of tokens:

• A version tag (v=spf1) that marks the string as an SPF record. It is mandatory and always comes first.
• One or more mechanisms that each name a set of permitted senders - ip4 and ip6 for raw IP addresses or ranges, a and mx for the hosts behind your A/AAAA and MX records, include to pull in another provider’s list, and exists/ptr for conditional and reverse-DNS checks.
• A closing qualifier on the all mechanism that sets the default verdict for everyone not on the list.

The order of mechanisms matters: receivers evaluate them left to right and stop at the first match, so the final all is what catches every sender you did not explicitly authorize. Because each lookup-triggering mechanism has a cost, RFC 7208 caps a record at 10 DNS lookups per evaluation - cross that line and the whole record is thrown out, no matter how correct the rest of it is.

How Receivers Evaluate an SPF Record

The check happens mid-conversation, during the SMTP handshake, before the receiving server has even accepted the message body. The moment a sending server announces which domain it is sending for (the MAIL FROM / Return-Path domain), the receiver looks up that domain’s SPF TXT record and walks the mechanisms in order, comparing the connecting IP address against each one until it finds a match.

The match produces one of a handful of results, and that result - not the record’s mere existence - is what downstream policy acts on. A pass lets the message continue and feeds into SPF alignment, the condition DMARC needs to confirm the visible “From” domain really owns the mail. A fail tells the receiver the IP is not authorized; what happens next depends on your qualifier and the receiver’s DMARC handling - rejection, quarantine, or a spam-folder delivery.

Whatever the verdict, the receiver stamps it into the message’s Authentication-Results header, so you can reconstruct exactly why a message passed or failed after the fact. That is what a free SPF checker reads back for you - the live record, the expanded mechanism list, and every IP address your domain currently trusts - without a manual dig session.

Why SPF Matters for Authentication and Deliverability

SPF rarely works alone. It is the first of three standards that together make up modern email authentication: SPF vouches for the sending server, DKIM adds a cryptographic signature proving the message was not altered in transit, and DMARC ties the two to the visible “From” domain and tells receivers what to do when they disagree. Reaching full DMARC compliance requires either SPF or DKIM to pass and align with your domain - so a correct SPF record is load-bearing for the whole stack, not an optional extra.

The payoff shows up in two places. First, security: a published record with a strict policy closes the easiest spoofing path attackers use to launch phishing and business-email-compromise campaigns from your name, the kind that lead to data breaches and wire fraud. Second, deliverability: mailbox providers treat a passing SPF result as a trust signal, so a clean record is part of why your legitimate mail reaches the inbox instead of the spam folder. Since February 2024, Gmail and Yahoo have required SPF for bulk senders outright - without it, your mail can be throttled or rejected before a human ever sees it.

How to Set Up an SPF Record for Your Domain

SPF setup is a DNS task, not a mail-server task: you build one text string and publish it in your domain’s DNS zone through whatever interface your registrar or DNS host gives you. The work is in getting the string right before you publish it.

Step 1: Identify Authorized Mail Servers

Start by listing every source that sends mail as your domain. Most organizations are surprised by how long this list gets: a primary platform like Microsoft 365 (Exchange Online) or Google Workspace, plus transactional and marketing senders such as Amazon SES, a CRM, a help-desk tool, and an invoicing system. Anything you leave off will fail SPF and risk the spam folder, so audit your actual sending before you write a single mechanism.

Step 2: Construct the SPF Record with Proper SPF Syntax

Using SPF mechanisms and qualifiers, build the SPF record string. An SPF record generator tool can assemble this string for you and validate it as you go. For example:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:spf.protection.outlook.com -all

• `v=spf1` indicates the SPF version.

• `ip4:192.0.2.0/24` specifies authorized IP address ranges.

• `include:` directives incorporate SPF policies from external services like Google Workspace or Microsoft.

• `-all` is the hardfail qualifier: every sender not matched above is unauthorized and should be rejected.

Keep the record lean while you build it. Every include, a, and mx adds to your DNS lookup budget, and overly broad entries (a bare +all, or an IP range wider than you actually use) quietly undo the protection you are trying to add.

Step 3: Publish It in Your DNS Zone

Add the finished string as a single TXT record at your domain apex - host/name @, type TXT, value the full v=spf1 … -all string in quotes. Save it, then allow for DNS propagation (usually minutes, occasionally up to the record’s TTL) before the new policy is live for every receiver worldwide.

Step 4: Test and Monitor the Record

Before you consider the job done, run the published record through a free SPF checker. A good check confirms three things at once: the syntax parses, the record stays under the 10-lookup limit, and the expanded list contains every sender from Step 1 and nothing it shouldn’t. Re-check after any change to who sends your mail.

Step 5: Pair SPF with DKIM and DMARC

SPF on its own leaves gaps (covered below), so finish by layering DKIM and a DMARC policy on top. DMARC is what turns three separate checks into enforcement - it requires SPF or DKIM to align with your “From” domain and gives you the reports to see who is sending as you.

Keeping a Record Healthy Over Time

An SPF record is not set-and-forget. The most common way a working record breaks is drift: a new sender gets added to your stack and nobody updates the TXT record, or a provider you include expands its own record until your total lookup count silently crosses ten. Both failure modes pass a syntax check yet reject real mail, which is why the record deserves a periodic re-validation the same way a DKIM key or a DMARC policy does.

The practical habit: re-run an SPF record check on a schedule and every time your sending changes, keep the policy at -all once your list is complete, and let something maintain the lookup budget for you. When includes push you toward the limit, AutoSPF flattens the record automatically - preserving the authorized IP addresses while collapsing nested lookups back into a single valid string - so a provider’s changes on their end never quietly take your mail down.

Statistical Data: Industry Adoption and Impact of SPF Records

• Adoption of SPF in corporate domains: Over 90%

• Reduction in successful email spoofing attempts when using SPF combined with DMARC: Up to 85%

• Average DNS lookup queries per SPF record: 3-5 (well-optimized records)

• Percentage of SPF failures due to improperly configured SPF records: ~20%

• Improvement in email deliverability after SPF implementation: 15-25%

These are directional industry estimates aggregated from published email-authentication adoption studies, not figures from a single vendor; treat them as orders of magnitude rather than precise benchmarks.

SPF Syntax Reference: Mechanisms and Qualifiers

Once you can read the parts of a record, most SPF troubleshooting becomes obvious. A record is a sequence of mechanisms, each optionally prefixed by a qualifier, closed out by a policy on all. Here is what each piece does.

SPF Mechanisms Include:

• `ip4` / `ip6`: Specifies authorized IP addresses or ranges.

• `a`: Authorizes the domain’s A or AAAA DNS records.

• `mx`: Authorizes the hosts named in the domain’s MX record(s) to send, not just receive.

• `ptr`: Validates the sender’s IP address against PTR records via Reverse DNS lookup (less common due to reliability issues).

• `include`: Incorporates SPF records from third-party services (e.g., SendGrid, Amazon SES, or Google Workspace).

• `all`: Defines the default policy for non-matching senders.

Each mechanism can be prefixed with an SPF qualifier to dictate the SPF evaluation result upon a match:

• `+` (pass) - a match authorizes the sender. This is the default, so +mx and mx mean the same thing.

• `-` (fail, or hardfail) - a non-match is unauthorized and should be rejected. This is the -all you want once your list is complete.

• `~` (softfail) - a non-match is probably unauthorized; accept but mark suspicious. Useful as a transitional step before committing to hardfail.

• `?` (neutral) - the domain asserts nothing, so receivers treat the result like no policy at all.

An example SPF record might look like this for Microsoft Office 365 (Exchange Online):

`v=spf1 include:spf.protection.outlook.com -all`

Here, the version tag (`v=spf1`) is mandatory, followed by mechanisms and a policy statement (`-all`) indicating only included servers can send emails.

How SPF Blocks Spoofing in Practice

Here is the attack SPF defeats: a scammer connects to a mailbox provider and announces they are sending for your domain, hoping the recipient trusts the name. Because the scammer controls neither your DNS nor an authorized server, the connecting IP is nowhere on your SPF guest list - so the check fails and the receiver can quarantine or drop the message before it reaches an inbox.

The catch is that this only works if your own legitimate senders all pass. If you run Microsoft 365, Google Workspace, or any mix of providers, each one’s sending IPs have to be represented in the record, or you create false failures that hurt the exact mail you want delivered. Watch especially for SPF alignment: a message can pass SPF on a Return-Path domain yet still fail DMARC if that domain does not match the visible “From”.

Where SPF Falls Short - and Why It Needs DKIM and DMARC

SPF has two well-known blind spots, both baked into its design. First, it only checks the envelope (Return-Path) domain, not the “From” address a person actually reads - so an attacker can pass SPF on a throwaway domain while still displaying your brand in the From line. Second, it breaks on forwarding: when a message is relayed, the forwarding server becomes the new source IP, which usually is not on your record, so a perfectly legitimate email fails SPF.

Neither gap means SPF is optional - it means SPF is one layer. DKIM survives forwarding because its signature travels with the message, and DMARC closes the “From”-spoofing gap by demanding that a passing SPF or DKIM result actually align with the visible domain. Run all three and you can analyze DMARC reports to see precisely which sources are failing SPF and fix them before you tighten enforcement.

How to Verify and Troubleshoot Your SPF Record

Most SPF problems trace back to one of three causes: a syntax slip, more than ten DNS lookups, or a sender that was never added to the record. A quick SPF record check surfaces all three at once, which is faster than reading raw DNS output by hand.

When a record misbehaves, work through it in this order:

• Confirm the record is actually published - one TXT entry at the apex, the value starting v=spf1. A missing or duplicated record is the single most common cause of a none or PermError result.

• Read the syntax left to right for typos, stray characters, or an unsupported qualifier.

• Cross-check the expanded IP list against your Step 1 inventory - every live sender present, nothing stale left behind.

• Count the lookups. If you are at or near ten, that is your ceiling, and adding one more include will tip the record into PermError.

• Confirm alignment with the “From” domain so SPF actually counts toward DMARC.

Re-test after every change to your sending - a new platform, a migration, or a provider quietly editing their own include. On a healthy domain, that check takes ten seconds; skipping it is how a working record drifts into a silent failure.