Office365 is an incredibly sophisticated business platform offering powerful capabilities supporting the needs of today’s mobile workforce with minimal investment and run cost.  As is common with any software subscription model, responsibility for maintaining and enforcing security controls protecting your O365 accounts is shared between Microsoft and the Subscriber.  While there is a plenty of information guiding implementation of common sense best practices, such as multi-factor authentication, logging, and monitoring, there is little in regard to DMARC enforcement. 

 

To begin with, email sending, receipt, and delivery across the internet is built upon several open standards published by the Internet Engineering Task Force.  Among these are mechanisms by which a domain owner may authorize one or several systems to send email on behalf of their email domain.  Available mechanisms have evolved from basic access lists to more advanced digital signatures verifiable by receiving email systems.  Additional capabilities were also introduced that provide domain owners visibility into authentication results for their email domain and a facility to publish email delivery policies instructing receiving  systems to take action when authentication checks do not provide a pass result.

 

For those technical readers, the standards I’m referring to include Sender Policy Framework(SPF), Domain Key Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance(DMARC).  As with any technical standards, challenges exist in interpretation, implementation, and interoperability.  Receiving email system vendors have implemented these standards as informed by their individual interpretations and implementation decisions.  This results in varying behaviors per email receiver for the same use-case and conditions.  Of specific interest for this article is DMARC and Microsoft Office 365’s similar treatment for either quarantine or reject policies. 

 

Summarizing before delving into the detail, we would normally expect that an email failing DMARC authentication when claiming to be from a domain publishing a reject policy would be rejected by the receiving system and never delivered to the intended recipient.   We would also expect a similar email failing DMARC authentication when claiming to be from a domain publishing a quarantine policy may be quarantined at the receiving email gateway or could potentially land in the recipients SPAM folder.  Unfortunately, the Office 365 implementation for dispositioning delivery based on DMARC policy does not align with these expectations.  In either case of a published reject or quarantine policy, Office365 delivers the message to the intended recipients SPAM folder, creating opportunity for an advanced attacker to follow a well crafted Phishing attack with a well executed Vishing attack, leaving your users more vulnerable than they should be.

 

Although this is the default behavior, there is a very simple and effective way to enable your Office365 account to respect published DMARC reject policies.  Using the well documented mail transport rules available in Office365, a configuration to explicitly reject messages failing DMARC authentication before they land in your users Inbox may be enabled.  The remainder of this article covers the technical details required to complete the implementation.  If you are a non-technical user reading this email, and you made it this far in the reading, congratulations!  I suggest you forward this to your technical teams so they may review and advise on implementation for your organization.

 

From <https://docs.microsoft.com/en-us/office365/securitycompliance/anti-spam-message-headers>

 

How Office 365 handles inbound email that fails DMARC

If the DMARC policy of the sending server is p=reject, EOP marks the message as spam instead of rejecting it. In other words, for inbound email, Office 365 treats p=reject and p=quarantine the same way.

Office 365 is configured like this because some legitimate email may fail DMARC. For example, a message might fail DMARC if it is sent to a mailing list that then relays the message to all list participants. If Office 365 rejected these messages, people could lose legitimate email and have no way to retrieve it. Instead, these messages will still fail DMARC but they will be marked as spam and not rejected. If desired, users can still get these messages in their inbox through these methods:

• Users add safe senders individually by using their email client
• Administrators create an Exchange mail flow rule (also known as a transport rule) for all users that allows messages for those particular senders.

 

From <https://docs.microsoft.com/en-us/office365/securitycompliance/use-dmarc-to-validate-email>

 

 

The following screenshot documents a configured mail Transport rule that interrogates the Authentication-Results message header for a matching value of dmarc=fail and the Microsoft transformed value action=oreject.  Using this configuration, we are able to effectively enforce published domain DMARC reject policies in our Office365 tenant.

 

Domain-based Message Authentication, Reporting, and Conformance (DMARC) provides organizations a mechanism to both publish email authentication policies and collect feedback on performance of those policies. Using valid DMARC mechanisms,  organizations may instruct receiving email gateways to quarantine or reject emails failing underlying Sender Policy Framework (SPF) and Domain Key Identified Mail (DKIM) checks.  This is a fantastic control that is increasing in popularity; however, control effectiveness relies purely on the email receiving systems enforcement of published policies.

Given the above, the next logical question you may have is How does Office 365 enforce published DMARC policies?  I’m glad you asked, and my answer is Unsatisfactorily.  Office 365 dispositions email failing both SPF and DKIM authentication for a domain publishing either a DMARC quarantine or reject policy the same!  Although organizations have invested in the right control and achieved a level of maturity allowing them to be confident in publishing a reject policy, Office365 says Nah, we’ll just put it in the SPAM folder just in case you didn’t mean to publish that reject policy.  Dispositioning as SPAM creates opportunity for an attacker to follow a well crafted Phishing email with a well crafted Vishing attack, and leaves your organization more vulnerable than they should be.

Do not despair!  Where there is  a will, there is a way!!  There is a very simple and straight forward configuration which you can apply against your Office365 account to enable true rejection of emails failing DMARC authentication where the sending domain publishes a reject policy.  If you are non-technical, I suggest you read no further and forward to your tech team for their review and implementation advice.