Fix "SPF Failed" Error

The Problem

Your mail is showing "SPF: FAIL" in the headers, or a report is telling you SPF checks are failing for messages that should be legitimate — and that failure alone can be enough to get mail junked or rejected depending on the receiving server's policy.

About this problem

An SPF failure happens when the server that actually sent the message isn't listed as an authorised sender in the domain's SPF record — which can mean the message is genuinely spoofed, or just as often, means a legitimate sending service (a CRM, an invoicing tool, a forwarding rule) was never added to the record in the first place. Forwarded email is a particularly common, confusing cause, since forwarding naturally breaks SPF by design unless the forwarding server handles it specifically.

This tends to surface after adding a new sending tool, after setting up email forwarding, or when a DMARC report first gets read and shows unexpected SPF failures from services the domain owner didn't realise were sending on their behalf.

What's Included

• Reviewing the exact message and headers that triggered the SPF failure
• Checking the current SPF record against every legitimate service actually sending for the domain
• Identifying whether the failure is a missing legitimate sender or genuine spoofing
• Correcting and republishing the SPF record to include what's actually needed
• Verifying the fix with a real test send and checking the resulting headers

What's NOT Included

• SPF failures caused by email forwarding that the receiving server doesn't handle correctly (a structural limitation of SPF and forwarding, not a fixable record issue)
• Setting up DKIM or DMARC if they're also missing (separate or bundled services)
• Investigating third-party spoofing incidents beyond identifying that spoofing is likely the cause

How It Works

1. Pull the exact message headers (or DMARC report) showing the SPF failure and identify the sending IP involved.
2. Check that sending IP against the domain's current SPF record to see whether it's listed as authorised.
3. If it's a legitimate service, add the correct include/mechanism to the SPF record without breaking the 10-lookup limit.
4. If it's not a legitimate service, treat it as a sign of likely spoofing and check DMARC policy strength as the more relevant control.
5. If forwarding is involved, check whether the forwarding mechanism supports SRS (Sender Rewriting Scheme) to preserve SPF validity.
6. Republish the corrected record and confirm with a live test send that SPF now passes correctly.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

What does "SPF failed" actually mean?

It means the server that sent a message using your domain isn't listed as authorised in your domain's SPF record, so receiving mail servers can't confirm it was sent from somewhere you approved.

Does an SPF failure mean someone is spoofing my domain?

Not always — it's just as often a legitimate tool (a CRM, a forwarding address, a new sending platform) that simply hasn't been added to your SPF record yet.

Why does forwarding my email break SPF?

Forwarding resends the message from a different server than the original sender, and unless that forwarding service rewrites the sender address (via SRS) or is specifically authorised, SPF sees it as coming from an unapproved source.

Can I just add an include for Google (or similar) to fix any SPF failure?

Only if that service is actually the one sending the failing mail — adding random includes without checking the actual source doesn't fix anything and can push you over the 10-lookup limit.

What happens if I ignore an SPF failure?

Depending on your DMARC policy and the receiving server's own rules, the mail could still be delivered, sent to spam, or rejected outright — the risk increases the stricter your DMARC policy is set.

How do I know which service is causing my SPF failures?

The sending IP shown in the failure report or message headers can usually be matched to a specific provider by looking up who owns that IP range, which points straight to the service needing to be added.