Understanding DMARC Better

I talk and present often about DMARC (and SPF and DKIM), including here. A lot of people who think they understand how DMARC works, do not really understand it as well as they think they do. This post is aimed to help clarify some common misunderstandings.

DMARC Basics

Domain-based Message Authentication, Reporting and Conformance (DMARC), Sender Policy Framework (SPF), and Domain Keys Identified Mail (DKIM) are related global anti-phishing standards that allow email receivers to verify if an email that claims to be from a particular domain is really from the domain it claims. In short, it helps to prevent domain spoofing. Email senders can use DMARC to protect their email domains from spoofing by spammers and phishers and email receivers can use DMARC to verify that emails were sent from the domains claimed. Every organization sending or receiving email should enable DMARC. If you are not sure if your organization has enabled DMARC for both sending and receiving, verify it.

All emails can have multiple sender email addresses (or types) attached to it in different places (some are easy to see, some are not). Although most of the time, all included email addresses are the same email address in most legitimate personal emails. Marketing, auto-reply, spam and phishing emails often have different email addresses listed in the various locations where email addresses are allowed in an email.

SPF verifies what is known as the RFC 5321 MAIL FROM/RECPT To email address domain. The 5321 email address is the address that auto-populates when you reply to an email (see example below).

DKIM verifies the RFC 5322 DISPLAY FROM email address domain (example shown below).

It is important to note that neither SPF or DKIM verifies the “Friendly From” email address which is often what a receiver might see and think is the “real email address”. The Friendly From email address can be anything the sender wants and does not impact the sending or receiving of an email.

So, SPF verifies one of the email address types, the RFC 5321, which a receiver normally does not see. DKIM verifies the RFC 5322 address type, which the receiver can normally see in the email summary. That is why you should always use SPF and DKIM if you can. Neither SPF nor DKIM cares about the “Friendly From” address type. Many receivers often think that SPF or DKIM involves the “Friendly From” address. It does not.

If you are interested in more information on the different types of email addresses, see here.

A sender’s DMARC policy tells a participating receiver detecting an email from a domain other than what is in its 5322 and 5321 email addresses, how to handle (e.g., reject, quarantine, pass along without modification); plus, it defines reports and diagnostic information. You do not need DMARC to have SPF or DKIM, but you must have either SPF or DKIM enabled, or both, in order for DMARC to work. If you are interested in learning more about DMARC, SPF or DKIM, watch this webinar.

Note: From here on out, when I state DMARC alone, I am referring to all three anti-phishing standards DMARC, SPF and DKIM, working in conjunction together.

Reading Email Headers

Understanding DMARC results involves viewing and interpreting email headers. Email servers and clients do this automatically for us, but you can manually inspect headers as well. All computer security practitioners should understand how to read email headers, although reading and understanding them can be daunting for people new to doing it. If you are interested in how to manually read and understand email headers, consider watching this webinar which covers forensically examining emails.

There are also a ton of free services that will parse email headers and make them a bit more understandable, removing all the unnecessary garbage text and highlighting the important information. Free email header analyzing services include:

• https://mha.azurewebsites.net/
• https://toolbox.googleapps.com/apps/messageheader/
• https://mxtoolbox.com/EmailHeaders.aspx

Consider using an email header analyzer if you are new to DMARC.

Pass or Fail

When DMARC is enabled for a participating sending domain, involved email servers and clients can check for DMARC-identifying information and then place a “Pass” or “Fail” in the incoming email’s header. There will be one Pass or Fail for SPF and one Pass or Fail for DKIM (if both are enabled). Here are some examples:

Here is an email with a Pass in the SPF value field:

Here is an email with a Fail in the SPF value field:

Here is an email header with a Pass in the DKIM value field:

Here is an email header with a Fail in the DKIM value field:

There can be a handful of other value options like None, Not Present, Error or some other value indicating that DMARC was not enabled or not configured correctly. But in general, email recipients (or more realistically, email servers and clients on behalf of email recipients) are looking for either a Pass or a Fail in the SPF and/or DKIM fields.

If a failure is indicated in SPF and/or DKIM fields, then depending on the sender’s DMARC policy or the email server’s or client’s settings, the involved failing email may be rejected and deleted, placed into a quarantine or spam folder, or accepted just like any other email. The receiving email server or client may also “mark” a failed email in some way that indicates its failure to the email recipient. Emails that fail DMARC checks are supposed to be treated as more suspicious and risky than emails that did not fail DMARC checks. Emails without DMARC enabled are usually not automatically treated as suspicious even though theoretically they should be.

