What this analysis does
Select sending platforms such as Google Workspace, Microsoft 365, SES or SendGrid, add your own IP ranges and includes, and pick the default qualifier. The generated record is resolved the way a receiver resolves it, so the DNS lookup count, void lookups and length problems are visible before the record ever reaches production DNS.
Writing an SPF record by hand is easy; writing one that stays under the evaluation limit is not, because each platform include expands into further lookups you cannot see in the text. The generator assembles the record and resolves it recursively so the real lookup count is known before anything is published.
List every platform that sends as the domain
SPF authorizes the sources allowed to use the domain as the envelope sender. Every platform that sends on the domain’s behalf — mailbox suite, marketing tool, transactional service, helpdesk, CRM — needs to be listed, or its mail fails SPF. The generator carries the current include mechanism for the common platforms; anything else can be added as a custom include or a literal address range.
Do not add mechanisms speculatively. The a and mx mechanisms are frequently included by habit and authorize the web server and inbound mail hosts to send mail, which is rarely intended and consumes lookup budget for nothing.
- Each include costs at least one DNS lookup, often several.
- a and mx are usually unnecessary and cost lookups.
- Literal ip4 and ip6 mechanisms cost no lookups.
The record is resolved before you copy it
RFC 7208 limits an evaluation to ten DNS-querying mechanisms. Because includes nest, a record with three includes can expand to a dozen queries. The generator resolves each include the way a receiver does and reports the total, the remaining headroom and any include that returned nothing.
A void result usually means a retired vendor hostname. Two void lookups produce PermError under the specification, so the generator reports them separately rather than folding them into the count.
Inspect the full dependency tree of the generated recordRead the lookup pressure guide
Choose the qualifier deliberately
The final mechanism decides what receivers do with unlisted sources. ~all asks them to accept but mark; -all asks them to treat the source as unauthenticated; ?all provides no protection at all. Use ~all while the sender inventory is being confirmed, then move to -all.
For a domain that sends no mail, the correct record is v=spf1 -all with nothing else. The generator produces it when no sources are selected and hard fail is chosen.
Compare the proposal against the live recordConfirm the sender inventory first
Example: a record that would exceed the limit
Evidence supplied
Google Workspace, Microsoft 365, SendGrid, Mailchimp, Zendesk and Salesforce selected, plus mx.
How to read the result
Recursive resolution reports a lookup count above ten. The generator marks the record as producing PermError and points at the largest contributors, so platforms that no longer send can be removed before publishing.
Known limits
- Platform includes reflect vendor documentation at review time; vendors change them and the live resolution is authoritative.
- Lookup counts are computed from DNS at generation time and can change as vendor records expand.
- SPF authorizes the envelope sender only; DMARC alignment with the visible From domain is a separate question.
Common questions
Why is my count higher than the number of includes?
Includes nest. Each platform’s own SPF record can contain further includes, and all of them count toward the same ten-lookup budget.
Should I flatten the record to IP addresses?
Only as a maintained process. Flattening removes vendor-managed updates, so the ranges must be refreshed whenever a platform changes infrastructure.
Can I have more than one SPF record?
No. Multiple SPF records are an error and receivers may treat the domain as having no valid policy. Merge everything into one.