SPF record check

Symptoms

SPF fails quietly. Nothing in your mail client changes, no bounce arrives, and the record still looks fine when you read it. What you notice instead is that mail to some recipients starts landing in spam, a vendor's newsletters stop arriving, or DMARC reports show failures for mail you definitely sent.

The usual causes, in the order we find them:

• The record grew past ten DNS lookups when somebody signed up for one more tool.
• Two SPF records exist because a provider added one without removing the old.
• The record ends in ?all or has no all at all, so nothing is ever refused.
• An old vendor's include: now points at a domain that no longer publishes SPF.

Diagnosis

SPF is a list of who may send mail using your domain on the envelope. A receiving server reads your record, follows every include: it contains, and builds the full set of authorised addresses. That expansion is the expensive part, and the specification caps it.

The ten-lookup limit

Ten DNS-lookup-consuming terms, total, across the whole chain, include, a, mx, ptr, exists andredirect=. ip4: and ip6: are free, which is why flattening works. Exceed the limit and the result is a permanent error: not "fail", not "unknown", but a record receivers stop trusting entirely.

Void lookups

A lookup that returns nothing counts too, and you are allowed only two. Three dead vendor includes will break a record that is otherwise well inside the ten-lookup budget, this is the check almost nothing else performs.

The closing mechanism

The last mechanism decides what happens to everyone not on the list. -all says refuse, ~all says treat as suspicious, ?all and +all say nothing at all, and +all authorises the entire internet to send as you.

Cure

Depending on what the test found:

1. Over ten lookups, remove services you no longer use first, since that is free. Then replace a stable vendor's include: with the ip4: ranges it resolves to, and re-check whenever that vendor changes infrastructure.
2. Two records, merge every mechanism into one v=spf1 record and delete the rest.
3. No enforcing rule, end the record with ~all, then-all once your reports are clean.
4. Dead includes. Remove them. They cost a lookup and a void lookup, and buy nothing.

A healthy record for a domain sending through one provider looks like this, and rarely needs to be more complicated: v=spf1 include:_spf.yourprovider.com -all

Questions people actually ask

Related tests

• DMARC checker, is your policy actually applied?
• DKIM checker, selector discovery and key strength
• Full checkup, every record at once