SPF Record Examples for Common Email Sending Setups

SPF (Sender Policy Framework) is a DNS policy that lists hosts authorized to use a domain in the SMTP envelope sender or HELO identity. It does not sign the message and it does not directly authenticate the visible From header.
The examples below show syntax. Replace every provider placeholder with the include value documented by that provider; do not invent an include domain from a blog post.
The one-record rule
Publish SPF as a TXT record at the domain that appears in the envelope-from identity. For a domain such as example.com:
Type: TXT
Name: @
Value: v=spf1 include:spf.example-sender.net -allIf two TXT values begin with v=spf1 at the same domain, receivers can return a permanent error. Merge the mechanisms into one record instead of adding a second SPF record.
Common setups
One email provider
v=spf1 include:spf.example-sender.net -allUse the provider’s exact include value. The provider may publish nested includes, so count the complete lookup chain rather than counting only the words in your record.
Two providers
v=spf1 include:spf.example-sender.net include:spf.example-crm.net -allThis is valid only if both includes are required and their nested DNS lookups remain within the limit.
Provider plus a fixed IPv4 sender
v=spf1 ip4:192.0.2.10 include:spf.example-sender.net -allUse an IP mechanism only for an IP address you actually control and that the provider says will send for this domain. Do not copy an example address into production.
Provider plus a fixed IPv4 range
v=spf1 ip4:192.0.2.0/24 include:spf.example-sender.net -allKeep the range as narrow as possible. Authorizing a broad network can authorize senders you did not intend to trust.
Separate policy record with redirect
Some organizations keep a shared policy at a dedicated SPF host:
example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 include:spf.example-sender.net -all"Use redirect only when you understand which domain owns the final policy and how its lookups are counted. For a small setup, a single readable record is easier to audit.
Choosing the final mechanism
| Ending | Meaning | Use with care |
|---|---|---|
| -all | Fail senders not matched by the record | Appropriate when the sender inventory is complete |
| ~all | SoftFail unmatched senders | Useful during migration when you need visibility without a hard failure |
| ?all | Neutral | Rarely useful as an operating policy |
| +all | Pass every sender | Do not use; it defeats the purpose of SPF |
Changing from ~all to -all is not a substitute for finding every legitimate sender. Inventory billing, support, CRM, website, and transactional providers first.
The ten-DNS-lookup limit
The SPF specification limits mechanisms and modifiers that cause DNS queries to ten during evaluation. Includes, a, mx, ptr, exists, and redirect consume this budget; ip4, ip6, and all do not. See RFC 7208.
Nested provider includes count too. A record with two visible include terms can still exceed the limit if each provider references several more domains.
Practical ways to stay within the limit:
- remove senders that no longer send;
- use the provider’s current consolidated include;
- avoid mx and a unless you actually need them;
- do not use ptr as a shortcut;
- use a dedicated SPF policy domain only with an understood lookup budget;
- validate after every provider change.
Verify what DNS returns
Query the domain:
dig +short TXT example.comThen use an SPF validator that expands includes and reports the lookup count. Finally, send a real message and inspect the SPF result in the headers. DNS visibility alone does not prove that the envelope-from domain used by the provider matches the record.
SPF and DMARC
SPF authenticates the envelope sender, while DMARC compares an authenticated SPF or DKIM domain with the visible From domain. A message can pass SPF and still fail DMARC alignment if those domains are unrelated.
If the provider uses a return-path such as bounce.example-sender.net while your visible From is news@example.com, configure custom return-path or aligned DKIM where the provider supports it. The actual message headers are the source of truth.
Migration checklist
- Inventory every service that sends mail for the domain.
- Confirm the envelope-from domain for each service.
- Collect the provider-documented include or sending IP.
- Merge into one SPF record.
- Count nested lookups.
- Publish and query the final TXT record.
- Send a test from each stream.
- Remove obsolete mechanisms after the old provider is no longer sending.
FAQ
Can SPF be a CNAME?
SPF policy is published as TXT. Some providers may use CNAME-based delegation for related authentication records, but follow that provider’s specific instructions and do not publish competing SPF records.
Does SPF protect the From address?
Not by itself. SPF evaluates the SMTP envelope identity. DMARC alignment, often through DKIM, is what connects authentication to the visible From domain.
Should I use a plus sign before include or ip4?
The pass qualifier is the default, so it is normally omitted. A record written with +include or +ip4 has the same positive qualifier but is less readable.
For syntax and qualifiers, see the SPF record format guide.