Many organizations are trying to embrace email authentication technologies. Some are struggling with some of the required steps to proper authentication: announcing their authentication policy to the world. By failing this early step, they are missing the benefits that these technologies can bring in terms of brand protection and email deliverability.
As part of our Ongoing Email Security Survey, we scan a large group of domain names and study the deployment of email authentication technologies such as DANE, DKIM, DMARC, MTA-STS and SPF. We are excited about this work and the statistics it will provide on the growth of these technologies; but this post is not about that.
So far, our survey has analyzed around 170,000,000+ domain names under many extensions including generic and country-code TLDs. While still incomplete, there are some preliminary findings that surprised us.
SPF and DMARC
In terms of ease of deployment, SPF ranks quite high. Our numbers show that this is by far the most deployed authentication technology at this time.
The hard part of deploying SPF – indeed, the part where most of our clients focus most of their attention – is determining the valid sources for email their organization sends. Once this is known, translating this knowledge to a properly-formatted DNS record is easy. At least in theory, because our survey is continually finding that almost one out of five domain names have SPF records that do not match the specification.
DMARC fares slightly better, at roughly one in twelve domains providing an invalid record.
The effects for most of those domains is weak authentication that exposes their domain reputation and denies them from useful reports. And of course, the wasted effort lost when publishing a non-functional email policy.
For both protocols, there are great resources online for verifying the corresponding DNS records. Not only right after implementation, but periodically afterwards, to make sure they are not inadvertently changed.
If you take a single thing from this post, it should be to check your domain names SPF and DMARC records frequently.
DANE vs MTA-STS
While SPF, DKIM and – to some extend – DMARC deal with protecting the outbound mail stream, DANE and MTA-STS are concerned with the inbound stream. It helps senders know your organization preference for receiving encrypted email – and helps those senders work in concert with you to prevent spoofing.
DANE provides a very powerful mechanism to request encryption when communicating with your domain’s mail servers – and allow supporting correspondents to validate the TLS certificate used to secure the connection.
With the protocol itself dating back to 2012, support is still spotty as few MTAs or email providers offer support for it.
MTA-STS tries to achieve a similar goal through a different mechanism, with less stringent technical requirements.
By the way, we have a free MTA-STS checking tool you can use to check your own domain configuration, including your MX server TLS configuration.
Based on our experience with our clients, DANE presents more technical challenges than MTA-STS because it requires DNSSEC and tight coordination on the part of the team responsible for managing mail servers and TLS certificates. Still, we frequently recommend implementing both technologies for clients in the financial or health industries.
Again, looking at some preliminary numbers from our survey, DANE is protecting 6,000,000+ domains while DNS records for MTA-STS are seen in just under 2,000 domains. These results are hard to translate in terms of secured message volume, as some of the largest email providers are currently supporting MTA-STS.
Also, keep in mind that the specification for MTA-STS is quite recent – late 2018 – so these numbers might be very different by this time next year.
Our survey only rarely finds invalid DANE DNS records. This is likely due to the DNS software enforcing proper format at publication. For MTA-STS, we see under 1 in 50 invalid DNS records. Both of these are great indicators.
For those organizations that take the effort in protecting their inbound mail stream, the actual configuration of the required DNS records does not seem to be an issue.