Setup guide

How to Set Up SPF — SPF Record Setup Without Permerrors

How to set up an SPF record: inventory senders, publish one TXT, avoid SPF permerror (too many DNS lookups), and verify with real mail. Copy-paste examples for yourdomain.co.za.

This guide covers how to set up SPF (Sender Policy Framework) so receivers know which servers may send mail for your domain. You will build a sender inventory, publish a single DNS TXT record, stay under the hard 10-lookup limit, and verify that legitimate platforms still pass — without silent permerrors that break delivery.

SPF alone does not stop all spoofing and does not survive many forwards. Pair it with DKIM and then DMARC for domain-level policy and reporting.

What SPF does

SPF (RFC 7208) is a DNS TXT record, usually on the apex of your domain, that lists which IPs and services may use your domain in the SMTP envelope (MAIL FROM / return-path). Receivers look up that record and check the connecting IP against the authorised set. Results include pass, fail, softfail, neutral, and permanent error (permerror).

1. Inventory every sender for your domain

Write down every platform that sends as you before you edit DNS. Typical list for a small or mid-size business:

Microsoft 365 / Google Workspace / hosted Exchange
Marketing or newsletter tools
Helpdesk, CRM, billing, HR, and security alert systems
Transactional SaaS (password resets, invoices, shipping, booking)
Any on-prem or cloud MTA that still injects mail for the brand domain

Each vendor documents an SPF include: (or IP / a / mx mechanisms). Missing one is the usual reason legitimate mail fails after you tighten DMARC. Keep the inventory in a ticket or sheet so the next SaaS does not get added “by DNS folklore.”

2. Publish a single SPF TXT record

Use one TXT record on the apex (or the exact sending domain). Multiple SPF TXT records on the same name cause evaluation failures. If an old hoster left a second v=spf1 string, remove or merge it.

Host: yourdomain.co.za (apex / @)
Type: TXT
Value: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

That example is illustrative — only include the services you actually use. A Microsoft 365–only domain might look like:

v=spf1 include:spf.protection.outlook.com ~all

Start with v=spf1 (required)
Add each vendor include: only once, in the form the vendor documents
End with ~all (soft fail) while learning, then move toward -all when the inventory is complete and verified
Do not paste two full SPF records into one string without merging mechanisms carefully

Prefer vendor include: mechanisms over hand-maintained IP lists. Vendor infrastructure changes; their include is their contract with you.

3. Stay under the 10 DNS lookup limit

SPF counts DNS lookups across include, a, mx, redirect, exists, and similar mechanisms — including nested lookups inside vendor includes. More than 10 produces a permerror: receivers may treat SPF as failed even for legitimate mail, which then hurts DMARC if DKIM is not aligned.

If you are close to or over the limit:

Remove unused or duplicate includes (old ESPs, decommissioned tools)
Prefer the vendor’s recommended single include over stacking several IP mechanisms
Avoid deep include chains and “include everything just in case”
Treat aggressive flattening (expanding includes into raw IPs) as a last resort — flattened records go stale when the vendor changes infrastructure

Deep dive: how to fix an SPF permerror without breaking mail.

4. Verify with checks and real mail

Run the SPF check on free tools and confirm a single record and a sensible all mechanism
Send a real message from each platform on the inventory and inspect Authentication-Results (or DMARC reports once DMARC is on)
Confirm DKIM is enabled so DMARC can still pass when SPF fails on forwarders
Only then tighten ~all to -all if your risk model and inventory support it

When a new SaaS starts sending, add it to the inventory first — see the new SaaS sender onboarding checklist.

Common mistakes and troubleshooting

Two SPF TXT records — merge into one v=spf1 … string; delete the duplicate.
Lookup count over 10 — permerror; clean includes before adding another ESP.
Syntax typos — missing v=spf1, spaces inside mechanisms, or quotes mishandled by the DNS UI can invalidate the record.
Authorising the wrong name — SPF on the apex does not automatically cover a separate marketing subdomain that uses its own From / return-path domain.
Jumping to -all with a half inventory — hard-fails forgotten tools; use softfail until verified.
Flatten once and forget — vendor IP ranges change; without maintenance you fail legitimate mail later.
Expecting SPF to survive all forwards — many list and forward paths rewrite the connecting IP; rely on DKIM + DMARC for those cases.

FAQ

Where do I publish the SPF record?

Almost always as a TXT record on the organisational domain apex (e.g. yourdomain.co.za). Some tools send from a subdomain; that subdomain needs its own SPF if it appears in the envelope domain receivers check.

What is the difference between ~all and -all?

~all (softfail) signals “not authorised, but treat gently.” -all (fail) is a hard unauthorised result. Start with softfail until the inventory is proven; many mature domains run -all once SPF and DKIM are solid and DMARC reporting is in place.

Why does SPF pass but DMARC still fail?

DMARC requires alignment: the domain that passed SPF or DKIM must match (or be a parent of) the visible From domain under relaxed or strict rules. Passing SPF for an unrelated vendor return-path does not satisfy DMARC for your brand From address.

Do I need SPF if I have DKIM?

Yes for a complete posture. Many receivers and DMARC deployments still use SPF; some mail paths only have one check working. Publish both, then DMARC.

How do I fix SPF without breaking mail tomorrow morning?

Prefer additive, reversible changes: remove only proven-dead includes, keep softfail until tests pass, and never delete a high-volume include without a report or header sample showing it is unused. The permerror article above walks a safe cleanup sequence.