SPF Flattening: What It Is & Why It Doesn’t Work

One of the biggest challenges organizations face in getting email authentication to enforcement involves Sender Policy Framework (SPF).

Here’s why: If you can’t identify all the senders who should be able to send email messages using your domain, and then use SPF to authorize them, you can’t move your DMARC policy to p=quarantine or p=reject.

Moving to enforcement without authorizing every service you actually use means that a few legitimate senders are going to get blocked. Solving this problem takes a lot of ingenuity due to limitations within the SPF standard.

When a domain name is listed in an SPF record, that tells receiving mail servers to go to the indicated address, where they will find additional rules: IP addresses, SPF macros, or additional domain names where more rules can be found.

For most services that send email on your behalf, you need to put something in SPF to specifically allow list that sender: Either its IP address(es) or an SPF “include” mechanism that indicates where receiving mail servers can find the appropriate rulesets.

SPF lets you put a large number of IP addresses in your SPF record, but it limits the number of domain lookups that receivers will do to just 10. That count includes domains explicitly listed in your SPF record and any domain lookups contained within the listed domains.

Many organizations turn to a quick-and-simple solution (SPF flattening), but it’s not as comprehensive or foolproof as it seems. Below, we’ll walk you through what SPF is, why SPF flattening doesn’t work, and a better (more reliable) solution you can trust.

What is SPF flattening?

SPF flattening is a technique that attempts to solve the SPF 10-lookup limit by manually expanding all the included domains in your SPF record into their component IP addresses.

Instead of using multiple “include:” statements that point to other domains (each counting as a lookup), you replace them with the actual IP addresses those domains authorize. The goal is to transform a nested, hierarchical SPF record into a “flat” list of IP addresses.

For example, rather than writing:

v=spf1 include:_spf.google.com include:mailchimp.com include:sendgrid.net -all

You’d expand each domain to list all their IPs directly:

v=spf1 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:205.201.128.0/20 ip4:198.2.128.0/24 [and many more] -all

In theory, this seems like a clever workaround to the 10-lookup limit. After all, listing IP addresses directly doesn’t consume any DNS lookups. But in practice, SPF flattening creates far more problems than it solves.

Most organizations attempt SPF flattening when they’ve run into the frustrating 10-lookup limit and need a quick fix. It seems straightforward at first—just replace domain references with their corresponding IP addresses. Unfortunately, this approach leads to a maintenance nightmare that gets worse over time, especially as your organization adds more cloud services.

The reality is that SPF flattening trades one problem (the lookup limit) for several bigger ones:

• Maintenance overhead
• Human error
• Reliability issues

Ultimately, these problems make SPF flattening a solution that ultimately doesn’t work.

SPF flattening doesn’t work

SPF flattening lets you do the lookups yourself, by hand, if necessary. Eventually, each of those lookups will (usually) lead you to a list of authorized IP addresses that you can place into your SPF record instead of referencing one or more domains for each service.

Sounds simple, right? Here’s where things can go badly wrong, though:

• Editing: Service providers frequently add and remove IP addresses from the list of sending IPs for their service.
• Errors: It’s easy to make errors (either in the IPs themselves or in the SPF syntax) when you’re building these long lists.  Are you sure you got that IPv6 address right?
• Multiple SPF records: Transforming that list of IP addresses and netblocks into an SPF record may require you to split it into multiple SPF records, linking them together…and possibly running into that 10-domain lookup limit all over again.
• IP address changes: Cloud service providers generally don’t notify their customers when they change the list of IP addresses from which they send email, so you’re going to have to track those changes yourself.

That means, if you’re the owner of a “flattened” SPF record, you now have the unenviable job of monitoring all the services in use, making sure that the list of IPs for each is still current, and that the overall list is complete.

And you did take notes when you were assembling the list, so you can tell which IP belongs to which service, right? Because you (or future IT admins) won’t be able to tell which is which just by looking at a long list of IPs.

Finally, humans tend to be really bad at managing lists of digits. Typos, transpositions, dropped periods, and other kinds of errors pop up all the same. For this reason, SPF flattening is fragile, brittle, error-prone, and winds up creating a significant maintenance overhead.

How to Avoid “Too Many DNS Lookups”

Instead of manually expanding SPF records and constantly monitoring for IP changes, automated SPF technology dynamically manages your SPF record in real-time. Here’s how it works:

1. Dynamic SPF Records: A specialized service hosts a DNS record that responds to SPF queries in real-time, calculating the authorized senders on demand.
2. Unlimited Service Integration: You can authorize as many cloud services as needed without worrying about the 10-lookup limit.
3. Real-Time IP Updates: The system automatically tracks IP address changes from all your service providers, eliminating manual maintenance.
4. Zero Maintenance: Once set up, the system works continuously without requiring constant monitoring or updates.

Automated solutions like Valimail Instant SPF® provide several advantages over manual SPF flattening:

• Set It and Forget It: No need to constantly monitor or update IP addresses.
• Future-Proof: Works with any new services you add without modification.
• Error-Free: Eliminates human error in managing complex IP lists.
• Standards Compliant: Fully compatible with the SPF specification and supported by all major mail providers.
• Scales with Your Business: No matter how many services you add, the system handles them automatically.

The alternative to SPF flattening: Valimail

Valimail’s solution is called Valimail Instant SPF®, and it solves the SPF 10-lookup limit without recourse to SPF flattening. Valimail Enforce includes the company’s unique, patented Instant SPF technology.

Valimail Instant SPF is the only automated SPF technology. Built on Valimail’s global, cloud-based infrastructure, it generates a tailored SPF record in milliseconds in response to each mail server request.

It’s scalable, fail-safe, and serves SPF records. Our approach is completely compliant with the SPF standard and is supported by every receiver that complies with the SPF specification, including all major ISPs and SEGs.

Instant SPF is just one feature you’ll have access to with Valimail Enforce. Our product will help you get to DMARC enforcement quickly and stay at continuous enforcement.