DMARC, or Domain-based Authentication Reporting & Conformance, is an email authentication, policy and reporting protocol. It was conceived to prevent impersonation-based phishing attacks, but it doesn’t protect you 100%. Let’s examine why.
What DMARC Can Do
DMARC builds on the existing and widely deployed SPF and DKIM protocols. All mechanisms to protect the email infrastructure we so heavily rely upon should be gratefully received, but as with everything the benefits and limitations should be fully understood. It is this understanding that allows us to optimize our defenses against the perpetual menace of phishing attacks.
DMARC has most promise to help organisations defend against Business Email Compromise (BEC) type attacks, as successful impersonation can be an imperative for success. As a result, DMARC should be evaluated as a mitigating control for these types of attacks, protecting both outbound as well as inbound email.
DMARC aims to get email senders and receivers working together in a standardized, coordinated way to determine whether a given email is legitimately from the sender—and the actions to be taken if it isn’t.
Therefore, if [email protected] sends an email to [email protected], appropriate DMARC policies can help remove the guesswork and answer the question “Has this email really been sent by [email protected]?”. By protecting their messages with SPF and DKIM, and using DMARC, sender.com can tell receiver.com what to do if these authentication methods fail, for example, reject the message.
What DMARC CAN’T Do
It all sounds good, but what if the email comes from [email protected], or [email protected]—does DMARC help then? Unfortunately, not. What about if the message is sent by [email protected], but the From: field has been modified to look like it comes from [email protected]—does DMARC keep Bob safe? No again.
While display-name abuse and adjacent-domain abuse are well recognized, there’s another growing phishing tactic that neutralizes DMARC completely. DMARC has capabilities to validate the sender’s authenticity, but it has no capability to validate the authenticity, of the email content.
Recently, the Cofense™ Phishing Defense Center has seen a significant rise in Man-in-the-Inbox style attacks. These attacks typically occur when user credentials have been compromised and are used to gain access to the compromised user’s mailbox and send malicious emails. These emails might be sent internally (no DMARC there…) or to a trusted third-party (DMARC might be configured, but as the message is coming from a legitimate user, SPF and DKIM check out, and the message is delivered…). The recent PDC zombie phish blog post discusses one style of Man-In-The-Inbox attack in more detail.
Given this, it’s important that emails teams don’t expect more from DMARC. It’s equally important that security teams ensure that end users are empowered to be “human sensors,” to identify and report emails that look suspicious. Users need to be alert to visual clues, such as adjacent sender domains, peculiar content, or unusual or unexpected emails, even if the emails come from internal senders or trusted third-parties.
We all need to remember that real phish are the real problem. This means knowing what real phish look like as they evolve day to day—and not expecting DMARC to do more than it really can.
Want to learn more about the DMARC protocol? Take a look at https://dmarc.org for the juicy details.
All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.
