Enterprise SPF Configuration: Building Records That Hold Up at Scale

Four Realistic SPF Record Examples

The right SPF configuration depends entirely on how your organization sends email. These four SPF record examples cover the most common ways enterprises structure their records.

Example 1: Single-Vendor Setup

Lookup count: 1 direct lookup, typically 2 to 3 total once Google’s own lookups are included.

Maintenance burden: Low.

Risk: Minimal. The main concern is the ~all qualifier. Softfail doesn’t block unauthorized senders; it flags them.

Use -all (hardfail) on production domains where you have high confidence in your sender inventory.

Example 2: Multi-Vendor SaaS Stack

Lookup count: About 8 to 12, depending on how each vendor sets up their record.

Maintenance burden: Moderate to high. Each vendor controls their own SPF infrastructure. When they rotate IPs or restructure their records, your lookup count changes without any action on your part.

Risk: This SPF configuration is close to the limit. Adding one more SaaS integration (a new support tool, a transactional email platform, a partner notification service) can push it into PermError territory.

For companies sending from this many sources, flattening is worth considering. SPF flattening replaces include references with the resolved IP addresses directly, removing DNS lookups at the cost of higher maintenance.

Example 3: Hybrid On-Premises and SaaS

Lookup count: 2 to 5 (the ip4 entries don’t count).

Maintenance burden: Low to moderate. The on-premises IP entries are stable as long as your infrastructure doesn’t change. The include entries carry the same vendor-dependency risk as the previous example, but the lower count gives you headroom.

Risk: The primary risk here is infrastructure drift. If your on-premises IP changes and nobody updates the SPF record to match, every message from that IP will fail SPF.

Using -all here is appropriate.

Example 4: MSP Multi-Tenant Architecture

MSPs face a structurally different problem. They often manage SPF configuration on behalf of dozens or hundreds of client domains, each with different sending stacks.

This is a per-client record, not a shared one. The MSP owns the DNS management layer; each client has an individual record.

The requirement for MSPs: A documented sender inventory per client, a clear process for adding new include entries, and a monitoring workflow that alerts you when any client domain approaches the lookup limit or starts generating SPF failures. Manual processes at this scale aren’t sustainable.

Auditing an Existing SPF Record

Auditing comes before any enterprise SPF configuration update. Before making changes, understand what you have. Use a dedicated SPF record checker to get the record.

Once you have the record:

1. Confirm which include entries are active vendors still sending on your behalf
2. Identify entries added for vendors you no longer use
3. Check for ip4 entries pointing to decommissioned infrastructure
4. Calculate the total DNS lookup count
5. Confirm the final qualifier is -all, ~all, or something weaker

Stale entries are common and dangerous. An include reference to a vendor you no longer use doesn’t break authentication, but it consumes a lookup slot and may reference IP ranges that could be reassigned to another party. That is a small but real spoofing surface.

The Operational Risk of SPF Misconfiguration

The operational consequences of SPF failures are broad:

• Rejection of critical email. An unauthenticated finance notification, compliance alert, or contract communication doesn’t land in Spam; it disappears entirely.
• BEC exposure. ~all and +all qualifiers let spoofed emails pass SPF. A tightly scoped record with -all closes that gap.
• Compliance gaps. Frameworks that require appropriate technical safeguards for email expect organizations to have functioning SPF, DKIM, and DMARC configurations. A misconfigured SPF record is a documented gap.

How Sendmarc Helps with Enterprise SPF Configuration

Enterprise SPF configuration rarely stays simple. New vendors, acquired subsidiaries, and distributed departments all add senders faster than most teams can track manually, which is exactly where visibility gaps and unauthenticated senders start to accumulate.

Sendmarc gives operations, security, and compliance teams unified visibility into every SPF, DKIM, and DMARC configuration across the domain portfolio, so unapproved SaaS tools and unknown senders surface before they break authentication.

Sendmarc turns DMARC aggregate report data into a clear breakdown of which sources are failing, which domains are affected, and what the authentication results look like across the sending infrastructure. 

Explore the Sendmarc Platform