Email error

Cause · impact · fix

spf=fail (hardfail)

The server that sent your message is not authorised by your domain's SPF record, and that record ends in -all, so the receiver reports a hard fail. Here is why, what it costs you, and how to fix it.

What it means

The cause.

spf=fail is the result a receiver writes into the Authentication-Results header after checking SPF. It means the IP address that connected and sent your message is not covered by any mechanism in the SPF record published at your From: domain, and that record ends in -all. The "-" qualifier is a hard fail: RFC 7208 defines it as an explicit statement that the sending host is not authorised to use the domain.

The word "hardfail" distinguishes it from softfail. A record ending in ~all produces spf=softfail — a weak assertion that the host is probably not authorised — and receivers usually accept the mail with a higher spam score. A record ending in -all produces spf=fail, which a receiver is entitled to reject outright at the SMTP stage with 550 5.7.1. Same missing IP, stronger policy, harsher outcome.

The cause is almost always a legitimate sending source you forgot to authorise: a new email platform, a CRM, a helpdesk, a mailing tool or a server that relays your mail but whose IP or include is not in your SPF record. Less commonly it is genuine spoofing — someone sending as your domain from an IP you rightly do not authorise — in which case the hard fail is working exactly as intended.

Why it matters

The impact.

Because your record ends in -all, receivers may reject the affected mail during the SMTP conversation with 550 5.7.1 rather than merely file it as spam. Mail from the unlisted source can bounce back to you outright, and the sender never lands in the inbox at all.

It also breaks DMARC. DMARC passes only when SPF or DKIM passes and aligns with your From: domain, and DMARC treats hardfail and softfail identically — both are an SPF failure. If the message was relying on SPF to satisfy DMARC and DKIM is not also passing and aligned, DMARC now fails. Since 2024 Gmail, Yahoo and Microsoft require DMARC to pass for bulk senders, so an unauthorised source quietly turns into spam placement or rejection at exactly the mailboxes that matter most.

What to do

The fix, in order.

Work top to bottom, then re-check — DNS changes take a few minutes to take effect.

  1. 1 Identify the server that actually sent the message. Open the failing message's headers and read the Received-SPF or Authentication-Results line — it names the IP that failed. Confirm whether it is one of your own sending services or something you do not recognise. Everything else depends on this answer.
  2. 2 If it is your own sender, authorise it in SPF. Add the missing source to your single SPF record — normally the provider's published include: (for example include:_spf.google.com or include:sendgrid.net), or an ip4:/ip6: range for a server you run yourself. Add it to the existing record; never publish a second SPF record, as two records is its own permanent error.
  3. 3 Keep the record inside 10 DNS lookups. Every include, a, mx, ptr, exists and redirect counts toward SPF's limit of 10 DNS lookups. Adding a sender can tip you over and cause a PermError, so count as you go and remove includes for services you no longer send through.
  4. 4 If it is not your sender, leave -all in place. A hard fail on an IP you do not recognise is SPF doing its job. Do not weaken -all to ~all to make the result disappear — that hides spoofing rather than stopping it. Investigate the source instead, and let your DMARC policy handle the rejection.
  5. 5 Do not soften -all to hide a real gap. Switching to ~all changes spf=fail to spf=softfail but does not authorise your sender; the mail still fails DMARC on SPF. Fix the missing source in the record rather than downgrading the qualifier.
  6. 6 Re-check after DNS propagates. DNS updates take a few minutes. Run your domain through the SPF checker to confirm the sending IP is now covered and the record is valid and under the lookup limit, then send a test message and read its Authentication-Results header for spf=pass.

Confirm the error is gone.

Run a full check on your domain — it reads SPF, DKIM and DMARC live and tells you, in plain terms, whether the thing behind this error is fixed. Free, no account.

Common questions

About this error.

What does spf=fail (hardfail) mean? It is an SPF result written by the receiving server. It means the IP that sent your message is not listed in your domain's SPF record, and that record ends in -all — a hard fail, which RFC 7208 defines as an explicit statement that the host is not authorised to send for the domain.
What is the difference between hardfail and softfail? Both mean the sending IP is not in your SPF record. Hardfail comes from a record ending in -all and lets receivers reject the mail outright with 550 5.7.1. Softfail comes from ~all and usually means the mail is accepted but treated as more suspicious. DMARC counts both as an SPF failure.
How do I fix spf=fail (hardfail)? Read the failing message's headers to find the sending IP. If it is your own service, add its include: or ip4:/ip6: range to your existing SPF record and stay within 10 DNS lookups. If it is not yours, leave -all in place — the fail is stopping unauthorised mail as intended.
Is spf=fail (hardfail) permanent? It persists on every message from the unauthorised source until you either authorise that source in your SPF record or stop sending from it. It is not a temporary DNS error like TempError; it reflects your published policy, so it clears only when the record or the sender changes.
Should I change -all to ~all to fix the failure? No. Softening to ~all only changes the label from fail to softfail; it does not authorise your sender, and the message still fails DMARC on SPF. It also weakens your protection against spoofing. Add the missing sender to the record instead of downgrading the qualifier.
Does spf=fail cause my email to bounce? It can. Because -all is a hard policy, a receiver may reject the message during SMTP with 550 5.7.1 and return a bounce, and it also fails DMARC, which since 2024 pushes bulk mail at Gmail, Yahoo and Microsoft to spam or rejection.