Back to Blog

SPF Record Examples for Common Email Sending Setups

9 min read
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 -all

If 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 -all

Use 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 -all

This 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 -all

Use 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 -all

Keep 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

EndingMeaningUse with care
-allFail senders not matched by the recordAppropriate when the sender inventory is complete
~allSoftFail unmatched sendersUseful during migration when you need visibility without a hard failure
?allNeutralRarely useful as an operating policy
+allPass every senderDo 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.com

Then 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

  1. Inventory every service that sends mail for the domain.
  2. Confirm the envelope-from domain for each service.
  3. Collect the provider-documented include or sending IP.
  4. Merge into one SPF record.
  5. Count nested lookups.
  6. Publish and query the final TXT record.
  7. Send a test from each stream.
  8. 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.