SPF Best Practices: Avoiding SPF Record Flattening

Why Is SPF Flattening Relevant?

SPF has a limit of 10 DNS Lookups; any mechanism (entry) requiring a lookup after the lookup limit will not be evaluated and will fail authentication. In some cases, people turn to SPF flattening tools to work around the 10 DNS lookup limit. When you add a new mechanism in your record, you require a new DNS lookup. The more services and third-parties that send on your behalf, the more complicated and bloated your record can become. SPF record flattening can be an easy answer, but is not the safest route.

How Does SPF Flattening Work?

In SPF Flattening, hostnames are converted to IP addresses, which don’t count in the DNS lookup tally. Then you create your SPF records using the IP addresses instead of the hostnames.

dmarcian developed SPF flattening as an experiment to work around the DNS lookup limit. In IETF’s RFC 7208, the SPF email authentication standard, lookups are limited to “avoid unreasonable load on the DNS.” You can get into the details of the standard here.

SPF flattening should be discouraged right off the bat; most people are initiating SPF records that are authorizing a lot of the internet that isn’t actually doing authentication in the context of SPF. The result is an increased risk surface where a bad actor can gain access to the parts of the internet that are wrongly authorized and send email from that domain. Instead, it’s best to collect DMARC data as a starting point to understand the overall authentication context and to decide what mechanisms should be represented in SPF records.

Tim Draegen, dmarcian CTO and coauthor of the DMARC specification.

How to Fix “Too Many DNS Lookups”

• Discard (and don’t add) nonessential SPF record entries. Here are a few examples:
  • Remove records for vendors that are unable to be configured for SPF alignment, where the SPF domain matches the MAIL FROM, aka return-path and uses your domain. If you have a dmarcian account, remove SPF records for sources appearing in your Detail Viewer that are “SPF incapable” and show a 0% SPF pass rate. If you don’t have a dmarcian account, you can refer to our free resource dmarc.io to look up the SPF capabilities of the vendor.
  • Avoid “a” and “mx” entries: These mechanisms are often useless and probably should not be included in your SPF record.
  • Remove records for vendors that are unable to be configured for SPF alignment.
  • Delete duplicate SPF mechanisms.
  • Discard top-level domain includes. Many email service providers use subdomains for their MAIL FROM, which is evaluated for SPF authentication.
  • Having an unnecessary top-level domain effectively authorizes thousands of IP addresses to send on behalf of that domain.
  • Where email is incapable of passing DMARC with SPF, configure DKIM.

• Audit your SPF records regularly as part of your ongoing domain maintenance and remove unused SPF entries (e.g. a sender that is no longer in use or has established a subdomain SPF management practice since onboarding).

• Move vendor traffic to subdomains for SPF authentication (see more on this below). Subdomain segmentation creates a new domain dedicated to a particular mail stream with its own 10 DNS lookups.

SPF Best Practices

As organizations grow, email sources can accumulate sporadically and organically. Because of this, mechanisms are often added to SPF records while unused mechanisms aren’t investigated to see if they can be removed.

From a security, operational and deliverability perspective, dmarcian advocates for the segmentation strategy for SPF management. We recommend that different email streams (types of traffic) be separated when possible. The idea is to separate streams per type, such as bulk marketing, transactional, billing, specific third party vendors, operational entities, and so on.

To achieve this, it is also a best practice to separate email traffic into subdomains dedicated to those streams. Doing so increases visibility into each stream, isolating the use of a particular system or vendor. When SPF authentication is necessary, it also brings added security and operational simplicity by offloading the burden of a single-domain approach and avoiding SPF bloating. It’s important to note that each segment should grow its own reputation, which necessitates consistent traffic volume. Variation or lapse in usage on a subdomain can impact reputation and deliverability.

Asher Morin, dmarcian Director of Deployment

In addition to reducing DNS lookups by a subdomain segmentation strategy, the following are some other SPF best practices:

• Avoid using ptr. The ptr mechanism is deprecated and has the potential to place substantial burden on the DNS when querying, and some receivers will skip the mechanism (or the SPF record) entirely.

• Protect any non-sending domains with a restrictive, “deny all” SPF record: “v=spf1 -all”. Bad actors will actively search for unused domains to exploit.

• Avoid “+all” or “all” as it authorizes any IP not explicitly denied in your SPF record to pass. Also, do not use “?all” as it is neutral and does not provide any indication of enforcement preference. A neutral verdict can raise the spam score on an email, pushing it towards a receiver’s spam verdict threshold—it can make the difference between an email ending in a junk folder versus not.

• Use “~all” (softfail) or “-all” (fail). While most receivers treat these directives similarly, some are more likely to reject email when “-all” is used, regardless of your DMARC policy. With this in mind, we recommend mirroring the DMARC policy as the technology is deployed: use “~all” when at “none” and “quarantine” DMARC policies, and deploy “-all” once you have moved to a policy of “reject.”

• Create processes in your organization for ongoing SPF monitoring and management. This periodic review should take into consideration onboarding/off-boarding third-party vendors where appropriate.

If you have any questions about how to manage your SPF records, get in touch with us. You can also read other SPF articles and guidance here and check out our SPF video.

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.