# Understanding SPF Failures: Protecting Your Email Reputation > SPF failures explained: softfail vs hardfail, common causes like exceeding 10 DNS lookups, and how to fix SPF to protect deliverability. ## What an SPF failure actually is [SPF (Sender Policy Framework)](/learning/what-is-spf) lets a domain publish, in [DNS](/learning/what-is-a-dns), the list of servers allowed to send mail on its behalf. When a receiving server gets a message, it checks the sending IP against that list and produces a result. An "SPF failure" is any result that isn't a clean pass — and the consequences range from a quiet reputation hit to outright rejection, depending on which failure it is. Understanding *which* failure you're looking at is the whole game, because they mean very different things. SPF is defined in [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208), and it returns one of several distinct results. ![An SPF record ending in ~all (softfail)](/images/figures/spf-record-softfail-example.webp) ## The SPF results, and what each one means - **Pass** — the sending IP is authorized. Nothing to fix. - **Fail (hardfail)** — the IP is explicitly *not* authorized. Produced by a record ending in `-all`. Receivers are entitled to reject the message. - **SoftFail** — the IP is probably not authorized, but the domain isn't asserting it firmly. Produced by `~all`. Mail is usually accepted but marked suspicious. - **Neutral** — the domain explicitly takes no position (`?all`). Treated almost like having no SPF at all. - **None** — the domain publishes no SPF record, or none could be found. - **PermError** — a permanent error in the record itself: broken syntax, more than one SPF record, or too many DNS lookups. The check can't complete until you fix the record. - **TempError** — a transient DNS problem (a timeout, for example). Usually resolves on its own. The critical distinction is **hardfail (`-all`) versus softfail (`~all`)**. A hardfail tells receivers to reject outright; a softfail tells them to accept but treat with suspicion. Most domains should run `~all` while rolling out authentication and only tighten to `-all` once [DMARC](/learning/what-is-dmarc) reports confirm every legitimate sender passes — see [softfail vs hardfail](/resources-post/spf-softfail-all-vs-hardfail--all-why-softfail-is-the-smarter-choice) for the full trade-off. ## Common causes of SPF failures ### Exceeding the 10 DNS-lookup limit This is the single most common cause of a broken SPF record. RFC 7208 caps the number of mechanisms that require a DNS lookup — `include`, `a`, `mx`, `ptr`, `exists`, and the `redirect` modifier — at **10** per evaluation. Every `include:` for a third-party sender (Google Workspace, Microsoft 365, a marketing platform) can pull in further nested lookups, and it adds up fast. Go over 10 and the result is a **PermError**, which means SPF fails for *all* your mail, not just the extra sender. There's also a limit of **2 void lookups** (lookups that return nothing) before a PermError. ### More than one SPF record A domain may publish **only one** SPF TXT record. If two exist — often one left behind by a previous provider — the result is a PermError. Merge everything into a single `v=spf1 ...` record. ### Forwarding SPF checks the **envelope sender** (the `MAIL FROM` / Return-Path), not the visible `From:` address. When a message is forwarded, the forwarding server sends from *its* IP, which your SPF record doesn't authorize — so SPF fails at the next hop even though the mail is legitimate. This is why [DKIM](/learning/what-is-dkim) matters: its signature survives forwarding, so DMARC can still pass on DKIM when SPF breaks. ### An un-included sender Adding a new email tool — a CRM, a ticketing system, a newsletter platform — without adding its `include:` to your SPF record means its mail fails SPF from day one. Every service that sends as your domain has to be listed. ### Syntax mistakes A stray space, a missing `include:` prefix, or the wrong `all` qualifier produces either a PermError or an unintended result. The [SPF syntax guide](/learning/spf-record-syntax-explained-mechanisms-qualifiers) covers the mechanisms and qualifiers in detail. ## Why SPF failures hurt your reputation A failing SPF check rarely just bounces one message. Repeated failures — from a lookup-limit PermError, an un-included sender, or a mis-set `-all` — teach mailbox providers that mail from your domain is unreliable, and that lowers your [domain reputation](/learning/what-is-a-domain-reputation) across the board. Worse, a PermError can make your entire domain fail authentication at once, which under an enforced DMARC policy means legitimate mail gets quarantined or rejected. Protecting deliverability and protecting SPF are the same task. ## How to fix and prevent SPF failures 1. **Audit your record.** Run your domain through the [SPF lookup tool](/tools/spf) to see the current record, count the DNS lookups, and catch PermErrors. 2. **Stay under 10 lookups.** Remove `include:` entries for services you no longer use. If you're near the limit, flatten the record (replace some includes with the underlying IP ranges) or consolidate senders. 3. **Keep one record.** Delete duplicate SPF TXT records so only a single `v=spf1` record remains. 4. **List every sender.** Add an `include:` (or the correct IP mechanism) for each service that legitimately sends as your domain. 5. **Use `~all` while rolling out.** Start with softfail, watch DMARC reports, and only move to `-all` once every legitimate source passes. 6. **Pair SPF with DKIM and DMARC.** Because forwarding breaks SPF, [DKIM](/learning/what-is-dkim) gives you a second, forwarding-resistant path to authenticate, and [DMARC alignment](/resources-post/fixing-spf-alignment-dmarc----full-guide) is what turns passing checks into real spoofing protection. For a from-scratch walkthrough, see [how to create an SPF record](/resources-post/how-to-create-an-spf-record-a-step-by-step-guide-for-better-email-authentication), and check your whole posture with the [Email Security Score](/tools/email-security-score). ## Frequently asked questions ### Does an SPF softfail mean my email will be rejected? Usually not. A softfail (`~all`) tells receivers the sender is probably unauthorized but stops short of asserting it, so most accept the message and may mark it suspicious or route it to spam. A hardfail (`-all`) is the one that invites outright rejection. ### Why does SPF fail after my email is forwarded? Because SPF authorizes IPs against the envelope sender, and forwarding changes the sending server to one your record doesn't list. The message is fine; SPF just can't vouch for the new hop. A valid DKIM signature survives forwarding, which is why DMARC can still pass on DKIM alone. ### What is an SPF PermError and how do I fix it? A PermError is a permanent fault in the record — most often more than 10 DNS lookups, more than one SPF record, or a syntax error. It causes SPF to fail for all your mail. Fix it by reducing includes to stay under 10 lookups, merging to a single record, and correcting the syntax. ### Can I have two SPF records on one domain? No. A domain must publish exactly one SPF TXT record. Two or more causes a PermError. Combine all your `include:` and IP mechanisms into a single `v=spf1` record. ### Does fixing SPF failures improve deliverability? Yes. Consistent SPF passes are a positive signal to mailbox providers and prevent PermErrors that would fail your whole domain. Combined with DKIM and an enforced DMARC policy, reliable SPF is one of the strongest levers you have on inbox placement. ## Related reading - [Softfail (~all) vs hardfail (-all): which to use](/resources-post/spf-softfail-all-vs-hardfail--all-why-softfail-is-the-smarter-choice) - [How to create an SPF record (step-by-step)](/resources-post/how-to-create-an-spf-record-a-step-by-step-guide-for-better-email-authentication) - [Fixing SPF alignment (DMARC) — full guide](/resources-post/fixing-spf-alignment-dmarc----full-guide)