What is SPF and how does it work?

SPF (Sender Policy Framework) is a DNS-based email authentication mechanism that allows a domain owner to specify which mail servers are authorised to send email on its behalf.

When a receiving mail server processes an inbound message, it checks the sending IP address against the SPF policy published in DNS for the domain in the envelope sender (MAIL FROM).

You can analyse a domain's SPF configuration with the DNS Pro SPF Checker.

For comparison, you can also use external tools like MXToolbox: https://mxtoolbox.com/spf.aspx

SPF is published as a TXT record in DNS and always begins with v=spf1.

A typical example:

example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

SPF evaluation is performed by the receiving mail server and follows a deterministic process:

• Extract the domain from the MAIL FROM (envelope sender)
• Query DNS for the SPF TXT record
• Evaluate mechanisms from left to right
• Stop when a match is found
• Apply the qualifier (pass, fail, softfail, neutral)

Each mechanism may trigger additional DNS lookups, which are subject to strict limits.

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

• v=spf1 → identifies the record as SPF
• ip4:203.0.113.10 → explicitly allows that IPv4 address
• include:spf.protection.outlook.com → imports Microsoft 365’s SPF policy
• -all → denies all other sources

The all mechanism acts as the default rule when no earlier mechanisms match.

• -all → Fail (recommended for enforced policies)
• ~all → SoftFail (monitoring / transitional)
• ?all → Neutral (no policy)
• +all → Pass (unsafe and should not be used)

The include mechanism delegates SPF evaluation to another domain. It effectively says: 'if that domain authorises this sender, then so do I.'

This is commonly used for third-party services such as Microsoft 365, Google Workspace, or marketing platforms.

SPF evaluation is limited to a maximum of 10 DNS lookups. Mechanisms like include, redirect, mx, and a all contribute to this count.

Exceeding this limit results in a permerror, which can cause legitimate messages to fail authentication.

If your record is complex, you may need to optimise it or consider techniques like SPF flattening.

• What is SPF flattening?
• How to fix SPF PermError

SPF only validates the sending infrastructure and does not guarantee message integrity or alignment with the visible From address.

Modern email security relies on SPF working alongside DKIM and DMARC.

• What is DMARC and how does it work?
• SPF vs DKIM vs DMARC

• Publishing multiple SPF records instead of one combined record
• Exceeding the 10 DNS lookup limit
• Leaving legacy include statements after migrations
• Using +all which effectively disables protection
• Misunderstanding redirect behaviour

When troubleshooting SPF issues, focus on both the published record and the effective policy after recursion.

• Validate the SPF record syntax
• Check lookup count and recursion depth
• Confirm all legitimate sending platforms are included
• Verify the final all mechanism behaviour
• Ensure alignment with DKIM and DMARC policies

# Retrieve SPF record
dig TXT example.com

# Alternative lookup
nslookup -type=txt example.com

• How to check an SPF record
• How to fix SPF PermError

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

• SPF Checker
• Email Security Check
• Email Header Analysis
• How to Check an SPF Record
• How to Fix SPF PermError