SPF Pitfalls: Clutter Clouds Your Security Footprint
SPF can be a powerful tool for securing an email domain, but it can be misunderstood. dmarcian Director of US Business Fred Bianchi talks about some common mistakes that result in clutter, leading to a less-than-secure SPF record.
As DMARC deployment specialists, we encounter a wide variety of organizations of different sizes and structures around the world. One thing that we’ve learned is that the quickest way to judge the state of an organization’s email health is to start at the SPF record. This is because SPF, in general, is mismanaged and the details are misunderstood.
It isn’t uncommon for an organization to have a superficial understanding of SPF, which can lead to unnecessary includes, or clutter, in their record. I’ve seen many organizations that have successfully deployed SPF, but moving forward, there isn’t a lot of consideration given when it comes to internal requests to add lookups to the SPF record.
As organizations organically grow, additional email sources sprout up sporadically. There may be long business cycles between deploying online invoicing to launching a newsletter. And then as services change, such as switching newsletter vendors, there often isn’t a formal internal “off-boarding” process that takes into account DNS hygiene. And even in organizations that do adopt a process moving forward, the existing lookups typically aren’t evaluated, so they remain in the record and unused.
The Dangers of SPF Clutter
SPF clutter can not only be includes for services that are no longer used, but also unnecessary top-level domain includes. Most understand that if an entity is sending on their behalf, it should be included in the SPF record. But it is all based on the return-path domain that is being used, as that is what is getting evaluated during SPF authentication.
Here’s an example: an organization is using SendGrid to send via a subdomain, like newsletter.domain.com, then we discover that SendGrid itself is in the SPF include statement on the top level domain (domain.com). In this case, including SendGrid in the SPF include statement on the top level domain isn’t necessary and contributes to SPF clutter and unneeded lookups.
Since SPF records are publicly visible, having an untidy SPF record communicates to the outside world that perhaps you don’t have visibility into how your email domains are being used. The more unused lookups and unnecessary top-level includes in an SPF record, the bigger an attack surface you could have. This is effectively authorizing thousands of IP addresses to send on behalf of that domain. It is the same as going to a hardware store and having a load of duplicate keys made for your house and then handing those out willy-nilly.
In information security, there is the idea of Principle of Least Privilege where a person or an application is granted only the bare minimum permission level needed to perform the task. When it comes to managing an SPF record, a similar consideration should be given to minimize exposure and opportunities for bad actors.
Clearing the Clutter
I think that SPF unfairly has a bad reputation because it is mismanaged. It’s hard to fault the organizations, because without using third-party tools, it is difficult to gain visibility on what elements of the SPF record are being actively used. Since the email is outbound, the only native option would be to check the email logs of the companies that you are sending to for validation—an impossible task at best. The addition of DMARC and the reports it generates provides insight into where a domain passes and fails SPF authentication across the internet. Third-party tools, like dmarcian, provide visualization and correlation to the raw data.
As I mentioned before, a DNS review that includes the SPF record should be part of an organization’s off-boarding process when it comes to ending a relationship with a vendor. If this policy isn’t currently in place, a full review of the SPF record should be conducted to make sure only active vendors are included.
Common SPF Mistakes
- Unnecessary top-level includes
As we mentioned above with the SendGrid example, unnecessary top-level domain includes are problematic. Although the return-path can reflect a top-level domain, that is pretty rare, as most ESP providers use subdomains for the return-path. And since we see it often, it is good to reiterate that the domain that gets evaluated for SPF authentication is the return-path (bounce) domain and not the from: domain. - Unneeded Gateway includes
When a secure gateway is being used to send and receive email, and there is an SPF include for Office 365 or Google G Suite, either one of those are open to hundreds of thousands of IPs. - Not understanding the DNS lookup limit, and how those lookups are calculated
SPF records have a hard limit of ten “lookups,” but how this limit is reached has been a source of misunderstanding in our experience.
IP addresses don’t count toward this lookup limit, but rather anything that needs to be “resolved” does. If an SPF record includes a domain which must then be resolved into an IP, then that does count. The inclusion of mechanisms such as “a” (for A records), “mx” (for mail exchanger records) and “ptr” (for pointer inquiries) also counts toward the lookup limit. You can find more information about SPF mechanisms here.
Another stumbling point is the concept of “nested includes” when an include statement (e.g., include:vendor.com) is expanded only to find that more include statements exist within it, similar to Matryoshka dolls (known more commonly as Russian nesting dolls). This can sometimes result in the discovery of other completely unrelated include statements or netblocks. This sort of scenario potentially, and possibly unknowingly, adds additional services and IP addresses to your SPF record.
An example of nested includes can be seen below in bluehost.com. If we run that domain through our SPF Surveyor, we see that it actually contains 13 unique lookups.
To inspect and verify your SPF records, head over to our complimentary SPF Surveyor.
We’re Here to Help
With a team of email security experts and a mission of making email and the internet more trustworthy through domain security, dmarcian is here to help assess an organization’s domain catalog and implement and manage DMARC for the long haul.
Want to continue the conversation? Head over to the dmarcian Forum.
