Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

1/24/2017
02:30 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

The Trouble With DMARC: 4 Serious Stumbling Blocks

Popularity for the Domain-based Message Authentication, Reporting and Conformance email authentication standard is growing. So why are enterprises still struggling to implement it?

Since its creation, email has suffered from an "original sin" - the inability to confirm a sender’s true identity. Recently, that flaw has led to an onslaught of phishing attacks - which often lead to further network compromise. According to one recent study, phishing is the launch vehicle for 91% of all cyberattacks.

In response, a growing number of organizations are turning to DMARC (Domain-based Message Authentication, Reporting, and Conformance), an open standard that can help prevent phishing attacks. As a critical additional benefit, DMARC also helps IT administrators get control over which cloud services are sending email on their behalf.

DMARC has been proven to be highly effective at both of these jobs, but we’re finding that a large number of companies are not successful at fully implementing DMARC. Recent data shows that DMARC usage is growing exponentially. But when ValiMail analyzed more than 1 million of the largest domains on the Web, we found that around 70% of those who implemented DMARC were not getting it right: Either there were configuration errors or DMARC was not actually switched on to enforcement mode. Just as surprising, the 70% failure rate applied to all companies, regardless of their size.

In other words, even with the near infinite IT resources of the largest companies in the world, they did no better than a mid-sized company when it came to properly implementing email authentication. Here’s why:

DMARC Is Tricky to Implement
The first problem is that DMARC is based on two 10-year-old standards, SPF and DKIM. All three standards are based on DNS TXT records, which is pragmatic (DNS is a great place to store domain-relevant information) but has an unfortunate downside in terms of configuration. DNS is the furthest thing from a point-and-click environment you can imagine. There is no GUI, the syntax is cryptic - you have to edit text records character by character - and the slightest error can screw everything up.

Complicating matters is the fact that DNS is so critical to the operation of an online business. Consequently, many organizations require a multi-week process before making any DNS record changes. With DMARC, SPF, and DKIM, you might be making many such changes as you configure and tweak your setup. Half a dozen DNS changes could easily take months to get through the pipeline.

DMARC Was Not Built for the Cloud Era
The DMARC standards themselves have built-in limits that make them challenging for companies that have embraced cloud services.

For instance, Sender Policy Framework (SPF) - an open, DNS-based email authentication system -  has a 10-domain lookup limit. SPF records are allowed to specify whitelisted servers by IP address or by rule sets included from other domains. But to protect against denial of service attacks, receiving mail servers won’t actually look up more than the first 10 rule sets listed in an SPF record. Since each cloud service typically uses between 3-5 rule sets, you’ll probably run into the 10 lookup limit with only three cloud services.

So if your company is using more than three cloud services that want to send email on your behalf, you need to list those cloud services’ mail servers by IP address. Do you know all the IP addresses used by Salesforce.com mail servers? How about Gmail? Are you prepared to update your DNS record every time one of those providers adds a new server?

No One Wants to Cut Off Critical Services Accidentally
Many companies lack the confidence that they’ve identified all the legitimate services that should be able to send email on their behalf. The consequences of an error can be high: Your IT guy might never have heard about Zapproved, and its message volume may be very low. But Zapproved is a legal discovery tool, and if you support a law firm and your attorneys are using it, cutting off its access to email could be disastrous for any legal work the firm has in progress.

IT administrators know the risks, so they are reluctant to take DMARC all the way to enforcement mode until they are absolutely sure it’s not going to cut off any critical services. Given the problems with DMARC’s complexity and its built-in limitations, that state of absolute confidence may never arrive.

Configuration Is Just the First Step
Now, consider that the above three problems -- DNS entries, standards limitations, and service identification -- all relate to configuration. That’s really only the first step. Once your email authentication is configured correctly and set to enforcement mode, you will need to consider maintenance, management, and alerting/notification (dealing with warnings, alerts to spikes in phishing attacks).

A lot of companies start with the best of intentions, thinking DMARC is an open standard, and not appreciating the complexity that comes with implementation. They then get into hot water and can’t get past the initial "monitoring mode" of DMARC without ever getting to enforcement, where DMARC’s greatest security and compliance benefits reside. It's an unfortunate reality that DMARC is simple in principle but complicated to manage in today's modern, cloud-centric world. The devil is in the details.

Related Content:

 

Alexander García-Tobar is CEO and co-founder of ValiMail, a leading provider of email authentication services located in San Francisco, CA. Alexander has deep roots in the email authentication and cybersecurity space, as a global executive and advisor at Agari, ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Commentary
How SolarWinds Busted Up Our Assumptions About Code Signing
Dr. Jethro Beekman, Technical Director,  3/3/2021
News
'ObliqueRAT' Now Hides Behind Images on Compromised Websites
Jai Vijayan, Contributing Writer,  3/2/2021
News
Attackers Turn Struggling Software Projects Into Trojan Horses
Robert Lemos, Contributing Writer,  2/26/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-21360
PUBLISHED: 2021-03-09
Products.GenericSetup is a mini-framework for expressing the configured state of a Zope Site as a set of filesystem artifacts. In Products.GenericSetup before version 2.1.1 there is an information disclosure vulnerability - anonymous visitors may view log and snapshot files generated by the Generic ...
CVE-2021-21361
PUBLISHED: 2021-03-09
The `com.bmuschko:gradle-vagrant-plugin` Gradle plugin contains an information disclosure vulnerability due to the logging of the system environment variables. When this Gradle plugin is executed in public CI/CD, this can lead to sensitive credentials being exposed to malicious actors. This is fixed...
CVE-2021-24033
PUBLISHED: 2021-03-09
react-dev-utils prior to v11.0.4 exposes a function, getProcessForPort, where an input argument is concatenated into a command string to be executed. This function is typically used from react-scripts (in Create React App projects), where the usage is safe. Only when this function is manually invoke...
CVE-2021-21510
PUBLISHED: 2021-03-08
Dell iDRAC8 versions prior to 2.75.100.75 contain a host header injection vulnerability. A remote unauthenticated attacker may potentially exploit this vulnerability by injecting arbitrary ‘Host’ header values to poison a web-cache or trigger redirections.
CVE-2020-27575
PUBLISHED: 2021-03-08
Maxum Rumpus 8.2.13 and 8.2.14 is affected by a command injection vulnerability. The web administration contains functionality in which administrators are able to manage users. The edit users form contains a parameter vulnerable to command injection due to insufficient validation.