SPF Record Creation: A Playbook for Enterprise Teams

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:

Breaking that down:

• v=spf1 – Required version tag, always first
• ip4:203.0.113.10 – Explicitly authorizes a single IPv4 address
• include:spf.protection.outlook.com – Points to Microsoft’s SPF record
• include: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:

1. Microsoft 365 or Google Workspace (1-2 lookups)
2. A marketing automation platform (1 lookup)
3. A CRM (1 lookup)
4. A transactional email provider (1 lookup)
5. An HR platform (1 lookup)
6. An on-premises server (1 lookup)
7. A ticketing or support platform (1 lookup)
8. 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:

1. Regional or product subdomains used by marketing or transactional systems
2. 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

1. Quarterly: Full sender inventory review against the published SPF record
2. On-demand: Any new vendor, SaaS tool, or infrastructure change that affects outbound email
3. 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 ~all or weaker on a domain that processes finance or HR communications
• A department is onboarding a third-party sender that can’t provide SPF include details 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.