Guides • Last Updated 5th April 2026 • 3 min read

How to Read SPF Records Correctly

Learn how to read an SPF record, understand mechanisms and qualifiers, spot risky syntax, and tell whether an SPF policy is too broad or too complex.

Tools For This Topic

SPF Checker

Break down SPF mechanisms, redirects, includes, and lookup count.

SPF Flattener

Generate a flattened SPF-style output from the current effective SPF policy.

Blacklist Checker

Check whether a domain or IP appears on common blocklists.

What you are looking at in an SPF record

An SPF record is a TXT record that lists which servers or services are allowed to send mail for a domain. Reading it properly means understanding both the order of the mechanisms and the effect of the final qualifier.

A record can look short and still be risky, or look long and still be perfectly valid. The job is not just to read the text, but to understand the effective sending policy it creates.

Example SPF record

v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:_spf.google.com -all

This example authorises one direct IPv4 address plus two external provider policies, then uses -all to fail anything else.

How to read the main parts

v=spf1 marks the TXT record as an SPF policy
ip4 and ip6 authorise specific IP addresses or ranges
include imports another domain's SPF policy
a and mx authorise addresses derived from DNS lookups
all is the catch-all rule for anything not matched earlier

SPF is evaluated from left to right. That means the order matters, especially when a record mixes direct IPs, includes, and broad mechanisms.

What the qualifier tells you

-all means hard fail for everything not explicitly authorised
~all means soft fail and is often used during less mature stages
?all means neutral and gives little protection
+all effectively allows everything and is usually a major red flag

The last qualifier often tells you more about the policy posture than the rest of the record. A carefully built SPF record can still be weak if it ends with an overly permissive fallback.

Signs an SPF record needs attention

There are many nested include statements and the record looks hard to reason about
The policy uses +all or ?all
The domain publishes multiple SPF TXT records instead of one valid policy
The record appears to authorise providers that are no longer in use
The policy likely exceeds or approaches the ten-DNS-lookup limit

How to review SPF in practice

The safest workflow is to read the visible record, then resolve the includes and redirects so you understand the effective policy. That is especially important when the domain uses Microsoft 365, Google Workspace, or multiple third-party senders.

A record that looks simple can still expand into a much larger policy once the imported mechanisms are followed.

Use These DNS Pro Tools

If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.