Microsoft Brings Improvements to DMARC

Preparing for Battle

Email defense is similar to a suit of chainmail armor that protects the wearer from attackers. Like most defenses, they also are in need of maintenance, repairs, and upgrades, which then provide a consistent defensive posture. In this vein, Microsoft’s recent changes to its email service are no different. Like the chainmail armor, which protects the wearer from attacks like knives, swords, and more, Microsoft’s solution defends against email attacks consisting of spam, malicious links, macros, and spoofing. The focus of this article will revolve around one component, DMARC (Domain-based Message Authentication, Reporting, and Conformance), which administrators can set up with their Exchange Online service and protect against spoofing. With DMARC records, there are three policy levels to be mindful of, and administrators should be prepared to set them properly so DMARC does its job.

DMARC and Email Defense

About 90% of attacks are based on fake Sender Identification (between branding and individuals), and Email Authentication checks are used to prevent these fakes from making it through. A faked email is one that is spoofed by an unauthorized mail-sending server and then sent to unsuspecting parties hoping they will click on a malicious link, open an attachment, or run some code to compromise a computer. Email Authentication consists of SPF, DMARC, and DKIM DNS records which email servers/systems used to authenticate or validate the authenticity of the sender of the message. Properly configured DMARC allows for good email authentication as well as boosting the reputation of the sender as a good/trusted sender.

Anatomy of a DMARC Record

Let’s quickly review the parts that make up a DMARC record, as we’ll need to understand these to implement Microsoft’s changes. Below is a sample record used in the service:

v=DMARC1; p=reject; 
rua=mailto:dmarcreports@mydomain.mail.onmicrosoft.com;ruf=mailto:dmarcreports@mydomain.mail.onmicrosoft.com pct=100

Explanation of the DMARC record sample:

v=DMARC1 – is the required portion used to declare the version of DMARC used, and DMARC1 is the latest/only version.

p=reject – DMARC has three levels of enforcement when servers are authenticating:

• None: DMARC is configured, but no enforcement occurs, which essentially means DMARC is off. Still reported in DMARC reports.
• Quarantine: Suspect emails should be Quarantined for safety, but it is up to the recipient’s mail system for final determination.
• Reject: Emails that fail authentication should be rejected outright.

rua=mailto:dmarcreports@mydomain.mail.onmicrosoft.com – This value designated an SMTP address to receive aggregate reports back from DMARC-compliant mail servers.

ruf=mailto:dmarcreports@mydomain.mail.onmicrosoft.com – This value designated an SMTP address to receive DMARC failure reports.

pct=100 – This Value is the percentage of email to be surveyed and reported back to the domain owner.

For DMARC to pass, there needs to be a proper alignment with SPF and DKIM records which means that the ‘FROM’ domain in the email needs to be the same as the SPF and DKIM records. Additionally, two different alignments exist – Strict and Relaxed. Relaxed is the default value for alignment and simply means the domain references can be the same or even a subdomain. With Strict alignment, the values must be the domain, and no subdomain matching is allowed. 

DMARC records can be added for the tenant-level domain (*.onmicrosoft.com) here.

Microsoft’s Documentation on DMARC implementation

MC543870: DMARC aggregate reports for enterprise

MC543870 puts Microsoft on track to meet RFC standards in regard to DMARC reporting, where tenant owners can now receive DMARC reports for their tenant domains. This can be done via the Microsoft 365 Admin Center –> Settings –> Domains. Select your tenant domain (*.onmicrosoft.com) and then add a DNS record of ‘_dmarc’ with your specific information: (see the previous DMARC record above for an example).

DMARC reports are XML files sent to the RUA address designated in a DMARC record and look something like this:

<record>
    <row>
      <source_ip>143.55.232.2</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_to>mydomain.com</envelope_to>
      <envelope_from>myseconddomain.com</envelope_from>
      <header_from>mydomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>pmyseconddomain.com</domain>
        <selector>krs</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>myseconddomain.com</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

Using a free service like MxToolbox, we can quickly make sense of this record and any others in our XML report, as seen in Figure 1 below:

Using a service to translate the XML will make the analysis and reaction part of an administrator’s job much faster.  Some enterprises use more automated solutions that ingest these DMARC reports directly, process the data, and produce more advanced reporting and/or action items for an administrator. These services are worth it for larger environments that contain numerous domains and wish to maximize an administrator’s time by reducing time spent.  Example services such as Dmarcian, SendMarc, and Valimail will do this for various fees. While we do not endorse any one vendor with this article, services like these exist and provide valuable results, historical data, and future tasks for improvement.

Why is This Important?

For those that manage tenant/email flow, knowing who is sending emails as you can be important. Many organizations do not know all of the legitimate third-party email solutions that send emails on their behalf, let alone are aware of the many malicious actors out there that are sending bad emails on their behalf. DMARC reports are a window into this world and enable administrators to get an idea of both the good and bad senders for their domains. Reviewing these and the data revealed can truly be an important task. If too much data is present, a third-party analysis service may be worth it.

MC516348: DMARC Policy Handling

Earlier, I mentioned that there were three levels of DMARC policies (None, Quarantine, and Reject). Microsoft has recently made a change where they will start honoring the p=Reject setting as they were not previously doing so. Configuring DMARC to reject as a policy if email authentication fails is where tenant admins can fill the hole in our chainmail armor used for email defense. By honoring the rejection, emails that do not pass authentication can be rejected instead of either passing through (p=none) or being quarantined (p=quarantine). The setting of Reject will thus block spoofing attempts by email servers not authorized to send email for the tenant’s domains. 

Why is the ‘p=reject Policy Important?

Without the ‘p=reject’ policy setting, spoofing can still occur, and these malicious emails will impersonate companies and possibly cause reputational harm. Now that Microsoft will honor this value, those that use Office 365 will be able to use the RFC-compliant feature. Some companies will still hesitate to set a Reject setting, which isn’t something I would advise. Plan on setting your p record to p=Quarantine first, turn on DMARC reporting, analyze the reports to see if you have any possible conflicts, and then set the DKMARC policy to p=Reject. The only time setting p=reject would cause an issue is if your other email authentication components are not configured correctly.

Time to Armor Up

A suit of chainmail is made up of a series of metal rings that work together to protect the wearer from attackers and in that sense, Microsoft’s email defense is made up of many different features and products to protect email users. By adding additional functionality to existing features, Microsoft is improving their (fixing missing or damaged sections) chainmail to better defend end users from external attackers. Both of these changes should be welcomed by organizations in the Microsoft 365 service.