What we checkEmailEM-02
SPF record syntax
A valid SPF record parses cleanly, stays inside the lookup limit, and does not end in a wildcard pass.
- Area
- Check
- EM-02
- Included
- Free in every scan
What we check
We parse your SPF record the way a receiving mail server does: the mechanisms in order, the qualifier on each, and the total number of DNS lookups it requires.
We flag +all, which authorises the entire internet to send as you.
Why it matters
An SPF record that does not parse is worse than no record at all — the effort is spent and the protection is not there.
+all is the specific case worth its own alarm: it tells every receiver that any server may send as your domain, which is exactly the statement an attacker would like you to make on their behalf.
How to fix it
- 1
Remove any
+alland replace it with-all. - 2
Count your
include:,a:,mx:andredirect=mechanisms — each costs a lookup, and ten is the ceiling. - 3
Delete includes for services you no longer use. Most records that hit the limit are carrying a mail provider from two migrations ago.
Common questions
- What is the difference between
-alland~all? -allsays unauthorised mail should be rejected;~allsays it should be accepted but marked suspicious.~allis a reasonable place to start while you confirm you have listed every sender. It is not a reasonable place to stay.- Why does
+alleven exist? - It is the explicit form of the default qualifier, and it is almost always a mistake — usually someone testing a change and never removing it.
- Does SPF check the address my recipient actually sees?
- No, and this is the gap DMARC closes. SPF validates the envelope sender, which is invisible in most mail clients. DMARC requires that the visible From address aligns with what SPF or DKIM authenticated.
See how your domain does on this check.
All 34 checks, a grade, and the exact fix for anything that isn’t right — in about twenty seconds, no signup.