DMARCIAN: Ending the SPF Flattening Experiment

SPF flattening is functionality meant to help deal with overly chunky SPF records that contain too many references to too many different service providers or IP addresses.

SPF flattening came about to be a solution a very specific problem: That a lot of senders utilize multiple service providers, utilizing business email platforms like Outlook 365 or Google Workspace, CRM tools like Salesforce, ESP tools like Mailchimp, and more. Each of these comes with guidance to add a specific "include" to an SPF authentication record, and if you add enough of these different "includes" from a multitude of providers, you end up with complex DNS records that take far too many DNS lookups to fully process, beyond what is allowed in the SPF specification

Dmarcian indicates that their "SPF Surveyor" was the first tool to help address this problem by reading your existing SPF record, and providing a new, smaller, "flattened" SPF record in response, to reduce the number of DNS lookups needed to fully process the record, to get around the "10 DNS lookup" limit inherent to the SPF specification. (Other tools offer this functionality, as well, such as autoSPF.) Flattening typically involves replacing "includes" with raw ranges of IP addresses, removing the references to specific services and other domains that must be queried via DNS to unpacked.

Well, times change and best practices changes, and DMARC tools/monitoring platform dmarcian just published their thoughts on why they will no longer provide an SPF flattening feature. It's a good overview of the limitations of SPF flattening, and how the "flattened" version of an SPF record can end up out of date over time, and how it isn't really best practice to implement SPF in this manner. If you're segmenting your use of different CRM and ESP tools by subdomain, and properly authenticating each of them, you probably don't need an overarching SPF record that encompasses every possible provider your use inside of one domain name's authentication record.

It seems like a valid point to me, though I do recognize that some companies, brands, or other email senders could be too small, having too little email volume to allow for subdomain segmentation between a multitude of service providers. Maybe SPF flattening is still going to be the best (or "least bad") choice in that edge case... and if so, it's good to know that others still provide that functionality. But it's also good to hear dmarcian explaining why they don't think this is a best practice and why it's not something they want to continue to facilitate.



  1. Thanks Al, yes, probably a better idea on that type of case, to rely on SPF macros to tackle that too many SPF reverses issue


Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.