An SPF record is a line of text in your domain's DNS that lists the servers and services allowed to send email for your domain. When your email arrives, the receiving server checks that list, and if the server that sent it isn't on it, the email is more likely to go to junk or be rejected.
SPF stands for Sender Policy Framework. DNS is the public set of records that tells the internet where your website and email live. Your SPF record sits there as a TXT record (a record that just holds text) on your main domain, yourbusiness.com.au.
What an SPF record looks like
Here's a typical record for a business using Microsoft 365, plus a web server that sends enquiry notifications:
v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 ~allRead it left to right:
v=spf1says "this is an SPF record". Every SPF record starts with exactly this.include:spf.protection.outlook.comsays "also allow every server listed in Microsoft 365's own SPF record". Most email services give you an include like this. It saves you listing their servers yourself, and they keep it up to date.ip4:203.0.113.10allows one specific server by its address. You only need this for a server you run yourself, such as your own web server. Never add an address you don't recognise.~allis the rule for everything else: any server not listed above.
The receiver stops at the first entry that matches the sending server. Anything after all is ignored, so new includes always go before it.
Look up your own record
Enter your domain to see the SPF record you have now, what it allows, and whether it breaks any of the rules below.
This reads your public DNS only. To see whether your email actually passes, and where it lands, send a free test.
Softfail or fail: ~all and -all
The symbol in front of all tells receivers how strongly you mean it.
| Ending | Name | What it asks receivers to do |
|---|---|---|
~all | Soft fail | Accept email from unlisted servers, but treat it as suspicious. Outlook may put it in Junk Email. |
-all | Fail (hard fail) | Treat email from unlisted servers as not authorised. It's often refused. |
?all | Neutral | Make no judgement. Not recommended. |
+all | Pass | Let any server in the world send as you. Never use this. |
Our reports suggest ~all when you first set up SPF. Microsoft recommends -all once DKIM and DMARC are in place. DMARC counts both as an SPF failure. In practice, receivers decide for themselves what to do with a failure, so the ending matters less than getting the list right.
Rule 1: only one SPF record
A domain can have only one TXT record that starts with v=spf1. This catches out a lot of people. You add Microsoft 365, then a year later a newsletter tool asks for SPF, and someone adds a second record instead of editing the first.
With two records, receivers can't tell which one to use. The result is a permanent error, and SPF fails for every email you send, including the ones from Microsoft 365. The fix is to merge every include into one record and delete the other.
Each subdomain needs its own record if it sends email. The SPF record for yourbusiness.com.au doesn't cover news.yourbusiness.com.au.
Rule 2: no more than 10 DNS lookups
Checking an SPF record can mean looking up other records. Each include:, a, mx, ptr and exists entry, and a redirect=, costs one DNS lookup. Includes can contain further includes, and those count too. The limit is 10 in total. ip4:, ip6: and all are free.
Go over 10 and receivers treat your record as broken, even though it looks fine. Microsoft 365's include uses one lookup, but some services use two or three. A business that has added an accounting tool, a CRM, a newsletter tool and a website plugin over the years can hit the limit without noticing.
To get back under 10, remove includes for services you no longer use, or ask a provider for a smaller ("flattened") include. Don't flatten Microsoft 365's include yourself. Microsoft's servers change often.
SPF and DMARC: why passing isn't always enough
Here's the part that confuses most people. SPF doesn't check the From address your customer sees. It checks the hidden return address used for bounces (often called the envelope sender or Return-Path).
When Microsoft 365 sends your email, the return address is on your own domain, so SPF passes for yourbusiness.com.au. But many services, including some that send invoices for you, use their own domain for the return address. SPF then passes for their domain, not yours.
DMARC, which Gmail, Yahoo and Outlook now require from bulk and high-volume senders, only counts SPF when it passes for the same domain as the From address, or a subdomain of it. That match is called alignment. If SPF passes for a service's domain rather than yours, it doesn't help with DMARC. That's why you also need DKIM signed with your own domain. Either one passing and aligned is enough for DMARC.
What our test checks
Send one email to your free test address and we check SPF exactly as a receiver would: whether the sending server is allowed, whether you have more than one record, whether you're over the lookup limit, and whether SPF passed for your own domain. You get a verdict for Gmail, Google Workspace, Outlook.com, Microsoft 365 and Yahoo, and the exact record to publish if something needs fixing.
Checked against: RFC 7208, Sender Policy Framework (SPF) · Microsoft Learn, Set up SPF to identify valid email sources for your Microsoft 365 domain · RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC).