How to fix your SPF record

More than one SPF record

Merge them into one. Take every mechanism from both records, remove duplicates, and keep the gentler of the two all qualifiers — if one record ends -all and the other ~all, use ~all. Two records means at least one sender list was incomplete, and a hardfail on an incomplete list rejects real mail. Publish the merged record first, then delete the other one. Doing it the other way round leaves a window with no SPF at all.

Over ten DNS lookups

You cannot fix this without deciding which senders you still use, and that is a question about your business rather than your DNS. Work through the includes and ask, for each one, whether that platform still sends mail as your domain. An old helpdesk, a marketing tool nobody renewed, a CRM replaced two years ago — each is costing you lookups and authorising a system that should no longer be able to send as you.

Resist flattening. Replacing an include with the IP ranges it currently resolves to fixes the count today and creates a silent failure later, when the provider changes ranges and your record still lists the old ones.

Syntax errors and dead includes

One malformed term, or one include pointing at a domain that no longer publishes SPF, makes the entire evaluation permerror. Both are quick to fix once you know which term is at fault, which is what the scan tells you.

Ending in +all

+all tells every receiver that any server on the internet may send mail as your domain. It is almost always a mistake — someone testing, or a copied example. Change it to ~all, keeping every other mechanism exactly as it is.

Publishing safely

Lower the TTL on the record a day before if you can, so a mistake is quick to reverse. Write down the current value before you change it. Publish, wait, then check what is actually resolving rather than trusting the control panel — a record saved as example.com.example.com looks perfectly fine in the panel.