SPF (Sender Policy Framework)

`v=spf1 include:_spf.google.com include:sendgrid.net ~all` — version, then mechanisms, then the policy for everything not matched.

`include:` delegates to another domain's record. Each one costs a DNS lookup, and so does each lookup inside it.

`ip4:` and `ip6:` list addresses directly and cost no lookup. They are the way out of the lookup limit.

The final mechanism states the policy: `-all` hard fail, `~all` soft fail, `?all` neutral.

One record per domain. Two TXT records beginning `v=spf1` is a permanent error, and evaluation stops. It happens whenever a second service is added by pasting a second record instead of merging into the first.

Ten DNS lookups. The specification caps the number of lookups performed while evaluating a record. Exceeding it is a permanent error, and the mail fails as if SPF were absent. Four or five `include:` entries for common services are enough to reach it.

Both failures are silent from the sender's side: nothing in your own systems reports them.

`-all` asks receivers to reject mail from unlisted servers. Correct once you are confident the list is complete.

`~all` asks them to accept but mark it. The safe setting while you are still discovering which services send on your behalf.

In practice DMARC decides what happens to a failure, so `~all` with a DMARC policy is a common and defensible combination.

`dig example.com TXT +short` returns the TXT records; the SPF one begins `v=spf1`. More than one is the first thing to check.

Count the lookups: each `include:`, `a`, `mx`, `ptr` and `exists` costs one, recursively. This is tedious by hand, which is why it is worth automating.

SPF authenticates the envelope sender, not the From: header a recipient sees. That gap is precisely what DMARC exists to close.

The limit is reached faster than people expect. A mailbox provider, a marketing platform, a transactional sender and a helpdesk is four includes, and each may expand into several more internally — the count is recursive, not the number of entries you typed.

Flattening is the direct remedy: replace an `include:` with the `ip4:` and `ip6:` ranges it resolves to. It costs no lookups and it breaks the day the provider changes addresses without telling you, so it needs re-checking rather than setting once.

Removing senders is the better remedy where it is available. Services that no longer send mail for the domain are frequently still listed years later, and each is costing lookups for nothing.

Subdomains are the structural answer at scale: mail from a marketing platform can be sent from `news.example.com`, with its own SPF record and its own ten lookups, leaving the apex record short.

`ptr` deserves a specific mention: it is deprecated, slow, and treated as unreliable by receivers. If a record still contains it, removing it is free.