DMARC Office 365

If you’re an Office 365 admin, you’ve doubtless heard of Domain-based Message Authentication, Reporting & Conformance (DMARC). Maybe you’ve wondered how it contributes to an organization’s email security. So what is DMARC? In short, it’s an email authentication protocol for validating the use of the domain in the visible From header and enabling reporting. To dive deeper into these concepts, here are some articles to check out:

• What is DMARC? 
• SPF Syntax 
• DMARC vs. DKIM.

Organizations are scrambling to implement the best defenses and investing more in cybersecurity; no one wants to be left behind. This article will equip you with the requisite knowledge to use DMARC with your Office 365 setup. Additionally, we’ll demystify DMARC, so you sufficiently understand why your Office 365 mail setup benefits from deploying DMARC.

Let’s start by looking at how DMARC works to make email safer before we show you how to set it up with Office 365.

Why Set up DMARC with Office 365?

There are two fundamental reasons to use DMARC: policy enforcement and reporting. In this section, we’ll look a little closer at what exactly those are while pointing you to some excellent resources to go further into certain specifics outside the scope of this article. 

Policy Enforcement with DMARC

Suppose that you have a domain set up with email, and maybe even some other email security mechanisms in place, like DKIM and SPF. By implementing a DMARC policy, you can provide a single point of authority for enforcing what should happen if an email fails your SPF or DKIM policy. 

To analyze an existing example, let’s look at a DMARC policy in the wild. To that end, we can use Valimail’s Domain Checker utility to investigate the DMARC record of gmail.com to see how it suggests what recipients should do with an email that’s not in alignment.

Let’s break it down part by part and see the enforcement policy. The first element is simply the version number; we can ignore that. The last one (rua) is for reporting, which we’ll touch on in the next section. For now, we’ll focus on the two in the middle: p=none and sp=quarantine. What do these do?

The former, p=none, means that if an email fails DMARC validation, then the domain owner requests that no specific action be taken regarding delivery of the message. But if it comes from a subdomain of gmail.com, it should be quarantined. According to RFC 7208, this means the domain owner wishes to have the email be treated by Mail Receivers as suspicious. Depending on the capabilities of the MailReceiver, this can mean “place into spam folder”, “scrutinize with additional intensity”, and/or “flag as suspicious”.

A third policy enforcement option that is not present in Gmail’s policy is p=reject, meaning the domain owner requests that noncompliant mail should not even arrive in the recipient’s inbox. When preventing fraud and phishing, this is a reasonable option, but many admins prefer quarantine over reject, so mail still arrives in some capacity. The reason is that sometimes legitimate mail fails an outdated or misconfigured security check, and quarantining is a nice middle ground rather than rejecting outright. 

Reporting with DMARC

DMARC goes beyond enforcement by providing visibility into emails using the domain in the visible From header. Remember that rua tag we mentioned earlier? It points to a URI. When recipient servers receive an email from your domain that fails DMARC, you’ll have insight into this via periodic aggregate reports. These reports come in xml format and look like this:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>example-recipient.com</org_name>
    <email>noreply-dmarc-support@solarmora.com</email>
   <extra_contact_info>http://example-recipient.com/dmarc/</extra_contact_info>
    <report_id>8782497923</report_id>
    <date_range>
      <begin>123557113</begin>
      <end>123453224</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.209</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <result>fail</result>
        <human_result></human_result>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

The report is pretty human-readable, even though it’s intended to be machine-parsed. In the above example, we see that the report is sent from example-recipient.com to yourdomain.com. The report informs us of the outcome of a DMARC check for an email sent from the IP 203.0.113.209. It passed SPF, but failed DKIM. Although the email should be delivered, because the policy is none, the domain still receives a report!

The report provides visibility that enables you to do the following:

1. Gain insight into ongoing phishing, fraud, and other abuse.
2. Debug issues with SPF and DMARC by seeing if any mail fails when it should succeed.

To learn more about DMARC tags, what they do, and how to use them, check out the brief article DMARC: The only three tags you need, which is a great primer.

How to Deploy DMARC in Office 365

Armed with a better appreciation for the benefit that DMARC offers to your email security posture, let’s get to the exciting part. How do you deploy it with Office 365 and start taking advantage of increased security and visibility?

