Guide · Email
SPF: inventory every sending source
DNS does not know your organization. Before changing SPF, find every service that really sends with your domain, then decide how each one should authenticate.
Short answer
How do you inventory every source that sends email for your domain?
Start from business uses rather than the DNS record: employee mail, newsletters, website forms, billing, booking, recruiting, support, signatures and transactional systems. For each one, identify the provider, visible From domain, return-path domain and recommended SPF or DKIM setup.
Compare that inventory with DMARC reports and provider logs. Remove a source from SPF only after confirming it no longer sends. Maintain one SPF record per domain name and track the DNS lookup limit defined by the standard.
What SPF actually checks
SPF lets a domain owner publish which servers may send using that domain in the SMTP MAIL FROM or HELO identity. This technical identity can differ from the domain a person sees in the From field.
SPF does not sign message content and does not by itself prove that the visible message came from your organization. DMARC adds the alignment requirement with the visible domain.
Worth remembering
A positive SPF result for a provider’s domain only protects your domain when DMARC alignment is also satisfied.
Start with processes that send
Commonly missed sources
- Human mail Microsoft 365, Google Workspace or the hosting provider’s mail server.
- Website contact forms, password resets, orders and notifications.
- Marketing newsletters, automation and customer relationship platforms.
- Operations billing, quotes, electronic signatures, booking and support.
- People operations recruiting, payroll, benefits or surveys.
- Devices and legacy systems scanners, monitoring tools, internal applications and forgotten services.
Ask each owner what sends, how often and with which visible address. Monthly and annual flows are the ones a short sample misses most easily.
Read an SPF record without copying it blindly
A record starts with v=spf1. The ip4 and ip6 mechanisms authorize addresses; include delegates part of the decision to another domain; a and mx rely on other DNS records. The final all mechanism matches anything not already recognized.
Common qualifiers are - for Fail and ~ for Softfail. Choose between them after inventory and testing. Copying another organization’s record can authorize its vendors while omitting yours.
Technical detail
The standard also defines redirect to hand evaluation to another record. include and redirect are different: the former adds a mechanism; the latter replaces the rest of the evaluation when no earlier mechanism matches.
The DNS lookup limit is a design constraint
RFC 7208 limits the total number of terms that can cause DNS queries during one evaluation to ten. Nested include chains consume that budget too. Exceeding the limit can produce a permanent error instead of authorization.
Count the real dependency chain, not only the includes visible on the first line. Before flattening IP addresses, check the provider’s contract: its ranges may change, and a frozen copy quickly becomes wrong.
Worth remembering
Remove unnecessary sending sources before trying to compress the record.
Connect SPF to DMARC reports
Aggregate DMARC reports show which systems send and which SPF or DKIM domains they present. They help identify a forgotten legitimate service, an old vendor or a flow that passes SPF without aligning to the visible domain.
SPF can lose alignment during some forwarding because the MAIL FROM identity changes. DKIM then offers another alignment path if the signature remains valid. DMARC preparation examines both mechanisms instead of making SPF solve everything.
Change without interrupting legitimate mail
-
Capture the current state
record, available reports, known providers and owners.
-
Classify each source
active and legitimate, needs confirmation, old and removable, or unknown and requiring investigation.
-
Configure at the provider
follow its documentation for SPF and especially DKIM, using an aligned domain where possible.
-
Test a real flow
received message, authentication headers and DMARC report; one test does not cover rare mail.
-
Remove progressively
one source at a time, with an observation window and documented rollback.
Careful
Do not jump from ~all to -all while the inventory is incomplete. The qualifier does not discover missing sources; it makes their failures more explicit.
Errors that keep returning
Avoid
- Two SPF records selecting multiple records for one name produces a permanent error.
- Authorizing everything with +all this matches every source and removes SPF’s authorization value.
- Stacking includes without checking DNS lookups and services no longer needed.
- Forgetting the return-path domain which SPF evaluates instead of necessarily using the visible From field.
- Removing a rare flow too soon such as monthly billing, annual notices or account recovery.
Common questions
Can I have multiple SPF records?
Not for the same name. An evaluation that selects multiple SPF records produces a permanent error. Combine authorizations in one coherent record.
Do DMARC reports show every sending source?
They show flows observed by receivers that participate in reporting, not a guaranteed inventory of the organization. Compare them with process owners and provider logs.
Must SPF be complete before configuring DKIM?
No. Both can progress together. DMARC requires one aligned mechanism to pass, and DKIM is often the more stable path for third-party services.
Has your SPF record become unreadable?
A domain review can establish sources, DNS dependencies and the correction plan before any DMARC enforcement.
Have the domain reviewed Return to the DMARC guide