SPF: stopping strangers sending email as your business

The short version

Why anyone can send email as you

The "From" address on an email is just text the sender types, like the return address on an envelope. The postal service does not check that you really live at the return address, and neither does the basic email system. This is why "spoofing" is trivial: the attacker's mail server simply states that the message is from accounts@yourbusiness.co.uk.

What makes this damaging is that your customers, suppliers and staff *trust* that address. The most expensive version is invoice fraud: a supplier of yours receives an email "from you" saying your bank details have changed, and pays the attacker. UK businesses lose tens of millions of pounds a year to exactly this.

Three DNS records, working together, fix it: SPF (which servers may send), DKIM (a cryptographic signature on each message) and DMARC (what to do when a message fails, and reports back to you). This guide covers SPF; DMARC and DKIM have their own.

What an SPF record is

It is a single TXT record on your domain that starts with v=spf1 and lists the servers permitted to send mail for you. When an email arrives claiming to be from your domain, the receiving server looks up that record and checks whether the server that actually sent the message is on the list.

A typical record for a business using Google Workspace for email and a newsletter tool looks like:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Reading it left to right: version 1 of SPF; Google's mail servers may send; Mailchimp's servers may send; and ~all — anything else should be treated as suspicious. Each include: pulls in the sending provider's own list of servers, so you do not have to maintain IP addresses yourself.

The parts that trip people up

• The ending matters. -all means "reject everything else" (strict). ~all means "mark everything else as suspicious" (soft fail), and is the usual choice because DMARC then decides the outcome. +all means "anyone may send" — it looks like a record but protects nothing, and we flag it as a finding.
• Only one record. If you have two TXT records starting with v=spf1, the whole thing is invalid and receivers ignore both. This is a very common mistake when a second provider's instructions say "add this record" and someone adds rather than merges.
• The ten-lookup limit. Each include: costs a DNS lookup, and SPF allows at most ten in total, counting nested ones. Go over and the record fails. Sites that have accumulated years of providers — CRM, helpdesk, newsletter, invoicing, website forms — often hit this. The fix is to remove providers you no longer use, or use a flattening service.
• Every sender must be listed. Your website's contact form, your invoicing software, your CRM, your helpdesk — if any of them sends mail "from" your domain and is not in the record, those messages will fail SPF and may bounce or land in spam.
• It covers the domain, not the display name. SPF checks the technical "envelope sender", which is why DMARC is needed to tie it to the address people actually see.

How to set one up

List every service that sends email on your behalf. Then find each one's SPF include — every provider documents it (search "*provider name* SPF record"). Common ones:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• cPanel shared hosting: usually include: your host's name, or a mx to allow the hosting server itself (your host's SPF page will say)
• Mailchimp: include:servers.mcsv.net
• SendGrid: include:sendgrid.net

Combine them into one record, ending in ~all, and add it as a TXT record on your root domain (@) in your DNS provider — Cloudflare, Spaceship, 123-reg, GoDaddy, wherever your nameservers are. Delete any older v=spf1 record rather than adding a second. Changes take from a few minutes to an hour to be visible.

What VigilScan checks

We look up the TXT records on your domain and report whether a valid v=spf1 record exists, whether there is more than one, what the all mechanism is set to, and roughly how many lookups it uses. We query via two independent DNS resolvers, so a result reflects what the wider internet sees rather than what one server has cached.

Common questions