Setting up DMARC to work with Office 365 is, at first glance, very simple. Simply add the appropriate DMARC policy as a TXT record in your DNS setup. If you want a policy to reject everything with no reporting, then that is all there is to it. 

However, what if you’re setting up SPF and DKIM as well as reporting? In that case, DMARC itself is just the icing on the cake. In the article  Set up DMARC for outbound mail from Microsoft 365 from Microsoft’s official documentation, the process of setting up DMARC with Office 365 is divided into four steps, which we’ll summarize here:

1. Identify valid sources of mail for your domain

Even if you already have SPF deployed, there are additional considerations when setting up DMARC. Specifically, you need to ask yourself two questions. First, what IP addresses send messages from my domain? And second, for mail sent from third parties on my behalf, will the 5321.MailFrom and 5322.From domains match?

2. Set up SPF for your domain

At this step, the Microsoft docs link to an additional resource: Set up SPF to help prevent spoofing. Also note that as a best practice, you should ensure that your SPF TXT record takes into account third-party senders.

3. Set up DKIM for your custom domain

And as usual, Microsoft links to a dedicated resource for learning more about setting up DKIM with your custom domain, in the article Use DKIM to validate outbound email sent from your custom domain. Perhaps the most important take away is this quote:

If you have third-party senders that send mail on your behalf and the mail they send has mismatched 5321.MailFrom and 5322.From addresses, DMARC will fail for that email. To avoid this, you need to set up DKIM for your domain specifically with that third-party sender.

– Use DMARC to validate email. Step 3: Set up DKIM for your custom domain

Consult the documentation for full instructions on setting up DKIM with third party senders and thus averting this issue.

4. Form the DMARC TXT record for your domain

This section briefly explains the essential syntax elements of a DMARC DNS record, such as the v (version) and p (policy) tags we explored earlier in this article. One interesting insight from this section is how DMARC applies to subdomains:

By default, the record protects mail from the domain and all subdomains. For example, if you specify _dmarc.contoso.com, then DMARC protects mail from the domain and all subdomains, such as housewares.contoso.com or plumbing.contoso.com.

This is convenient for preventing abuse of arbitrary subdomains, but you are also free to create distinct policies for individual subdomains if you wish to.

Microsoft also maintains an excellent guide illustrating DMARC best practices in the context of Office 365 here: Best practices for implementing DMARC in Microsoft 365.

We should also say one more thing about reporting. We’ve shown you how to add a URI to receive reports, but how do you set up that URI? That’s where third-party services come into the picture. Valimail Monitor, for example, offers free DMARC visibility in the form of Monitoring aggregated DMARC reports.

Although the service is third-party, its integration with Office 365 is officially supported by Microsoft. The official Microsoft 365 Youtube channel has a video explaining how Valimail integrates with its products:

https://www.youtube.com/watch?v=zPAeM1gsDr8

With this setup, reports should begin appearing within 72 hours. If your org has a Security Operations Center (SOC) or Security Information and Event Management (SIEM), you can link your DMARC reports into your broader security reporting context. Otherwise, regularly visiting the dashboard of a visibility solution should give you a good bird’s eye view of bugs and abuse.

Conclusion

DMARC gives admins a system for requesting handling for messages where the domain’s use in the visible From cannot be validated. Moreover, we get a fantastic reporting tool extending visibility into misconfigurations of DKIM, SPF, and DMARC itself. This makes DMARC a great addition to the Office 365 analytics you may already have in place, and that visibility can be accomodated using tools that have an official partnership with Microsoft, like Valimail Monitor.

When a mail sent from your Office 365 fails DKIM and SPF, DMARC can suggest the email be rejected entirely, or it can recommend quarantining it, or allowing it to arrive normally. In the latter case, we still get a report, providing immense value for detecting bugs. Even if you don’t send email from your domain, attackers can still try to fraudulently send email from it, making DMARC useful nevertheless.

Deploying DMARC can be dangerous, but as admins, the principle of deploying incrementally and initially implementing softer policies should be nothing new. By setting up properly and following the advice laid out above, you’ll enjoy the security configuration and reporting benefits of DMARC in no time.