Defaults.Exposed › Fixes › SPF (Sender Policy Framework)

How to fix SPF (Sender Policy Framework)

SPF is the line in your domain's settings that lists which mail services are allowed to send email as your business. Without it, anyone in the world can send email that looks like it came from you — and your own genuine email is more likely to land in customers' spam.

Bottom line for your business: Anyone can send email pretending to be your business — to your customers, staff, and suppliers — invoices, payment-change requests, the lot. At the same time your real quotes and invoices are more likely to be junked, so deals quietly stall.

What this can cost you

A scammer emails your customer an invoice 'from you' with their own bank details, and gets paid. You find out weeks later when the customer asks where their goods are — and now it's your reputation, and possibly your liability.
Your quotes, invoices, and replies quietly land in customers' spam folders because big providers can't verify they're really from you. Deals go cold and you never learn why.
A scammer impersonates your owner or finance person and emails staff asking for an urgent payment or gift cards — the message genuinely appears to come from your domain, so someone pays.
A larger prospect's IT or security review checks your domain, sees no sender protection, and either drops you or makes you fix it before they'll sign — costing you the deal or weeks of delay.
You think you're protected because an SPF record exists — but it's set to 'soft fail' with nothing enforcing it, or it's silently broken, so spoofed mail still sails through.

Why it matters. Faking the 'from' address on an email is trivially easy and costs an attacker nothing. SPF is the cheapest, fastest way to make your domain harder to impersonate and to keep your legitimate mail out of spam. Google and Yahoo now actively junk or reject mail from domains that aren't authenticated, so this is no longer optional — it's table stakes for getting your email delivered at all.

The short version

Right now, unless you have SPF set up correctly, anyone in the world can send email that appears to come from your business. They can email your customers fake invoices, email your staff fake payment requests, and email your suppliers as if they were you — and the messages will look genuine, because nothing on your domain says otherwise.

SPF (Sender Policy Framework) is the fix. It’s a single line of text in your domain’s settings that lists which mail services are actually allowed to send email as you. Receiving mail providers — Gmail, Outlook, everyone — check that list before deciding whether a message is real. No list, or a weak one, and they have nothing to go on.

This page covers two things that have to both be right: whether an SPF record exists at all, and whether it’s set strictly enough to actually do its job.

What this can cost you

These are the everyday, real-world ways a missing or weak SPF record turns into money and trust walking out the door. We never name a real business — these are the patterns we see across the data.

The invoice redirect. A criminal sends one of your customers an email that looks exactly like it came from you, attaching a real-looking invoice with their own bank account. Your customer pays it. The first you hear is a chaser asking where the order is. Now there’s an angry customer, a payment gone to a criminal, and a hard conversation about who eats the loss.
The CEO/finance scam. Someone emails your bookkeeper “from” the owner: “Quick favour — can you push this payment through before end of day?” Because the message genuinely appears to come from your domain, it doesn’t trip anyone’s instincts. Money leaves the building.
The silent deliverability tax. Your quotes and invoices start landing in customers’ spam folders because Gmail and Yahoo can’t verify they’re really from you. You don’t get a bounce, you don’t get an error — deals just go quiet. You’re losing business and you can’t even see it happening.
The lost contract. A bigger client’s procurement or security team runs a basic check on your domain as part of onboarding. They see no sender authentication and flag you as a risk. Best case, you scramble to fix it under deadline pressure; worst case, they go with a competitor who passed.
The brand-poisoning wave. Your domain gets used in a phishing campaign aimed at the public. People who got burned now distrust every email with your name on it — so even your genuine offers and renewals get ignored or reported.

The thread running through all of these: the attacker spends nothing, and your business carries the cost and the blame.

What it actually is

When an email arrives, the receiving mail server wants to know one thing: is this really from who it claims to be from? SPF answers part of that question.

You publish a short line of text in your domain’s DNS settings — a “TXT record” — that names the mail services allowed to send on your behalf. Something like:

v=spf1 include:_spf.google.com include:sendgrid.net -all

In plain terms, that reads: “Genuine mail from us comes from Google’s servers and SendGrid’s servers — reject anything else claiming to be us.”

The two parts that matter for your grade:

Does the record exist? This is the big one (it carries the most weight of any single email check). No record means receivers have no list to check against, so impersonation is wide open. There’s also a subtle failure mode here: if your domain has two or more SPF records, the rules say all of them are invalid — so you effectively have no SPF at all, even though it looks like you do.
Is the policy strict enough? A record can exist but still be toothless. The ending — the “all” mechanism — is the instruction to receivers:
- -all (hard fail) — reject anything not on the list. Strongest. Full marks.
- ~all (soft fail) + DMARC set to reject — the modern recommended setup. Equivalent protection to hard fail, without the risk of legitimate forwarded mail bouncing. Full marks.
- ~all + DMARC set to quarantine — acceptable, slightly weaker; move DMARC to reject for full protection.
- ~all on its own (no DMARC enforcement) — weak. This says “probably fake, deliver anyway.” Spoofed mail still gets through. This is the trap many businesses fall into thinking they’re protected.
- ?all (neutral) — provides no protection.
- +all — actively dangerous: it tells the world anyone may send as you. Never use this.

There’s one more invisible failure: SPF is only allowed to trigger up to 10 DNS lookups when it’s evaluated. Stack up too many include: entries and the record exceeds that limit, at which point receivers treat the whole thing as broken — and you’re back to no protection. This is a common, silent problem for businesses using lots of marketing and SaaS tools.

