SPF explained for small businesses.

What does it do?

An SPF record is a single line of text published in DNS at the apex of your domain. It lists the IP addresses, hostnames and third-party services authorised to send mail using your domain in the envelope sender. When a receiving server gets a message, it looks up your SPF record and checks the connecting server's IP against that list. If the IP is on the list, the message passes SPF. If not, it fails, and the receiver applies whatever your DMARC policy says.

SPF records use a small DSL of mechanisms and qualifiers. include:_spf.google.commeans "import whatever IPs Google publishes for its mail servers". ip4:203.0.113.10means "allow exactly this IP". mxmeans "allow whatever IP the domain's MX records resolve to". Mechanisms are evaluated left to right and the first match wins, with the final all mechanism deciding what to do with everything else.

SPF on its own does not block much. The crucial detail is that SPF checks the envelope return-path, not the human-visible From line. Anyone running their own SMTP server can write any From they like. Where SPF really earns its place is as one of the two authentication results DMARC reads when deciding whether a message is genuinely you.

Why it matters

Imagine a Melbourne accounting firm with seventy clients. Their domain has no SPF record at all. A phishing crew registers a cheap VPS, sends a tax-deadline reminder that displays partners@yourfirm.com.auas the sender, and routes recipients to a fake portal. Half the firm's receiving clients are on Gmail, which downgrades the message slightly but still delivers it. Eight clients submit payroll credentials. The clean-up takes a fortnight, the cyber insurer asks why SPF was missing in the first place, and the firm spends the next renewal cycle paying a higher premium. A single SPF record would not have stopped every attempt, but it would have stopped this one.

SPF also matters for deliverability, not just defence. Major receivers like Gmail and Yahoo treat unauthenticated mail as a spam signal. If your domain has no SPF, your legitimate invoices, newsletters and quotes get a deliverability penalty that quietly suppresses replies. Most owners blame the recipient for "not seeing the email". The actual cause is often a missing or broken SPF record.

How to set it up

Most small businesses have three or four senders: their inbox provider (Google Workspace or Microsoft 365), an invoicing tool (Xero, MYOB), a newsletter platform (Mailchimp, ActiveCampaign), and a transactional service (Stripe, SendGrid). Each one publishes its own include: directive that you reference.

• A complete record for a Google Workspace customer that also sends from Xero and Mailchimp:

yourdomain.com.au.  TXT  "v=spf1 include:_spf.google.com include:_spf.mcsv.net include:eu._spf.xero.com -all"

• One record per domain. Multiple SPF TXT records on the same name is a permerror.
• Add new senders by editing the existing record, not by publishing a new one.
• Keep the lookup count under ten. Flatten includes if you outgrow the limit.
• End with -all once you are confident in the list.

To test, use any free SPF lookup tool and confirm the result shows pass for your provider's sending IPs. Send a message to a Gmail address you control and look at the authentication-results header: it should say spf=pass with your domain. If you see spf=permerror, you are over the lookup budget. If you see spf=neutral, your record ends with ?all and is not enforcing anything.

Common mistakes

• Multiple SPF records on the same name. Merge them or delete the older one.
• Going over ten DNS lookups. Common with stacks that include Microsoft 365, a marketing platform, and a CRM.
• Leaving ~all in place forever. It is a halfway signal, not a defence.
• Forgetting that SPF alone does not protect the visible From address. SPF without DMARC is half a fence.

How AttackEdge checks it

The AttackEdge scan reads your SPF record on every scan. It flags missing records, multiple records, lookup overflow, soft-fail endings, and unused includes left over from former tools. The full methodology is on /what-we-check, and the free DMARC checker covers SPF in the same pass.