How to Build an SPF Record
Building an SPF record from scratch involves identifying every sender, adding the right mechanisms in the correct order, and staying under the DNS lookup limit. This guide walks through the steps: start with v=spf1, add one include or ip4 per sending service, avoid unnecessary mx or a mechanisms, and end with a clear qualifier. Rushing or copying without understanding leads to permerrors, duplicates, or missing senders.
One-Minute Fix
Start with v=spf1, add include: or ip4: for each sending provider, keep the total lookup count under ten, and end with ~all or -all.
# 1. Version
v=spf1
# 2. Add providers (one include each)
include:_spf.google.com include:sendgrid.net
# 3. End with qualifier
~all
# Result: v=spf1 include:_spf.google.com include:sendgrid.net ~allDo not add mx or a unless you specifically need them. Prefer provider includes over manual IPs when possible, and always verify the include hostname from the provider's docs.
Re-checkWrong vs correct setup
Building without planning
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:amazonses.com mx a ~allAdding mx and a on top of many includes can push the lookup count over ten. Build incrementally and count lookups before publishing.
Planned build
v=spf1 include:_spf.google.com include:sendgrid.net ~allOnly the services that actually send mail. No unnecessary mx or a. Stays under the lookup limit and remains maintainable.
Why a structured build matters
Teams often add mechanisms one by one without checking the total lookup count or removing obsolete senders. A deliberate build process reduces permerrors and keeps the record maintainable.
Why ad hoc building causes problems
- Accumulating includes can exceed the 10-lookup limit.
- Legacy senders left in the record create confusion.
- Redundant mx or a mechanisms add lookups without clear benefit.
- No single source of truth for which senders are authorised.
How a clean build helps deliverability
A lean, correct SPF record passes evaluation reliably. Overbuilt records risk permerror; underbuilt records fail for legitimate senders. A structured build balances both.
Common build mistakes
- Adding mechanisms without tracking lookup count.
- Keeping old provider includes after switching services.
- Using mx or a when include would suffice.
- Forgetting to add a new sender when onboarding a tool.
What we checked
We evaluate SPF records for structure, lookup depth, and completeness. We flag records that are likely to exceed limits or that omit common senders.
Live DNS lookup. No login. No saved domains. No tracking.
FAQ
How many includes can I add?
The limit is 10 DNS lookups total, not 10 includes. Each include can trigger multiple lookups. Count carefully when combining several providers.
Should I use ip4 or include?
Prefer include when the provider publishes one. Use ip4 only when you have a fixed, provider-documented range and no include is available.
When do I need mx or a?
Only when your mail actually comes from your domain's MX or A records. Many hosted setups use include instead; mx and a add lookups.
Next steps
- List every service that sends mail for your domain.
- Get the exact include hostname from each provider.
- Build the record: v=spf1 plus includes plus ~all or -all.
- Verify the lookup count stays under ten.
- Publish and re-check after propagation.
- Review the full troubleshooting guidance in the SPF Hub.
- Check signing and selector issues in the DKIM Hub.
- Review alignment and policy issues in the DMARC Hub.