What “good” looks like: exactly one SPF record, listing every service that legitimately sends mail as you, ending in -all (or ~all paired with DMARC at p=reject), and staying comfortably under the 10-lookup limit.

How to fix it (free, ~10 minutes)

Hand this section to whoever manages your domain or website — and note that the fix is free. It’s a change to a DNS setting, not a product you buy. We only charge to monitor that it stays correct over time, not to make the change.

Step 1 — List every service that sends email as you. This is the part people get wrong. Write down all of them: your mailbox provider (Google Workspace, Microsoft 365, etc.), plus any newsletter tool, CRM, helpdesk, e-commerce platform, invoicing/accounting app, and booking system. If a service sends mail with your name on it and you forget it, your SPF will block its mail when you tighten the policy.

Step 2 — Publish one TXT record at your root domain. Combine the “include” lines for all your senders into a single record. Per common platform:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (or the region-appropriate domain)

A combined record looks like:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Where to add it, by provider:

Cloudflare: DNS → Records → Add record → Type TXT, Name @, Content = the value above.
Microsoft 365 / Google admin: they publish the exact include string to use in their setup wizard; copy it into your DNS host’s TXT record.
GoDaddy / Blacknight / most hosts: DNS management → Add → TXT, Host/Name @, Value = the record.

Step 3 — Start safe, then enforce. While you confirm your sender list is complete, publish with ~all (soft fail) so nothing legitimate gets blocked by accident. Once you’ve confirmed all your genuine mail still flows, tighten to -all (hard fail) — or, better, keep ~all and add a DMARC policy of p=reject, which is the recommended modern pairing.

Step 4 — Make sure you have exactly ONE record. If an old SPF record already exists, edit that one rather than adding a second. Two v=spf1 records cancel each other out and leave you unprotected.

Step 5 — Watch the lookup count. If you have many senders, you can blow past the 10-lookup limit. If that happens, consolidate — some providers offer “SPF flattening,” or drop senders you no longer use.

Step 6 — Re-check your domain to confirm it now passes, with the record present and the policy strict.

Common mistakes

Two SPF records. The most common silent failure. Adding a new record instead of editing the existing one invalidates both. There must be exactly one.
Stopping at ~all and assuming you’re done. Soft fail with no DMARC behind it is the weak middle ground — it looks configured but barely protects you. Either go to -all, or pair ~all with DMARC p=reject.
Forgetting a sender. Tightening to -all before listing your invoicing app, CRM, or newsletter tool will start blocking your own legitimate mail. List everything first.
Blowing the 10-lookup limit. Each include: can chain to more lookups. Too many and the record is treated as broken. Keep it lean.
Using +all. This explicitly authorises the entire internet to send as you. It’s worse than having no record. Never publish it.

Where this fits

SPF is the foundation, but it’s one of three layers. DKIM adds a cryptographic signature proving a message wasn’t tampered with, and DMARC is the instruction that ties SPF and DKIM together and tells receivers what to actually do with mail that fails — including blocking impersonation of the visible “from” name your customers see. Get SPF right first (it’s the fastest win and carries the most weight), then add DKIM and DMARC to fully close the door. All three fixes are free.

Set it up on your host

Step-by-step for popular providers:

FAQ

I'm not technical — can I deal with this myself?

You don't need to understand the details. The change is one or two lines added to your domain's settings, done by whoever manages your website or your IT provider. Hand them the 'How to fix it' section below — it usually takes a few minutes, and it's free. We only charge to monitor that it stays correct over time.

We already have an SPF record — doesn't that mean we're covered?

Not necessarily. Having a record is the first half; having it set strictly is the second. A record ending in '~all' (soft fail) with no DMARC behind it tells receiving servers 'this might be fake, but deliver it anyway' — which provides minimal protection. Two SPF records, or one that does too many lookups, is treated as broken and gives you no protection at all despite appearing to exist. Both halves have to be right.

Will fixing this accidentally break my own email?

It can if the record misses a legitimate sender — for example your invoicing app or newsletter tool that sends mail using your name. That's exactly why the safe approach is to list every service that sends mail as you first, publish with a soft '~all' while you confirm nothing is missed, then tighten to hard fail. Done in that order it won't break anything.

What's the difference between '~all' and '-all', and which should we use?

'-all' (hard fail) tells receivers to reject anything not on your list — the strongest setting. '~all' (soft fail) says 'probably not legitimate, but accept it anyway.' The modern best-practice recommendation is '~all' combined with a DMARC policy of 'reject' — that pair gives you the same protection as '-all' without the risk of forwarded mail bouncing. '~all' on its own, with no DMARC enforcing it, is the weak configuration to avoid.

Will SPF stop all email spoofing on its own?

No — it's the essential first layer, not the whole answer. SPF says which servers may send for you, but it doesn't tell receivers what to do when a message fails, and it doesn't cover the visible 'from' name a user sees. To fully lock impersonation down you also want DKIM and DMARC. SPF is the fastest, highest-impact first step, so start here, then add the other two.

How long until it takes effect, and could it cost anything?

DNS changes usually take effect within minutes to a few hours. The fix itself is always free — it's just editing a setting at your DNS provider. Anyone telling you it requires a paid product to add an SPF record is mistaken.