SPF Record Structure: The Architecture Decisions That Matter

Why SPF Record Structure is an Architecture Decision

Most SPF guides stop at syntax and skip the structural decisions that determine whether a record holds up at scale. Get the mechanisms right, publish the record, move on. That approach works for a single domain with two or three sending sources. It fails in every other scenario.

Enterprise environments typically run multiple sending systems: a primary server, a CRM, a marketing platform, a transactional service, and a finance system. Add regional infrastructure, and the SPF record structure decisions become a problem.

The SPF record structure determines:

1. How many DNS lookups it triggers on evaluation, and how close the record sits to the DNS lookup limit
2. Whether flattened IP ranges introduce drift as provider infrastructure changes
3. Whether include chains are auditable

These are SPF architecture decisions. Treating them as syntax is where the operational risk begins.

The DNS Lookup Limit: The Constraint That Shapes SPF Record Structure

RFC 7208 caps SPF evaluation at 10 DNS lookups. That limit includes every include, a, mx, and exists mechanism in the chain.

For a lean, single-platform setup, the DNS lookup limit is generous. For an enterprise with five or six SaaS senders, each carrying its own include chain, it’s easy to exceed.

Suppose you configure an SPF record for a mid-size organization:

This looks reasonable. Six include references, all legitimate senders. But each include points to a record that itself contains one or more lookups. By the time an evaluating server resolves this chain, you’ll have likely exceeded the DNS lookup limit, which means SPF returns a PermError.

The fix is not to remove senders. The fix is to restructure the SPF record structure to control lookup depth.

Option 1: IP Flattening

Replace include references with the resolved IP ranges:

ip4 and ip6 mechanisms don’t count toward the DNS lookup limit, so SPF flattening eliminates lookup depth entirely.

This SPF record structure choice carries a trade-off: when a provider rotates or expands its IP range, which Google, Salesforce, and major ESPs do, your flattened record becomes inaccurate. SPF authentication may fail for legitimate emails until you update the record manually.

Option 2: SPF Macros

MSPs and businesses managing multiple domains from shared infrastructure can use macros to construct SPF records dynamically. The %{d} macro resolves to the sending domain.

The -all vs. ~all SPF Qualifier Decision

The SPF qualifier at the end of an SPF record determines what happens when a source isn’t listed. -all returns a fail; ~all returns a softfail. Neither SPF qualifier is universally correct.

For companies that have a DMARC policy of p=reject or p=quarantine, the effect of the ~all vs. -all SPF qualifier is minimal. DMARC policy takes precedence.

For environments still building their sender inventory, ~all is the appropriate starting SPF qualifier. It avoids blocking messages from senders not yet identified, while DMARC reporting surfaces those sources for remediation. Once the sender inventory is complete and DMARC is at enforcement, tightening to -all is the operationally sound choice.

Common SPF Record Structure Mistakes

• Duplicate mechanisms: Listing the same include reference more than once wastes lookup budget and signals poor record hygiene during audits.
• Missing all qualifier: A record without a trailing all SPF qualifier defaults to neutral, which is functionally equivalent to no SPF policy.
• No change management process: SPF record updates are DNS changes. In environments with strict change windows, an undocumented SPF update (often made by a marketing or onboarding team) can break authentication for other senders.

How Sendmarc Helps

Managing SPF record structure across multiple domains and sending vendors is an ongoing operational task. Distributed environments make it difficult to see every sending source in one place, and stretched security and IT teams don’t have the capacity to trace lookup chains.

Sendmarc provides continuous visibility into your SPF record, surfacing unknown or unauthorized senders appearing in DMARC aggregate data before they become a compliance or deliverability problem.

Sendmarc’s DMARC Management extends this visibility beyond SPF into DKIM and DMARC authentication, with continuous monitoring and centralized reporting across every domain you manage.