When DMARC (Domain-based Message Authentication, Reporting, and Conformance) launched in 2012, it looked to some as if the Utopia of a fully “authenticated email world” was out there.
It’s a mouthful to say and, apparently, it’s been a handful to implement with new figures suggesting that DMARC’s promised land remains elusive.
Despite strong backing at launch from Microsoft, Facebook, Google, Yahoo and PayPal, only a measly 39 of Fortune 500 companies have implemented a DMARC policy for their domains.
That leaves 124 using it in the passive “none” monitoring mode (in other words, simply watching how other DMARC domains are treating their email) and 337 who haven’t bothered at all.
Sectors that have got the DMARC memo are overwhelmingly in technology, finance and business services, leaving aerospace, energy and engineering with tiny levels of take-up.
But even in tech and finance, uptake is patchy, which seems odd given that these are the sectors most targeted by cybercriminals phishing and spoofing well-known domains for all sorts of bad reasons.
Things aren’t much better in London’s FTSE 100, the survey found, with two thirds of companies lacking DMARC in any form and only six using it in its full “reject” flag glory.
It should be catnip for email security teams, so what’s going wrong?
Earlier this summer, an exasperated US senator even sent an open letter to the Department of Homeland Security (DHS), asking why so many US government domains weren’t using DMARC, to everyone’s detriment.
The problem is DMARC isn’t catnip for email security teams at all – far from it.
DMARC is as a way for companies using email domains to define a policy that tells other domains how to treat email claiming to be from them.
Using Sender Policy Framework (SPF) and DomainKeys Identified Message (DKIM) protocols for IP address and encrypted key authentication, DMARC gives a receiving domain guidance on what to do if an email – a phishing attempt for instance – fails these tests.
DMARC, then, gives domain owners a way to receive detailed reports on abuse of their domains by fraudsters, which helps them protect the people they want to send emails to.
Obviously, this works best when everyone does it. If not enough companies adopt DMARC then the view companies have of abuse is only ever partial.
If DMARC is like the wisdom of the crowd, it has drawbacks. For a start, it needs a lot of experience to implement without causing the sort of problems that ends with email admins being told to clear their desks. Limitations in the ageing SPF protocol don’t help either.
Did we mention that DMARC can be time-consuming to administer when using external email services?
The biggest flaw of all is simply that DMARC only solves part of the problem. Even if universally adopted, criminals can find ways around using it a toolbox of tricks including hijacking or using legitimate domains (which pass authentication) to send emails mocked up to look genuine. Domain abuse isn’t the only game in town.
Nobody doubts wider DMARC adoption could make a difference. The question is whether the difference is seen by companies as worth the expense and hassle. Without wanting to sound pessimistic, it’s as if some companies have lost faith in security’s grand Utopias.
David
Yes, it was difficult to implement, required knowledge of anything and everything that was capable of sending emails, fixing years worth of bad code, constant communication with vendors, and maintenance after the fact. However, if you have a tool available to make even a small dent in fraudulent email, why not use put it in your toolkit?
Benjamin Schoenecker
I have been part of a fairly early adoption of DMARC (financial industry) for some time. I think the real reason it’s a challenge is because it requires intimate knowledge and collaboration between business units to work smoothly. Most larger organizations these days have many entities that send email on their behalf, and knowing all of them is the first battle. Being able to weed out what is legitimate and what is not is key. Then, there’s dependence on the vendor to support the needed frameworks (SPF / DKIM). While there are some simple workarounds for SPF, the IP4 declarations can be spoofed, and the standard only allows 10 named SPF records as a maximum. DKIM is great, and truly authenticated email, but good luck getting all of your vendors on board with it!
Con Lokos
I applaud when vendors advocate for DMARC implementation, just as in this article from Sophos.
A couple of points I would counter are:
1. Everyone CAN do it – 80% or more of your suppliers should be dmarc compliant. There are financial requirements for all your purchases, so why not security requirements.
2. Lots of experience not needed – if you understand the way email works, then its a quick and small learning curve for admins to understand dmarc
3. Yes, dmarc solves part of the problem, but email borne threats are the majority of the problem
4. Its not complex – its like baking a cake as opposed to designing a car engine.
There’s no silver bullet, so don’t wait for the ultimate fix – its not coming – that is unless you want to give up email !!
Start today – its easy !
0Laf
There is a push for this government. I know of organisations that have implemented and although there have been problems in general they have not found it all that hard.
I’ve always used the analogy of vaccination in describing DMARC. It only really works well when a majority of the community are immunised.
Dylan Tweney
This piece is spot on in most respects, including the potential usefulness of DMARC and the difficulty most organizations have in implementing it. Only about 30% of organizations that publish a DMARC record actually complete it correctly and get it to an enforcement policy (p=quarantine or p=reject).
However, you write: “If not enough companies adopt DMARC then the view companies have of abuse is only ever partial.” This is not correct. In fact, DMARC has been widely implemented by ISPs and providers of email services, including every major provider of consumer email and many enterprise providers. DMARC works with about 2.7 billion mailboxes worldwide.
As a result, any organization that publishes a DMARC record will see benefits from it immediately (and will collect data from the vast majority of receiving mail servers around the world). There is no longer any need to wait for wider adoption.
John E Dunn
You make a good point about ISP implementation but that still leaves about half of the world’s inboxes working outside DMARC. The point about DMARC, surely, it that was designed to be a universal standard.
Dav
We started to test inbound emails using DKIM and SPF, we’ve had nothing but problems!
SPF – too many senders/organisations still left the ~ in the string. We used to send polite emails letting them know this setting was enabled and as such, they’re emails could still come from other/rogue IP addresses and we’d have to honour them! We tried to implement a policy that on softfail, we’d add a note to the subject of the email – the outcry from staff and from the companies that sent the email was outrageous! Even Google advises it for their customers to use ~. We’ve had so many arguments about this that we no longer do anything with softfails!
DKIM – we used to check these, but found too many companies screwed up the configuration and as such the DKIM check would fail and we’d bounce back the email. And yet it was left to us to prove that the sender had screwed up; almost impossible with DKIM. We even had a mass problem with people using Office 365 for emails (varying companies); it seemed to stem from a mass update made by Microsoft (1 or 2 years ago? I forget now)… We had to stop checking these emails because of the overhead/man-power to tackle the problems was too great.