DKIM and DMARC in Office 365 (Part 3)

If you would like to read the other parts in this article series please go to:

• DKIM and DMARC in Office 365 (Part 1)
• DKIM and DMARC in Office 365 (Part 2)

Implementing DMARC

As I have mentioned in the previous parts of this article series, Office 365 already fully supports inbound validation of DKIM with outbound DKIM signing coming really soon. As such, and at the time of writing this article, all we can do for now is set up DMARC records.

First, we need to have an SPF record in place (remember that we cannot have a DKIM record yet). For my nunomota.pt domain, I have the following SPF record already in place: “v=spf1 include:spf.protection.outlook.com –all”

Figure 1

This states that only Office 365 is allowed to send emails from nunomota.pt. Any mail from this domain being sent from anywhere else will cause the SPF check to fail (unless the IP is spoofed of course). To verify this, I sent an email from my on-premises deployment to a mailbox in my Office 365 tenant and confirmed it indeed failed:

Figure 2

Also notice the dmarc=no, meaning there is no DMARC record available for the nunomota.pt domain.

Now, we need to set up a DMARC record. So let us start by publishing a DMARC policy with action=none so we can collect data first. Below is Microsoft’s DMARC record published at the TXT record for _dmarc.microsoft.com:

Figure 3

As you can see from the screenshot above, Microsoft is not currently enforcing any action. It is simply monitoring and sending its DMARC reports back to Agari, a 3rd party organization.

In my case, I have created the following DMARC record: “v=DMARC1; p=none; rua=mailto:[email protected]”

Figure 4

In the record above we have the following explicit tags:

Table 1

And the following implicit tags (defaults if not declared):

Table 2

Once this record is published, all receivers who support DMARC, including Office 365, will start checking DMARC and sending reports. If I run the same test again and send an email from a @nunomota.pt user from my on-premises Exchange to a mailbox in my Office 365 tenant, DMARC will now fail (because I now have a DMARC record and because SPF fails). Also notice the action set to none:

Figure 5

A difference in the way Office 365 implements DMARC is how it treats messages that fail DMARC for inbound messages. If the DMARC policy says p=reject, EOP will mark the message as spam instead of rejecting it, meaning it will treat p=reject and p=quarantine the same way. This is because there is some legitimate mail that fails DMARC. For example, sending mail to mailing lists which is relayed to all list participants. This type of mail will still fail DMARC but it will be marked as spam. Users can still get them to their inboxes by adding safe senders or by administrators creating Exchange Transport rule (ETR) for those particular senders. When the DMARC Working Group adds support for these types of messages, EOP will support it. But for now, this is simply how it is.

Although they are treated the same way, we can still distinguish them as EOP will set the Phishing Confidence Level to 8 in the event that a message fails DMARC with a reject action, meaning the message is a phish. This is stamped in the X-MS-Exchange-Organization-PCL header and in the X-Microsoft-Antispam: PCL:8 field. What this will do when this feature is implemented is disable functionality within the message such as Reply, Reply All, Attachments and Links so the user cannot take action on it. The reject action is supposed to keep messages away from users. EOP cannot keep these away completely, but disabling features of the message is close to achieving the same thing. For now, at least for my tenant, the X-MS-Exchange-Organization-PCL is not yet set for this scenario.

Additionally, in these cases EOP overrides the p=reject action and indicates it has done so in the headers by putting an oreject into the action=<action> field, such as: dmarc=fail action=oreject

Figure 6

This means that the message failed DMARC and the policy was p=reject, but EOP overrode the action and marked it as spam instead. As mentioned above, a safe sender or ETR can still override this.

As to Gmail, when the action is set to quarantine, it places the email in the user’s Spam folder. When the action is set to reject, it simply drops the email and sends the following NDR back to the sender:

Figure 7

Hybrid Environments

A scenario to keep in mind is for organizations running an Exchange Hybrid deployment where MX records point to on-premises and not to EOP. In this case, DMARC failures are not be enforced by EOP because if they were, customers would receive a huge number of false positives. Why? Let’s think about it:

1. A message is sent from an Internet sender to a user in Office 365;
2. Because MX records point to on-premises, the message is delivered to an on-premises Exchange server;
3. After performing a lookup on the user, an on-premises Hybrid server forwards the email to EOP;
4. SPF fails because the connecting IP (to EOP) is not the original IP but the IP of the on-premises Hybrid server.

Also, when a message fails DKIM it does not necessarily mean it did so because of a DKIM forgery. This could have happened because an older version of Exchange modified the message’s content, which breaks DKIM body hashes. Unfortunately EOP cannot distinguished between a modification in transit and a malicious spoof of DKIM.

As SPF fails, and because DKIM can also fail, EOP will not enforce DMARC failures if an organization’s primary MX record does not point to EOP (this is all due to routing). EOP can still detect if a message passes DMARC when the DKIM-signature passes.

DMARC Reports

Finally, let us look at what a DMARC report looks like. Here is what you can expect:

• The participating mail provider will send daily reports via email based on what you defined in the “rua” tag;
• These reports will be MIME formatted messages and will include an XML file contained in a zip file;
• The reports include data about messages that passed and/or failed DMARC.

The following is an example of a DMARC report with an action of none:

Figure 8

Note that there is no dkim under auth_results as I have not yet implemented DKIM.

These reports include three sections:

1. ISP information:
   • Mail provider name (google.com);
   • Mail provider’s sending email address and additional contact information ([email protected]);
   • Report ID number (4760398061289808876);
   • Beginning and ending date range in seconds (from 1424563200 to 1424649599). These numbers are seconds since “epoch”. Epoch, also known as Unix timestamps, is the number of seconds that have elapsed since January 1, 1970 at 00:00:00.
2. DMARC Record
3. Summary of authentication results. This is the important part (look for the areas that show neutral, none, or failed results):
   • IP identified in the legitimate and/or fraudulent email (154.xxx.xxx.xxx);
   • Count of IP address identified (6);
   • From domain (nunomota.pt);
   • DKIM authentication results lists the domain and result (again, no DKIM here as I have not yet implemented DKIM);
   • SPF authentication results lists the domain and result (neutral, pass or fail).

The following is a similar report but with an action of reject:

Figure 9

Conclusion

In this article series we looked at what DKIM and DMARC are and how they work in Office 365.

If you would like to read the other parts in this article series please go to:

• DKIM and DMARC in Office 365 (Part 1)
• DKIM and DMARC in Office 365 (Part 2)