SPF is a TXT record that lists which servers are allowed to send email using your domain. A receiving mail server looks it up, checks the connecting server against the list, and decides whether the sender is legitimate.

Which domain SPF checks

SPF checks the domain in the SMTP envelope sender, the return address used during the mail transaction. That’s not always the same as the From: address a human sees in their inbox.

So an SPF pass alone doesn’t prove the visible sender is real. DMARC adds that alignment check. We’ll get there in the next lesson.

Read a policy

Here’s a typical SPF record:

v=spf1 ip4:192.0.2.0/24 include:_spf.mail-provider.test -all

Read it left to right. v=spf1 marks it as SPF. ip4:192.0.2.0/24 allows that address range. include: pulls in the policy your mail provider publishes. -all says everyone else fails.

The all qualifier matters. -all is a hard fail. ~all is a soft fail, which many providers suggest while you’re still finding all your senders. Copy your provider’s exact value and read their rollout advice before going strict on a production domain.

One record, always

This is the mistake I see most. You add a new email service, it tells you to “add this SPF record”, and you add a second v=spf1 TXT record next to the existing one.

Two SPF records don’t combine. They produce a permanent error, and your mail starts failing. Merge the new include: into the one existing record instead.

The ten-lookup limit

SPF evaluation may trigger at most ten DNS lookups. include, a, mx, redirect, and a few others each count, and includes nest. Your provider’s include may itself include three more domains.

A short-looking record can blow past ten once you expand everything. Then SPF fails for everyone. ip4: and ip6: mechanisms don’t count, so prefer them where you can.

What SPF can’t do

Forwarding breaks SPF. When someone forwards your mail, the connecting server is theirs, not yours, and it’s not in your list. Unless the forwarder rewrites the envelope sender, SPF fails.

SPF also says nothing about the message content. That’s DKIM’s job.

Audit your policy

Let’s look at what’s published:

dig TXT example.com +short

Find the one string starting with v=spf1. Expand every include: with more dig TXT queries and count the lookups as you go. Remove services you stopped using. And if a provider sends from a subdomain, query that subdomain’s TXT record too. It has its own policy.

Try this on a domain you manage: list every authorized sender, count the DNS lookups including nested includes, confirm there’s exactly one policy, and note the final all qualifier.

SPF records