Modernizing Authentication — What It Takes to Transform Secure Access
By default, email is not secure. That's not an inflammatory statement, just the inconvenient truth.
When an email is sent or received, there is no obvious or clear indication that the email is authentic or if it was sent from a validated sender address or domain. One way to improve the security of email is the DMARC standard - which will become a U.S. federal government standard next week.
What is DMARC?
Domain-based Message Authentication, Reporting and Conformance is a protocol that was first proposed in January 2012, though it is likely that 2018 will be a big breakout year for adoption.
DMARC is being adopted by the U.S. government as part of the Department of Homeland Security (DHS) 18-01 binding operational directive that was issued in October 2017. The directive requires all second-level agency domains to have valid DMARC records by Jan. 15.
The DMARC protocol is actually only the top layer of a set of protocols and technologies that when used together help improve email security. DMARC can be thought of as the policy layer for email authentication technologies known as Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM).
DKIM is all about protecting a domain from being used for email spoofing. In an email spoofing attack, an attacker (or a spammer) uses an arbitrary domain name in the sender field in an effort to trick a user into thinking an email comes from a legitimate source.
DKIM provides a cryptographic verifier for a domain that can be attached to an outgoing email. The promise of DKIM is that it can help to prove that a given email did in fact come from a domain that was authorized to send email using the given domain name.
In many use cases, organizations use different email providers and gateways to send email other than the same server where a domain is hosted. That's where Sender Policy Framework (SPF) fits into the DMARC picture.
With SPF, an organization can define which email exchanges are allowed to send email on behalf of a given domain.
While having SPF and DKIM on a given domain is all fine and nice, the challenge is that receiving organizations don't know if they should look for those items. Additionally, if SPF or DKIM fail for one reason or another, impacting the delivery of email, the sending organization might not be aware of the error.
DMARC policy aims to solve both those issues.
A DMARC policy is included in a DNS record for a given domain, enabling the sender to specify if messages are protected by SPF or DKIM. DMARC policy also integrates an email address that can be used to for sending compliance reports for non-delivery of emails due to DMARC policy violations.
The DMARC policy itself is flexible, allowing organization to set different parameters and tolerance for non-compliance.
DMARC is not a panacea for all that is wrong with modern email. It does, however, provide an authentication layer that could help to cut down on spam and fraudulent emails. Without DMARC policy, recipients have no easily assured way of knowing if a given email actually came from or was authorized by the domain it claims to come from.
DMARC is an important component of modern IT security hygiene in 2018, and U.S. government adoption will likely help spur wider adoption by enterprises around the world as well.
Interested in learning more? Coming soon on eSecurityPlanet: Learn how to implement DMARC for your own domain.
Sean Michael Kerner is a senior editor at eSecurityPlanet and InternetNews.com. Follow him on Twitter @TechJournalist.