Since its humble beginnings in 2010, DMARC (Domain-based Message Authentication, Reporting & Conformance) has become a powerful tool for many organizations to improve their email filtering and properly assess the strength of their domains’ emails
In particular, the prevalence of Business Email Compromise (BEC) attacks, which rose 42 times relative to Banking Trojans between the end of 2015 and the end 2016, have given added importance to DMARC. DMARC’s robust authentication features can successfully prevent a majority of BEC attacks. Most of them rely on various kinds of domain or email spoofing to pass through filters undetected and misleading business stakeholders. A Report from the HMRC showed DMARC is capable of stopping 99% of malicious scams that involved a phishing email.
While the value of DMARC is clear, understanding it may be tricky. To make things simpler, here’s an explainer by Vircom’s Chief Scientist, Deeptiman Jugessur, on how the DMARC record works and why it matters.
Motivation – What is DMARC and what does it do for Email?
To understand DMARC and its value, we must first understand the structure of an email and the fundamental challenge that exists within that structure. To begin, an email consists of 3 parts; The Envelope, The Headers, and The Body.
The Envelope
Similar to a snail mail envelope, the Envelope is primarily used to identify the sender and recipient. The sender, a.k.a the email address specified in the “return-path” in email lingo, is used in cases where the message could not be delivered. In SMTP (Simple Mail Transfer Protocol), this is also known as the “MAIL FROM” field. It is often called the “bounce address”, the “envelope sender address” or the “envelope from”.
The Header
The Header section contains information which can be parsed by Mail Transfer Agents (MTA). For example, “received” headers exist so that MTAs can know the path your email has taken on its way through the internet, as well as information which is displayed to the recipient. The “Subject” field is probably the most known header field. Among the various header fields, there is a “from” field (which we will call the “header from” to differentiate from the “envelope from”) which is of particular interest to those looking to understand DMARC.
The Body
Finally, the body of the message contains the actual payload of the email.
[cta id=’18654′]
The Challenge of Authentication
Considering the general structure of an email, the fundamental problem that remains is that there is no built in mechanism to validate a sender’s authenticity. A sender is identified using the 2 fields mentioned above, the “envelope from” address and the “header from” address. One can send an email pretending to be someone else by spoofing either or both of those 2 fields.
For example, say an accountant named Njord works at the company asgard.com and receives a spoofed email requesting information. The email below is an example of the spoofed message sent from Loki@midgard.com to Njord@asgard.com. However, in this email, Loki is pretending to be the CEO of asgard.com, Odin.
This is an example of a phishing email, as the real sender (the attacker, Loki) wants confidential information. When Njord opens this email in his mail client, he will not see the “reply-to” header field (which identifies Loki) – he will only see that the sender is Odin. Should he fall for the scam and reply to this message thinking that he is replying to Odin, the message would actually be sent to the attacker: Loki@midgard.com.
Lines 1 to 3 are part of the envelope. The “envelope from” here is odin@asgard.com. Lines 5 to 8 are headers and the “header from” is Odin Borson CEO <odin@asgard.com>. The rest of the message is the body. Upon connecting to an MTA, the above is sent via SMTP. The MTA only knows the connecting IP address of the real sender, while the rest of the data it can use to validate the email is in the message above.
The SPF Record : The First Step in Email Authentication
Spammers have been exploiting this vulnerability in email for decades and, as a response, several measures have been developed to validate sender fields. Enter SPF (Sender Policy Framework). SPF tackles the sender authentication by requiring MTAs that support it to perform DNS TXT queries on the domain specified in the “envelope from”. If a domain owner wishes that messages coming from their domain be checked for authenticity, they can specify lists of authorized senders by adding them to an SPF TXT record in their DNS infrastructure. An MTA would then simply check if the connecting IP address is in the list of authorized senders in that domain’s SPF TXT record.
Thus, by leveraging the fact that a domain owner should be the only one able to alter their own DNS records, one should be able to guarantee the authenticity of the sender. In the above example, if the owner of asgard.com had set up an SPF record stating the list of servers that are allowed to send emails for asgard.com, with a quick SPF check on asgard.com, the MTA could have blocked the message before it reached Njord, our accountant at asgard.com, as Loki does not own an IP address that is allowed to send on behalf of asgard.com. This would prevent this particular form of spoofing from being successful, but is asgard.com’s problem solved?
Well, not really. Consider the following spoofed message:
Note the difference in Line 2. The “MAIL FROM” (envelope from) field now contains loki@midgard.com. Loki owns midgard.com, so if he setup his own SPF TXT record, an SPF check by asgard’s mail server would now pass. Since poor Njord does not see the “envelope from” in his mail client, he would once again only see the “header from” and consequently reply to the message, sending Loki confidential data. While there are ways of examining the full message headers in an email on most email clients, a typical email user does not do this, meaning that users at organization’s using SPF are still vulnerable to revealing confidential data, as well as other phishing-type threats.
The DKIM Record: Another Attempt at Email Validation
Another technique introduced to guarantee the authenticity of a sender was DKIM (DomainKeys Identified Mail). Once again, it leveraged DNS. The domain owner would generate key pairs and publish their public key in a DNS TXT record. All outbound messages would then be signed using the private key and a DKIM header containing the signature would be added to the message (see lines 5 to 9 below for an example). DKIM-enabled MTAs could then examine this DKIM header and verify that the email had not been modified by decrypting the hash value in the signature and recomputing the hash based on fields specified in the DKIM signature. If there was a match, the email was unaltered.
Once again however, if a spammer created valid DKIM signatures and signed their spoof emails with the valid signature, poor Njord would still get the message as his MTA would accept it. Furthermore, he would reply to the message, as the “header from” would still show Odin Borson CEO <odin@asgard.com>. In the example below, Loki has sent a proper DKIM-signed message from his DKIM and SPF enabled domain midgard.com.
The DMARC Record: The Best Email Authentication (Yet)
DMARC handles this problem. With DMARC, the validity of the email specified in the “header from” field is tested. Instead of starting from scratch to tackle the sender authentication problem, DMARC leverages the benefits of both SPF and DKIM. As with the other 2 techniques, DMARC also requires that the domain owner setup a DNS TXT record.
A typical DMARC DNS TXT record would look like: v=DMARC1; p=quarantine; rua=mailto:vor@asgard.com. This effectively says that should DMARC validation fail, the message should be quarantined. Furthermore, the record instructs the mail server to send DMARC reports periodically to vor@asgard.com.
Had there been such a published DMARC record for asgard.com, a DMARC capable MTA would perform extra checks to validate the sender in the “header from” field. A DMARC DNS TXT query would be performed for the domain in the “header from“, namely asgard.com. If it exists, the MTA moves on to try validate it.
For a DMARC validation to pass, SPF and/or DKIM validations should pass and the domain from either of the passing algorithms (envelope from domain in the case of SPF, and the domain specified in the d= field in the DKIM signature for DKIM) must align with the domain specified in the “header from” field. Alignment means that the domains match, or that one is a sub-domain of the other. So, in the example shown above, we see that midgard.com (the domain from both SPF and DKIM) does NOT align with the domain in the “header from“, asgard.com. Hence it’s a DMARC fail and the DMARC record says to quarantine such emails. Njord finally gets a break as the email does not end up in his inbox.
DMARC Reports: Improving on SPF and DKIM
DMARC took things a step further from SPF and DKIM with its reporting feature. This was necessitated by the fact that SPF and DKIM DNS records were often misconfigured, and domain owners would typically only find out about the misconfigurations when they are notified by their clients that their emails were not being delivered to a party. By specifying a rua in the DMARC record, DMARC validators can send detailed reports to the rua recipient email address about how DMARC is performing on their servers.
A DMARC record also details the performance of both SPF and DKIM on the validating server, thus a domain admin can keep an eye on the performance of their SPF and DKIM records upon modification. One should keep in mind that SPF and DKIM records change over the lifetime of a company. For example, if a company uses a marketing service to send emails on their, their SPF record should be updated accordingly. A constant analysis of a DMARC report would notify a company of such a breakage, were it not updated, and thus assure that their marketing emails are being delivered while their organization’s emails remain more secure.
DMARC, though it might not be perfect, is far and away the most advanced email authentication tool out there. As phishing and Business Email Compromise messages continue to pose a growing threat for organizations of all sizes, DMARC’s usage should be at the forefront of any company’s email protection.
What do you think? Is your organization still facing challenges in authenticating emails with DMARC? Comment your answers below.
DMARC record publishing will soon be a part of modusGate. Click here to learn more about our leading on-premise email security.
Leave a Comment