There are a lot of reasons why a legitimate email sent by a good vendor could fail DMARC checks, including mistakes the sender makes with their DMARC configuration settings. This is very, very common. Still, any email that fails a DMARC check should be treated more suspiciously than an email that did not.

Pass or Fail Caveats

Pass or fail does not mean an email did or did not come from a malicious origination. SPF and DKIM simply ensures that if an email says it is from such and such domain(s), as indicated by the 5321 and 5322 email addresses, then it is or is not really from that domain(s). DMARC makes no interference about whether the involved domains, even if verified, will result in the email being legit.

It was mistakenly envisioned by some early on that emails passing DMARC checks would be less likely to be malicious, but this has not proven to be the case. Spam and phishing emails often have DMARC enabled and pass all the DMARC checks. All this means is that the 5321 and 5322 email address domains they claim to be from are where they are from. No more, no less. Today, a higher percentage of spam and phishers have enabled valid DMARC domains and their malicious emails pass DMARC checks, than legitimate email. Unexpectedly, spammers and phishers have adopted DMARC at higher rates than regular organizations.

Still, DMARC has been a huge success, in that when a phisher or spammer sends a malicious email, usually the email IS from the domain it claims to be from…it is just that the domain involved is not the same as the legitimate domain of the legitimate vendor. Thus, an email pretending to come from Microsoft might be sent by a domain called Micros0ft.com.biz instead of the valid Microsoft.com. DMARC really did not result in less phishing and spamming (something we had all hoped), but it did prevent spammers and phishers from sending emails from domains they did not legally have assigned to them.

Instead, phishers and spammers send their malicious emails from rogue domains they have created to send the malicious email campaigns. But if you check the DMARC status of those rogue domains, they pass the DMARC checks. The malicious emails really are from those domains. They just are not often the domains the user should associate with the legitimate brand name the spammer or phisher is posing as.

Here is a phishing email claiming to be from Netflix:

Here’s the DMARC section of that phishing email’s header:

You can see that this phishing email passed both SPF and DKIM checks. Yes, that phishing email is really from accountupdateyourinfos.com. It is not, however, from netflix.com, as a valid email from Netflix would likely be. Remember, Pass does not mean not malicious.

Here is another example, an email with part of its header claiming to be from Amazon.

A legitimate email coming from Amazon will have a domain of amazon.com, not googletopranking.org. What this email header is saying is that, “Yes, this email is from googletopranking.com”, according to the DKIM pass. The SPF “SoftFail” is a failure, which either way (Pass or Fail) is not a good thing. What we want to see from a legitimate Amazon email is SPF and DKIM Pass for the amazon.com domain. Nothing else is legit.

So, for now on, remember a DMARC Pass does not mean the email is or is not malicious. All it means is that the email is or is not from the domain it is claiming to be from (regardless of the branding in the text of the message). You cannot read into DMARC pass or fail values any more than that.

There are also many reasons why legitimate domains that pass DMARC checks may still be used to send malicious emails, including:

• Legitimate domains can be compromised and sending malicious emails
• Legitimate, authorized sender on behalf of legitimate domain can be compromised and sending malicious emails
• Phishing emails are sent by email addresses from large, public email providers such as gmail.com, hotmail.com, sendgrid.net, etc.

So, even when an email passes all DMARC checks, that does not mean a receiver should immediately trust it. If the email is unexpected and asking you to do something you have never done before (two high risk traits), verify the request using an alternate method (e.g., call a legitimate phone number or go directly to a legitimate website address), before performing. A little verification can go a long way to avoid damage.

DMARC, SPF and DKIM are great anti-phishing standards. When enabled on both the sender and receiver’s side, they prevent phishers and spammers from sending emails that claim to be from protected domains. This has forced malicious email senders to stop using legitimate domains of the legitimate brands they are pretending to be from. But do not automatically equate a DMARC pass with the idea that it means the email is not malicious. You do not know that. You still have to use commonsense and be wary of any email you receive. DMARC is just one additional check that can give you information in your search to determine the legitimacy of a particular email. And for that alone, DMARC is a good thing.