Seven SPF mistakes that break mail quietly

1. Two SPF records

Publishing a second v=spf1 TXT record, which usually happens when a new vendor's setup guide is followed literally rather than merged into the existing record, produces a permanent error. Receivers do not merge them. Merge the mechanisms into one record instead.

2. SPF on a CNAME'd or wrong name

The record belongs on the exact domain used in the envelope sender. Publishing it on www.example.com, or on a host that is a CNAME to somewhere else, means nothing checks it.

3. Exceeding ten lookups

Permerror, which DMARC counts as an SPF failure. Nothing in your mail client will tell you; only the reports will.

4. Using the SPF RR type

DNS once had a dedicated SPF record type (type 99). It was deprecated in 2014. Publish SPF as TXT, and delete any type 99 records still lying around.

5. Splitting the string wrong

A single TXT string caps at 255 characters. Longer records must be split into multiple quoted strings within one record, which resolvers concatenate with no separator. Some DNS UIs do this for you; some do not.

"v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 " "include:_spf.example.net -all"

6. Authorising more than you meant

A wide ip4 range from a shared hosting provider authorises every other customer on that platform to send as you. Prefer the narrowest range the provider will commit to.

7. Forgetting the domains that never send

Parked domains and subdomains get spoofed precisely because nobody thinks about them. Publish a record that authorises nothing: v=spf1 -all.