How to read an SPF check: every part of the result, explained

An SPF check answers one question: which servers are allowed to send email for your domain. The result you got back - a line of text starting with v=spf1, plus a verdict - is read in 3 parts: the mechanisms (the list itself), the qualifier at the end (what happens to everyone not on the list), and the lookup count (whether the record even works). This page walks through all 3, then the handful of results that actually matter, including the 2 failures that break delivery silently.

If you haven't run the check yet: paste your domain into MXToolbox and run the SPF lookup. The walkthrough below makes most sense with your own record on screen. We also keep a shorter plain-English answer to what an MXToolbox SPF result means if you want the 1-minute version, and the email deliverability guide for where SPF fits in the bigger fix.

Reading the record, left to right

A typical Australian small business record looks something like:

v=spf1 include:spf.protection.outlook.com include:_spf.mlsend.com ip4:203.0.113.7 ~all

v=spf1 - the version tag. Always present, always this. A record not starting with it is not an SPF record.

The mechanisms - everything in the middle is the actual list of permitted senders:

• include: pulls in another domain's published list of servers. include:spf.protection.outlook.com means "everything Microsoft 365 sends from is allowed" - this is how your email provider, newsletter platform and form handlers each get on the list without you maintaining their server addresses.
• ip4: (and ip6:) name specific server addresses directly - typically your web server, if it sends order confirmations or contact-form mail.
• mx and a allow the servers already named in your domain's mail and address records. Common, harmless, occasionally redundant.

Every legitimate service that sends email as your domain must be covered by one of these. The most common SPF problem isn't syntax - it's the invoicing tool someone connected in 2023 that nobody added to the list, whose mail has been quietly failing ever since.

The qualifier - the all at the end says what receivers should do with mail from servers not on the list, and the single character in front of it is the whole policy:

• -all (fail) - reject everything else. The strict, correct destination.
• ~all (softfail) - treat everything else with suspicion. The sensible setting while you are still confirming the list is complete.
• ?all (neutral) - express no opinion. Functionally close to useless.
• +all (pass) - explicitly allow the entire internet to send as your domain. This setting appears in the wild more than you would hope, usually as a "fix" for a delivery problem someone had years ago. If your record ends in +all, it is doing nothing except advertising that fact.

The verdicts that matter

Pass - the record exists, parses, and the sending server was on the list. This is the goal, for every service you legitimately send from.

Softfail / Fail - the sending server wasn't on the list. For mail from a stranger pretending to be you, this is the system working. For your own mail, it means a sender is missing from the record - find which service sent the failing message and add its include:.

None - no SPF record at all. At this point you are in the minority: 89% of Australian small business domains publish one^*. Publishing a basic record for your actual email provider is a 10-minute fix with no downside.

Permerror - the record exists but is broken, and receivers treat it as if it were absent or worse. This is the verdict that hides in plain sight, and it has 2 usual causes - both silent.

The 2 silent breakers

More than 10 DNS lookups. SPF caps the number of DNS lookups a record may trigger at 10 - and every include: counts, including the ones inside the includes you reference. A business that has accumulated Microsoft 365, a newsletter tool, a CRM and a couple of form services over the years can cross the limit without any single addition looking wrong. The record validated last year; this year's one extra include: tipped it; nothing announced the change. The checker reports the lookup count - if you are at 9 or 10, prune before you add. Includes for services you no longer use are the first candidates.

A second SPF record. A domain must have exactly one. Two records - classically, one created by the web host and another added later for the email provider - invalidate each other, and receivers see a domain with broken authentication. The fix is never to delete one and lose its senders: merge the mechanisms into a single record and remove the rest. Checkers flag this as "multiple records found", and it is worth a deliberate look whenever a new provider's setup wizard offers to "add an SPF record for you".

What a passing SPF check doesn't prove

SPF is one of 3 authentication records, and the weakest alone - it breaks when mail is forwarded, and it says nothing about whether the message content was tampered with. A domain can pass every SPF check and still have its mail land in spam because DKIM is unsigned or DMARC sits at p=none; the deliverability guide covers how the 3 records work as a set and the order to fix them in. And SPF protects mail from your domain - it does nothing about mail to you.

The honest summary: get the list complete, get the lookup count under 10, end in ~all while you verify and -all when you have, and keep it to exactly one record. Our scan's Email category checks all of this on every run - the same verdicts as the manual check, in plain English, re-checked on schedule so the record that passes today still passes after the next provider someone connects. An SPF record is a guest list - and guest lists are only ever wrong in the direction nobody notices.