28 Jul 20268 minutes read
Waseem OsmanDMARC EnthusiastSPF Record Creation: A Playbook for Enterprise Teams
SPF record creation overview:
- SPF record creation is a one-time task, but keeping the record accurate is ongoing.
- The
-allqualifier is the correct default for production domains;~allbelongs in testing or rollout phases. - Enterprise sender stacks often hit the 10-lookup limit with fewer senders than expected.
- IP flattening removes lookup overhead but requires automated monitoring to stay accurate as vendor IPs change.
- Subdomains don’t inherit the parent domain’s SPF record, so each one needs an explicit policy.
An incorrectly deployed SPF record can either block legitimate emails or leave you vulnerable to spoofing. Catching the difference before it affects you takes more than a syntax check.
In large organizations, SPF failures tend to surface quietly: A vendor’s transactional emails start bouncing, or a regional business unit’s campaign lands in Spam.
The misconfiguration happened weeks earlier, buried in a change that looked routine at the time. Deploying a record correctly is only step one. What follows, keeping it accurate as vendors and infrastructure change, is the real challenge.
This post covers SPF record creation, real DNS constraints, subdomain policy, and the governance structure needed to keep SPF functional over time.
Sendmarc’s DMARC Management gives distributed teams a single view of every SPF record, subdomain, and sender across the company, so gaps don’t surface only after messages fail to deliver.
SPF Record Creation Basics: Syntax and Structure
An SPF record is a DNS TXT record published at your root domain (or subdomain). It tells receiving servers which IP addresses and sending services are authorized to send on your domain’s behalf.
The basic syntax:
| Host | Type | Value |
|---|---|---|
@ | TXT | v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:sendgrid.net -all |
Breaking that down:
v=spf1– Required version tag, always firstip4:203.0.113.10– Explicitly authorizes a single IPv4 addressinclude:spf.protection.outlook.com– Points to Microsoft’s SPF recordinclude:sendgrid.net– Delegates to a third-party sender-all– Hard fail: Blocks any source not listed
The -all qualifier is the right default for production domains. The alternative, ~all (softfail), still permits delivery and is only appropriate during initial deployment or testing phases. Using ?all (neutral) or +all (pass) provides no protection and shouldn’t appear in production records.
Where SPF Record Creation Breaks at Scale: The 10-Lookup Limit
RFC 7208 imposes a hard limit of 10 DNS lookups per SPF evaluation. Each include, a, mx, and exists mechanism counts toward that limit, and so do nested lookups. ip4 and ip6 mechanisms don’t trigger lookups, which is why direct IP authorization is preferable.
In practice, enterprise SPF records exceed the 10-lookup limit more often than most teams realize. A typical enterprise sender stack might include:
- Microsoft 365 or Google Workspace (1-2 lookups)
- A marketing automation platform (1 lookup)
- A CRM (1 lookup)
- A transactional email provider (1 lookup)
- An HR platform (1 lookup)
- An on-premises server (1 lookup)
- A ticketing or support platform (1 lookup)
- A finance system (1 lookup)
That is already eight lookups before accounting for nested includes. Once you add a new SaaS tool during a procurement cycle, you’re probably over the limit. Receiving servers will return a PermError, which typically results in the message being rejected outright.
The most reliable mitigation is IP flattening: Resolve all include chains to their IP addresses. This eliminates lookup overhead.
The tradeoff is a maintenance burden. When a vendor changes their sending IPs, which they do, often without notice, your record becomes stale. Automated SPF management tools monitor for these changes and update your record accordingly, which removes the operational cost of manual flattening.
SPF Record Creation for Subdomains
Subdomains don’t inherit the SPF record from the parent domain. A record at yourdomain.com provides no SPF coverage for mail.yourdomain.com or regional.yourdomain.com. Effective SPF record creation treats every subdomain as a separate policy decision.
Enterprise environments commonly have:
- Regional or product subdomains used by marketing or transactional systems
- Acquired domains operating under a subsidiary subdomain
Subdomains with no legitimate sending purpose should publish a hard fail record:
v=spf1 -all
This is a deliberate signal to receiving servers that nothing is authorized to send from that subdomain. It closes a common attack vector where adversaries use unprotected subdomains for spoofing.
For subdomains that do send email, publish explicit records that include only the systems that actually use them.
Governance Checklist for SPF Record Creation and Maintenance
SPF record creation is a one-time task, but keeping that record accurate is not, and it affects more than the DNS team. It spans IT operations, security, and compliance. The checklist below defines who owns what, when to escalate, and what records to maintain.
Ownership
- DNS team owns record publication and change execution
- IT operations owns the sender inventory and coordinates vendor onboarding
- Security or compliance owns the audit trail and periodic review cycle
- Department leads own approval for their team’s third-party senders
Review cadence
- Quarterly: Full sender inventory review against the published SPF record
- On-demand: Any new vendor, SaaS tool, or infrastructure change that affects outbound email
- Post-incident: Any SPF failure that caused production email disruption
Escalate to a CISO when:
- A sender not in the inventory is actively sending emails from your domain
- SPF enforcement is at
~allor weaker on a domain that processes finance or HR communications - A department is onboarding a third-party sender that can’t provide SPF
includedetails or a fixed IP range - An acquired subsidiary’s domain is sending messages with no SPF record
- The 10-lookup limit is consistently exceeded, and no flattening solution is in place
Compliance records to maintain:
- DNS change log with timestamps, approver, and before and after record state
- Sender inventory with owner and last-reviewed date
- Incident log for SPF failures, including root cause and resolution
How Sendmarc Helps
Maintaining SPF records manually across multiple domains and dozens of senders is operationally expensive. Most stretched IT and security teams can’t sustain it without added headcount.
Sendmarc automates the parts of SPF record creation and maintenance that create the most risk. The platform surfaces authorized and unauthorized sources sending on your domain, keeps lookup counts within RFC limits as vendor infrastructure changes, and produces the audit trail that compliance teams, audit committees, and boards require.
For organizations managing SPF across subsidiaries, acquired domains, or complex environments, Sendmarc provides centralized visibility and governance without requiring every business unit to coordinate through a single DNS team.
