Research from Valimail indicates that domains lacking DMARC enforcement are nearly 4X more likely to get spoofed — how Microsoft’s new feature could help differentiate junk from legitimate emails
Hey friends. I’m back for yet another email-related discussion. Email is an extremely utilized and important tool for communication across not only businesses and organizations across the world but for personal use as well. Approximately one-third of the population of the planet has an email address. This is why it’s essential for every organization protects their domains to ensure that no one impersonates them via email.
This is where DMARC, or what’s known as domain-based message authentication, reporting and conformance, comes in handy. But not everyone uses DMARC, even though it provides protection against email phishing and spoofing. This means that when Microsoft releases its new Office 365 feature that will give organizations the option to block emails from senders whose domains lack DMARC authentication mechanisms, those non-DMARC authenticated organizations are going to be in trouble.
So, what is there to know about this new Office 365 update and how will it affect your email capabilities?
Let’s hash it out.
Breaking Down Microsoft’s New ATP Feature for DMARC Authentication
Okay, so Microsoft is doing what now? Microsoft recently announced that they’re looking to roll out a new advanced threat protection feature across all Office 365 environments that aims to block any email senders whose domains fail DMARC authentication. The new Office ATP feature is anticipated to roll out around April 2020.
Basically, what this means is that Microsoft plans to incorporate an additional type of filter into their email process/lifecycle that’s based off of domain message authentication, reporting, and conformance (DMARC) validation policies. This means that, quite simply, if DMARC fails for an email, the message will be filtered.
Of course, there’s an option for an admin (likely via the Office 365 admin console) to turn this off and disregard the DMARC status per email. Like most issues, this function, whether on or off, has advantages and disadvantages to consider. But, like many well-thought-out things that are sent to production, the pros will likely still outweigh the cons. But before we can get into a more in-depth discussion about what all of this means, let’s first take a moment to review DMARC, SPF, DKIM, and other considerations.
What is DMARC, SPF, and DKIM, and Why Do They Matter?
DMARC is a reporting tool that takes metrics from two other protocols — sender policy framework (SPF) and domain keys identified mail (DKIM) — to determine the authenticity of an email, and data gathering can determine how well an email sender’s domain is doing. DMARC can also take action on emails based off of SPF and/or DKIM results.
DMARC reporting will describe how the domain(s) are doing as a whole. Examining the data in different timeframes can help you determine if things are getting worse before further sleuthing can help determine what might be going on.
SPF is both a protocol and a very simply configured DNS entry in a DNS record. It’s essentially a listing of hostnames, IP addresses or range of addresses that can be set as valid sending sources. What this means is that if an email comes from an IP/hostname other than what is listed in the DNS’s TXT SPF record, it’ll fail.
DKIM, on the other hand, is a protocol that uses one DNS entry per valid sender to utilize a key signature in outbound emails. So, what this means in layman terms is that email clients (and mail exchangers) will verify the email based off of the DKIM signature and the lookup in the DNS record. If the key is legit (according to the DNS entry), DKIM passes.
So, essentially, DKIM and/or SPF are good for one-off situations, whereas DMARC is useful for authenticating against those standards to ensure validity of an email domain. Of course, this is an oversimplification of these protocols. We didn’t even go over the weighted results of valid vs aligned. For more information on that, you can go back and read my previous articles discussing all the different options and so forth. (Note: Links to each of those specific topics are embedded in the individual paragraphs above.)
How Is Filtering for DMARC Different Than Filtering for SPF, DKIM?
Categorization with SPF is based on the defined IP addresses and/or host names. There are qualifiers that can be placed — and are placed — for anything not matching the defined IP addresses and/or host names. Typically, using the “all” statement at the end of the SPF TXT record indicates this. The qualifiers are:
- Pass (+) — Passes when criteria is met
- Fail (-) — Fails when criteria are met and flag as spam
- Soft Fail (~) — Fails but takes no action
- Neutral (?) — Take no action at all
DKIM is a little less hands-off in that regard. However, it may depend on the email client, such as Outlook, MacMail or Thunderbird, or it will depend on the DMARC policy to filter out the message.
So, basically, SPF and DKIM do pass/fails and note it as such. It is up to the exchangers, servers, and email clients to figure out what, if any, action to take (deliver, spam it, delete it, etc.).
DMARC, which is a composite of SPF and DKIM results but also has extra capabilities beyond that, will utilize the results of each protocol to take action. Those next steps could be filtering (flagging as spam) or simply just marking the message as bad (noted as a failure but not flagged as spam). It has options that can require one or both to pass, or it may require both to be aligned. Those DMARC options can flag a message, soft fail it, etc.
DMARC’s real strength comes from its reporting and domain alignment features. When lots of emails are sent, DMARC is a great way to see how much spoofing or problems an email domain is having. DKIM and SPF are good for handling the single anecdotal instances, but DMARC can help with the bigger picture.
Why We Use DMARC (and Why You Should, Too)
According to research from Valimail, domains without DMARC in place are nearly four times as likely to get spoofed. So, this is where DMARC — and its components SPF and DKIM — comes to the rescue.
So, you possessors of email addresses and inboxes, I know that you understand the attacks that we (as businesses) are constantly under — the flooding of phishing and junk mail that inundates our inboxes on a milli-second basis. Our email clients do a subjectively good job filtering stuff out. (Well, they actually do do (heh) a good job filtering stuff out. It’s the 1(ish) % of junk that does get through that seems to stand out and makes us super frustrated.) However, they’re not enough.
I’ve mentioned in the past that we need to jump through the hoops, do our due diligence and fight the good fight to improve all of our email to junk/phishing ratios and situations. Some of my previous articles go over these tools and actions that should improve those ratios/situations. I have good reason to believe it has improved my company’s ratios and situations.
Why Should You Care So Much About This?
One concern that we have as a for-profit business is the amount of emails that we send out to customers and prospective customers. We have a reputation to uphold, after all. We want to make sure our customers know it is actually us trying to communicate with them and not an imposter.
Here Are a Few Thoughts About Microsoft’s New Filtering Tool
When I read articles about Microsoft’s announcement, several considerations came to mind that I’d like to share:
Not Adhering to DMARC Compliance Doesn’t Necessarily Equate to Being Invalid
By definition, emails that fail SPF and/or DKIM need to be highly questioned. It doesn’t necessarily mean that a message that isn’t sent from a DMARC enabled domain isn’t valid. However, it’s up to the administrators or email domain/inbox owners to make sure that all possible sources to be used to send email are included in SPF and DKIM domain name system (DNS) definitions.
Allowing software to do a bunch of the heavy lifting is what software is all about. Having 365 block failed DMARC policy emails will certainly help with the filtering. And, it allows for the user to not have to think about it. Unless, there is some sort of problem and they actually need certain failed emails to come through.
Microsoft’s Rollout Could Encourage (or Discourage) the Use of DMARC
Strictly from the DMARC perspective, this may encourage businesses and other entities to setup SPF, DKIM and DMARC. One might look at it as a dissuasion, though, as a mess up in the structure could potentially lead into false positives.
It appears that Microsoft is looking for a DMARC fail in order to block messages. But, if an email sending entity doesn’t have DMARC and its components set up, wouldn’t the result just be “Not Applicable?” Seemingly, “Not Applicable” should pass through because Microsoft is looking for “Fails” results only. So, the criteria for an email to pass through the filter would be a DMARC “Pass” or “Not Applicable” result. Achieving the latter status for DMARC is significantly less work than achieving a “Pass” status.
If this were, indeed, the case, I suspect that it would be a short-term thing and would lead to more email-sending entities setting up DMARC to get on that pass list. Perhaps the “Not Applicable” status may find itself coupled with the “Fail” side in the future. Or, perhaps, the option may be set on a per-account basis.
Use of Microsoft’s DMARC Filter Feature Is Ideal, But It’s Still Optional (for Now)
It almost makes it seem like we are dealing with the HTTP vs HTTPS shift here where, eventually, it’s in the clear best interest for all public facing websites to use HTTPS because the public aren’t going to want to deal with the uncertainty of HTTP. As such, it’s in the clear best interest for email sending entities to set up SPF, DKIM and DMARC to prevent spoofing and to give their recipients the warm fuzzies.
Here is a Final Thought About This DMARC Filtering Option
Ultimately, I think Microsoft’s new Office 365 feature is a good thing and may help set a standard for preventing and squashing mail fraud and so forth in the future. DMARC is fairly young in its inception, and I’m sure that there will be improvements and standards instilled to make it even more effective.
We all know that the scammers and ne’er-do-wells are continuously thinking of new and creative schemes to attack us. One thing that I would like is a way to associate display names to email addresses better and filter on user-defined mismatches. Falsifying the display name to the sending address is a clever way to attack people. Way off topic, but an example of this is when you get an email from, say, the CEO and it says he needs money and deposit into so and so account. The display name in the email is correct but the email address is something else completely different.
We should be able to natively set up the association and, if the display name is X and the email address is anything other than Y, drop the email. Okay, tirade over.
Anyway, I hope this was helpful and, as always, stay safe, wash those COVID-19 riddled hands, and happy scrutinizing!