SPF Management Challenges
The email world was a much different place back in 1997 when the idea of SPF was taking shape. It went mostly unnoticed when first publicly mentioned around 2000, but fast-forward 20 years, and it is now one of the most widespread forms of email authentication in use, along with DKIM and DMARC. Ensuring the accuracy of your record then was a much different challenge to undertake compared to now.
The accuracy of your SPF record relies on your understanding and visibility into your email ecosystem. For many organizations this ecosystem consists of directly managed infrastructure that is owned or on-site in a jungle of hosted services sending emails on behalf of your domains. In recent years this jungle has only grown, quickly pushing, and sometimes breaking, the limits of SPF imposed by its own implementation, as well as the DNS itself. Juggling these limits are realities that must be addressed and baked into any organization’s domain management processes.
In this article, our Deployment Team speaks primarily to the common challenges in regard to deploying SPF in the modern world of email authentication.
Let’s imagine for a moment that you own a single domain, along with a hybrid on-prem/exchange online environment, and about a dozen hosted services that send emails on behalf of that domain. The first thought could be to simply add all relevant entries to your domain’s SPF record and call it a day. After all, they are using your domain to send email, so the process should be simple. The reality is that this process should include evaluating how these services are sending emails on your behalf, identifying which SPF challenge you are experiencing, and understanding the solutions to each to form a deployment plan.
The problem encountered will generally fall into one of the following: You are breaking the 10 DNS lookup limit, or your record is too big to fit in a single TXT record—the first is the most commonly encountered, by far. What is there to do about it? Well, there are few solutions, and none are perfect. However while finding a solution is required, the importance of understanding the problem through management knowledge of your email ecosystem is paramount. This will allow you greater flexibility in making operational decisions for your organization’s domain management practices.
The common solutions most often used to address the SPF 10 DNS lookup limits are the following:
- Avoiding unnecessary DNS mechanisms
- Avoiding “a” and “mx” entries
- Dedicated email sources subdomains
- Dynamic SPF solutions
Let’s look at some of the pros and cons for each.
Avoiding Unnecessary DNS Mechanisms
Though this may seem like obvious advice, there is a lot of bad guidance on the Internet as to when or if an organization should add a specific vendor or service to their SPF record. Let’s remember that a verifier performs an SPF record check against the domain extracted from either the RFC 5321 Mail From email address, or the HELO/EHLO identity issued by the client during an SMTP conversation should the Mail From be null. This email address (also known as the return-path, envelope from, bounceback address) is not the same as the RFC 5322 From: email address header. You may often hear it called the Friendly From. This is the from email address commonly displayed in an email client. These two addresses sometimes don’t match, and they don’t have to.
When onboarding a new service or vendor, it is important to understand how they will be sending emails on behalf of your domains. More precisely, what domain will they be using as a return-path? If the answer is none of your domains, then there is no reason, from an authentication perspective, to add them to your SPF record. It can be difficult to understand or see how existing services are already sending emails, and this is where DMARC can help as the feedback reports contain metadata on what domain identity was verified as part of the receiver’s SPF check. Keep your records clean!
Avoiding “a” and “mx” entries
One of the most common mistakes for an SPF record is to have “a” and “mx” listed. While those are completely valid and sometimes useful in a correct way, they are more commonly useless and should not appear. The “a” mechanism indicates that the IP address of the domain should be allowed to transmit messages for the domain in the From header of messages; this is usually wrong because that IP address is the domain’s web host IP address. While this CAN be a legitimate use, it is not normal. You should investigate and remove the entry if possible.
The “mx” mechanism indicates that the IP addresses for the domain’s MX records should be allowed to transmit messages for the domain in the From header of messages; this can be incorrect because the MX hosts are used for ingress traffic, and outbound does not go through that same environment. Many times this is completely legitimate, but it is incorrect for most large hosted environments such as M365, Google, etc. If your SPF record already has allowance for traffic from your provider such as those, addition of “mx” is incorrect.
Dedicated Email Stream Subdomains
What we are talking about here is creating a subdomain that will be used by one or few service providers. Think of sales.example.org for all sales-related third party senders. This need is sometimes inevitable when deploying DMARC where you may have a vendor that does not support DMARC, and you isolate them to their own subdomain with its own DMARC policy.
When a verifier performs an SPF record check, it only looks at the domain as extracted from the RFC 5321 Mail From. This means if an email is sent using info@sales.example.org as the Mail From address, the receiver will look strictly in the DNS for an SPF record at sales.example.org, not its parent, ever. What this gives you is a brand new domain to create an SPF record, a clean slate. Isolating streams of emails this way can also help mitigate the impact of potential abuse of email accounts existing on the subdomain only. In turn, it can also help isolate domain reputation impact from abuse to the subdomain, rather than impacting all services using your primary corporate domain identity.
Depending on the scope of this subdomain, there may be additional costs associated with the deployment, such as identifying if there is a need for additional licenses, web resources, etc. Scoping the need will determine the resources required to deploy and any associated costs. In addition, this adds to the current administration load of your domain management team.
Dynamic SPF Solutions
The idea of a dynamic SPF record can be several things, such as dynamically flattening a record, then publishing the result based on a data source. It could also mean more complex management through the use of macros. These solutions can be varied in implementation, but they typically all present the same benefits. Primarily, it allows for a type of automation and provides greater flexibility and scalability. The goal is to save administration time while not having to worry about how many senders are sending on behalf of your domain.
These can be very strong solutions, but they are not a panacea. They would require significant internal development time for an in-house custom solution. More realistically, organizations will seek a service provider for this functionality, and they can be costly. It also shifts the mentality towards SPF-first deployment, using few if not a single domain. With many service providers not supporting a custom return-path, meaning a return-path using your domain instead of theirs, such solutions will not help, and will rely specifically on DKIM for authentication when deploying DMARC. In certain implementations, there can also be a stronger DNS reliance with a single point of failure for all email streams.
Ultimately, nothing beats strong research to determine what solution is best to solve your problem. Regardless of which one you employ, a strong SPF management process is best practice to ensure long-term email authentication deployment success.
If you have any questions, visit our website and chat with us. If you haven’t already, you can sign up for a free trial here and let us help you secure your email domains.
Want to continue the conversation? Head over to the dmarcian Forum.
