SPF record: one record, ten lookups, and the senders you forgot

An SPF record is a TXT record in your domain’s DNS listing the servers permitted to send mail on its behalf. A receiving server checks the sending IP against that list and gets a pass, a fail, or a soft fail. It is the simplest of the email authentication mechanisms and the one most often quietly broken.

Two rules cause most problems. A domain must publish exactly one SPF record — two records mean the check fails outright, not that the lists are merged. And evaluating the record must not require more than ten DNS lookups; exceeding that produces a permanent error, and each `include:` for a sending platform can consume several.

What an SPF record looks like

• It starts with the version tag, and ends with an all mechanism that decides the default.
• `include:` delegates to a provider’s own record — your mail host, marketing platform, ticketing system.
• `ip4:` and `ip6:` list your own sending servers directly, and cost no lookups.
• `-all` means anything not listed fails; `~all` means soft fail, treated as suspicious rather than rejected.
• `+all` permits everything and should never be published.
• It says nothing about what receivers should do on failure — that decision belongs to the dmarc policy.

The choice between `-all` and `~all` matters less than it used to, because DMARC decides the outcome, but `-all` remains the correct end state once you are confident the list is complete.

Staying under ten lookups

1. Inventory every system that sends as your domain — the list is always longer than the first draft.
2. Count the lookups: each include, a, mx, ptr and exists mechanism counts, and includes nest.
3. Replace an include with explicit ip4 entries where the provider publishes stable addresses.
4. Remove providers you no longer use — old marketing platforms are the usual dead weight.
5. Use a subdomain for bulk sending, with its own SPF record, so the main domain stays lean.
6. Re-check after any change of provider, and treat the record as configuration rather than a one-off.

SPF breaks on forwarding by design: the forwarding server is not in your record, so the check fails at the destination. This is not a fault to fix in SPF — it is why DKIM exists, and why DMARC alignment should rest primarily on DKIM. An email bounce caused by forwarding is the usual way this surfaces.

Where the record actually lives

SPF is DNS, not mail. It is published as a TXT record on the domain, propagates on DNS timescales, and is edited wherever the domain’s zone is managed — which in many companies is neither the person who runs the mail platform nor the one who noticed the problem. Knowing who holds the zone is half of fixing it quickly.

Ettex Sites manages the domain and its DNS records alongside the site, so the TXT record, the MX records and the mail configuration are edited in one place rather than across three logins. What the record cannot do is authorise mail you have not listed, and where a provider is missing, the fix is the inventory rather than a wider policy.