How to Fix an SPF Record

A broken SPF record is one of the most common reasons legitimate email lands in spam and spoofed email slips through. The good news is that almost every SPF record problem falls into a short list of well-understood mistakes, each with a clear fix. This guide walks through how to fix an SPF record, from the most damaging errors to the small details that quietly weaken your protection. If you need the basics first, start with our explainer on what SPF is.
Problem 1: More than one SPF record
A domain may publish only one SPF record. If a scan finds two, perhaps one added by your email host and another by a marketing tool, receiving servers see a permanent error and SPF fails completely. The fix is to merge every source into a single record that starts with v=spf1, combining all the include mechanisms from both into one line, then delete the extras. This single mistake breaks more SPF setups than any other.
Problem 2: Too many DNS lookups
SPF allows a maximum of ten DNS lookups when a record is evaluated, and every include, a, mx and similar mechanism counts. Stacking several providers easily pushes you over the limit, which causes SPF to fail even though the record looks reasonable. To fix an SPF record that exceeds the limit, remove providers you no longer use, replace broad includes with specific ip4 or ip6 entries where practical, or use a maintained flattening service that keeps the lookup count down. Every source you drop buys back headroom.
Problem 3: A soft fail where you want a hard fail
The end of your record tells receivers how to treat mail from servers that are not listed. A soft fail, written ~all, only marks such mail as suspicious, while a hard fail, written -all, tells receivers to reject it. If your record ends in ~all or, worse, +all, tighten it to -all once you are confident every legitimate sender is included. Leaving a permissive ending in place is like locking the door but leaving the key under the mat.
Problem 4: A missing sending source
If a genuine service is not listed, its mail fails SPF and may be rejected. Work through everything that sends on your behalf, your mail host, newsletter tool, invoicing system, help desk and any server applications, and make sure each has an include or address entry. DMARC aggregate reports are the best way to discover senders you forgot, which is another reason to enable them. See our guide on fixing DMARC p=none for how those reports help.
Problem 5: Syntax and formatting errors
Small mistakes cause big failures. Watch for a missing v=spf1 prefix, stray spaces, duplicate mechanisms, or the record being split incorrectly across DNS strings. After editing, always confirm the record resolves as a single, valid line. A careful review here prevents the frustrating situation where a record looks correct but never actually passes.
Step by step: the safe order to fix an SPF record
- Inventory every service that sends email as your domain.
- Build one record with v=spf1, the includes and addresses for those services, and -all at the end.
- Remove any second SPF record from your DNS.
- Confirm you are under ten lookups, trimming where needed.
- Publish, then re-scan to verify it passes and aligns with DMARC.
Confirm the fix with a scan
Once you have edited your DNS, verify the result rather than assuming it worked. Run a security scan with EzyAudit AI and check that a single valid SPF record is published, sits within the lookup limit, ends in a hard fail, and supports your DMARC policy. Each result is explained clearly so you know exactly what, if anything, still needs attention. See the full list of checks, and consult IETF RFC 7208 for the formal SPF specification.
A clean, single SPF record ending in -all is the foundation of email your recipients and their mailbox providers can trust. Scan your website now to check your SPF record in seconds.