Email comes of age with DMARC
Date: 14/5/2020
In the 2nd in a series of articles on email security, SMX co-founder and email evangelist, Thom Hooker, delves into DMARC, a relatively new and powerful security standard able to protect your staff and domains from forgery, taking in a brief history of email along the way...
Introduction
Email has come a long way since it was invented in the late 1970s/early 1980s. You’ve probably heard that email is insecure and prone to forgery, allowing attackers to launch phishing and whaling attacks pretending to be senior employees within an organisation.
Email is the perfect tool for these kinds of social engineering attacks due to its ubiquity and the relative ease with which it can be forged or spoofed.
All that has changed with the arrival of DMARC, but before we delve into the how, we need to take in a brief history of email.
40 years of evolution…
The first emails were sent in the 1970s but it wasn’t until 1982 that the seminal email RFCs were published, RFC821 and RFC822. (For those unfamiliar with RFCs, the acronym stands for Request for Comment and they are technical documents written in plain English describing a fundamental Internet protocol. As a side note, RFC822 which defines the format for Internet emails was written by David Crocker in 1982 but his older brother, Steve Crocker, wrote the very first RFC1 in April 1969).
Email has been around since the era of free love and existed as a standard for more than a decade before the commercial Internet arrived in the ‘90s, so we shouldn’t be surprised that email is so easy to forge.
One of my favourite quotes from David Crocker, is that we’ve had “40 years of changing the engines in mid-flight”. What he means by this is that since email was rolled out in the 1970s the Internet community has released multiple updates and extensions to the email standard allowing, for example, attachments to be sent with an email (RFC2045 et alia November 1996 - yes that’s right kiddies, before 1996 you couldn’t attach files to your emails). When these new extensions were released we had to keep the mail servers running while supporting old and new extensions at the same time.
Dave’s analogy of changing an aeroplane’s engines in mid-flight continuously, for 40 years, seems appropriate.
Email’s not going anywhere
When you factor in all the extensions to email over the years it’s not surprising email is as popular and ubiquitous as it is today. Several years ago, with the advent of so many different messaging apps, we would commonly hear “the end of email is nigh” or “email has had its day because X messaging app is here now”.
However email fills a particular niche that other messaging “apps” don’t satisfy. For a start email has evolved to support every function within the modern workplace: it is universal, everyone has access to a mailbox, it has the ability to send files (since 1996!), it has built-in logging & bounce handling and is truly open & extensible. If we were going to replace email its replacement would need to have all these features and we would end up replacing email with, well, email.
Then the cloud happened...
Towards the end of the first decade in the 21st century something amazing happened: cloud computing. While the concept of shared and managed services had been around for decades a confluence of factors happened: increased Internet speeds, cheap computing and companies large enough to deploy vast quantities of shared resources for the public to consume enabled the era of cloud computing.
Cloud computing was probably the biggest boost to the world of email since David Crocker wrote RFC822. Why? Because all these cloud resources required a simple way to authenticate users. And which Internet communication technology is more ubiquitous, easy to use or setup than email? Email was the first true cloud app and it’s not surprising that email and cloud services are now so tightly integrated.
It’s evolving... but you’re still using 40 year old technology to authenticate
Internet email is approaching its 40th birthday (in 2022), but it has been continually evolving over that time to meet changing market needs. From the introduction of the cloud, to adding the ability to send documents attached to emails in 1996, we’ve had security extensions such as end-to-end encryption using S/MIME (the foundation of many government-level encryption standards such as NZ Government’s SEEMail standard) and TLS (for encrypting the session itself) which has had a huge impact on every user on the planet; stats from Google show that about 90% of all email is now sent via TLS-encrypted sessions, up from 30% in early 2014 when they started reporting on this.
Email comes of age with DMARC
In March 2015 the email gods released DMARC (RFC7489) and it is having a big impact on email forging and spoofing.
The DMA in its name refers to Domain-based Message Authentication, essentially using a combination of SPF and DKIM to verify whether an email really was sent by the purported sender - finally we can determine whether an email is legitimate or not!
The RC letters in the name relate to Reporting and Conformance and allows domain owners to specify what sort of reporting they would like to receive on spoofing attempts using their domain.
So you can think of DMARC as being anti-spoofing and reporting in one. Sounds amazing and just what email needed.
But...DMARC uptake is low
Sadly, despite turning 5 years old recently, apart from some large (US-based) technology companies, DMARC is surprisingly and, from a security POV, depressingly under deployed.
Some stats from a recent survey we conducted of organisations utilising DMARC in this region demonstrate this.
- 8% of NZ’s top 100 Companies have DMARC
More than 1 third of the top 100 companies in NZ have some form of DMARC record but of those companies many were either still experimenting with DMARC or had misconfigured records. That sounds great, but only 8 have a working valid DMARC setup that either rejects or quarantines email. Just 8% of the largest companies in NZ, that’s pretty poor and needs to be improved to protect customers and partners of these large organisations.
- 4.5% of NZ Government Agencies have DMARC
We looked at the DNS records of all 372 NZ government agencies. While we found 74 agencies have some form of DMARC record we saw large numbers of misconfigured or invalid records amongst them. This also means 298 agencies have done nothing about DMARC.
Of the 74 agencies with some form of DMARC only 12 are configured to reject email, another 5 to quarantine emails that breach their policy.
So that’s 17 out of 372 agencies or just 4.5% of all government agencies care enough about their email security to implement DMARC. Obviously a lot of room for improvement there.
- 1.4% of the est of NZ have DMARC
We also surveyed the top 50% of NZ companies, by volume, sending emails to SMX customers. This equated to just over 56,000 domains and the story is fairly similar to the government and top 100 groups: about 4.5% of companies have some form of DMARC record but we see a large number of these being configured to either take no action or misconfigured and invalid.
Of the 4.5% only about 1.4% actually have an enforcing DMARC policy, which means more than 98% of NZ businesses don’t have one. Again, a lot of room for improvement.
So, we should all be using DMARC?
The short answer is yes! But setting it up on your own domains should be done carefully.
The good news is that there are a lot of resources available on the internet, including the likes of https://dmarc.org/resources/
If the DIY approach isn’t your style or you simply don’t have the resources then there’s even more good news; protecting your staff from receiving fraudulent emails spoofing large companies such as Paypal and Amazon can be done easily by implementing a 3rd party email security vendor on your inbound email flow.
Unsurprisingly, SMX is a leader in this space and like many email security cloud vendors detects and blocks emails that breach DMARC policies of these large email senders. You’ll find a lot of these large senders have already deployed DMARC records and some, like Paypal, played a leading role creating the DMARC standard itself because they and their customers were particularly badly affected by email spoofing.
Implementing DMARC on your own domains should be done using a phased approach. DMARC provides mechanisms so you can authorise MTAs to only report on emails that fail your policy (using p=none) or alternatively to apply your DMARC policy to only a defined percentage of email from your domains (using pct=5 would affect only 5% of your email for example) as you roll it out.
Finally, if you need help with implementing a robust DMARC policy for our own assets check out the online resources or contact SMX by clicking here.