Set up SPF without blocking legitimate email

What SPF checks

Publish one SPF policy for the actual envelope-sender domain only after listing every legitimate sending route.

SPF authorises hosts for the SMTP envelope domain, not the visible From address on its own. List hosted mail, forms, billing and marketing senders, then get each provider’s current instructions before changing the single policy. Do not publish an illustrative value.

Publish one policy at the sending domain

At the authoritative DNS provider, find any TXT record beginning v=spf1 for the exact sending domain.
Merge authorised mechanisms into a single record rather than adding a second SPF record. Remove obsolete senders only after confirming they no longer send.
Use the provider's recommended include: value where needed. A minimal illustrative shape is v=spf1 include:sender.example.test ~all; the example domain is a placeholder and must never be published unchanged.
Save, then run dig TXT example.com and inspect the final TXT string at the authoritative nameservers.

If SPF reports too many DNS lookups

RFC 7208 limits evaluation of the DNS-querying mechanisms and modifiers to ten. Count nested include, a, mx, exists, legacy ptr and redirect paths, not merely words in the top-level record. The ptr mechanism is discouraged by RFC 7208; do not introduce it into a new policy. Confirm the failure with a real recipient's Authentication-Results header and a trace of the evaluated path. Remove unused services or ask the sending provider for a supported narrower mechanism. Static IP lists need maintenance as providers change addresses; automatic flattening can silently become stale. Do not weaken the policy to +all.

Test and hand over

Send a message from each authorised source to a mailbox that shows full headers. Check spf=pass and whether the authenticated domain aligns with the visible From domain for DMARC. SPF alone does not guarantee inbox placement. If a service fails, retain its headers and provider documentation; the domain owner authorises DNS changes, while the sending provider controls its outbound hosts.

For a website form using the same hosted SMTP account as staff mail, test one form message first: the receiving header should show the hosted sender's envelope domain and SPF result before adding another mechanism.

Worked sender inventory

Suppose a domain sends through its hosting mail server and a separate newsletter platform. Make a table before writing TXT: hosting mail — provider-supplied SPF instruction; newsletter — its current authorised include; website form — identify whether it sends through the hosting SMTP server or a third service. If the form uses hosted SMTP, it may need no separate SPF mechanism. If the newsletter platform uses a different envelope domain, the policy to edit may be that domain rather than the visible From domain. Determine this from a real message header.

An illustrative shape is v=spf1 ip4:192.0.2.10 include:mail.example.test ~all. Both the TEST-NET address and example include are non-operational placeholders. ip4 authorises that address without a DNS-querying SPF mechanism; include evaluates another policy and can recurse. The ending ~all is a soft-fail policy, not permission for unlisted senders. Choose the final policy only after inventory and provider guidance.

Interpret the DNS and message results

Observation	Likely meaning	Next check
No SPF TXT at the queried name	Wrong domain or zone, or unpublished policy	Inspect the envelope sender domain and authoritative nameservers.
Two TXT values beginning v=spf1	Ambiguous policy and likely permanent error	Merge legitimate mechanisms into one policy.
spf=fail	The connecting host was not authorised by the evaluated policy	Check the sending IP, envelope domain and intended provider.
spf=permerror	Invalid policy, excess lookups or another permanent evaluation error	Read the receiver's detail and trace the chosen path.
spf=pass but dmarc=fail	The passing SPF domain may not align with From	Compare Return-Path and From; check DKIM as another alignment route.

Use dig TXT example.com +noall +answer for publication, then inspect a delivered message's Authentication-Results. DNS alone cannot prove that a particular sender passes.

Lookup-limit questions

Do ten include statements equal the limit? The limit is on DNS-querying terms encountered during one evaluation, including nested paths. A single include may expand to several terms.

Can I split SPF across two TXT records? No. For one name, publish one SPF policy; ordinary verification TXT records may coexist.

Will flattening always fix it? It can reduce live lookups but replaces provider-managed hostnames with addresses that may change. Keep ownership, update and monitoring arrangements explicit.

Does a passing SPF guarantee delivery? No. Alignment, DKIM, reputation, content and recipient policy still matter.

Can a DNS lookup alone show which provider sent a message? No. Use a real receiving header and the service owner's route information.

Sources and technical references

Prepared by Team Novasean from the references above. Menus and available features depend on your installed version and service permissions.

Related guides

Was this guide helpful?

If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .

Need help with your service?

Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.