What Is SPF? Sender Policy Framework Explained

SPF is the DNS record that tells the rest of the internet which servers are allowed to send mail using your domain. If outbound mail from your new tenant is landing in spam, or marketing emails are bouncing with policy errors, the SPF record almost always needs work. This page explains what SPF is, how the include mechanism actually behaves at lookup time, and the specific changes you make to SPF during an email migration.

What SPF is#

SPF stands for Sender Policy Framework. It is defined in RFC 7208 and is published as a TXT record on your domain. A simple SPF record looks like this:

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

That single line tells every receiver on the internet: "if a message claims to come from my domain, the sending server should be on Google's list. If it isn't, treat the message as a hard fail."

SPF authenticates the envelope sender — the MAIL FROM address used during the SMTP transaction — not the friendly From address users see in their mail client. That distinction is why SPF on its own does not stop most user-visible spoofing.

How the syntax works#

Every SPF record starts with v=spf1 and ends with an all mechanism. In between sit one or more mechanisms that authorise specific senders.

• include:_spf.example.com — pull in another domain's SPF record. Use this for cloud providers.
• ip4:192.0.2.1 — authorise a specific IPv4 address.
• ip6:2001:db8::/32 — authorise an IPv6 range.
• a — authorise the domain's own A record.
• mx — authorise the hosts listed in the MX record.

The final mechanism is all, prefixed by a qualifier:

• -all — hard fail. Reject mail from anything not listed.
• ~all — soft fail. Accept but mark suspicious.
• ?all — neutral. Don't make a judgement.

Production records almost always end in -all. Anything weaker tells receivers your policy is advisory.

The 10-DNS-lookup limit#

The single most common SPF mistake is going over the lookup limit. RFC 7208 says a receiver evaluating an SPF record must perform no more than 10 DNS lookups in total. Every include, a, mx, exists and redirect counts. Includes are recursive, so each provider's SPF can itself trigger several lookups.

A record like this looks innocent:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org include:_spf.salesforce.com -all

In practice it can resolve to 11 or 12 lookups, depending on how each provider has structured their own SPF. Once you exceed 10, receivers return permerror and treat the whole record as broken. Outbound mail from every one of those services starts failing SPF at once.

SPF during a migration#

Updating SPF is one of the four DNS jobs at cutover, alongside MX, DKIM and DMARC.

The pattern is the same regardless of provider.

1. Find the new provider's include. Microsoft 365 uses include:spf.protection.outlook.com. Google Workspace uses include:_spf.google.com. Zoho uses include:zoho.com.
2. Add it to the existing SPF record before cutover. SPF can authorise both providers at once during the transition window.
3. After cutover stabilises, remove the old provider's include to keep the record under the lookup limit and reduce the spoofing surface.

For Microsoft tenants specifically, see the Office 365 migration guide. The SPF step is the same whether you're moving from Google Workspace, GoDaddy, or a self-hosted server.

Testing SPF#

Two checks catch almost every problem.

• dig TXT example.com — confirm exactly one record starts with v=spf1. If there are two, merge them.
• Send a test message to a Gmail address. Open the message, click Show original, and read the Authentication-Results header. SPF should report pass with spf=pass smtp.mailfrom=... pointing at the right sending domain.

If SPF returns softfail or none, the receiver did get a result back but it didn't authorise the sender. If it returns permerror, the record is syntactically broken or over the lookup limit.

What SPF doesn't do#

SPF is one piece of email authentication, not all of it. It does not protect the visible From address. It does not survive forwarding. It does not sign the message body. For full protection you also need DKIM and DMARC. Plan all three changes together in the migration runbook — see the complete email migration guide for how they sequence relative to the MX flip.