If you would like to read the other parts in this article series please go to:
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”
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:
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:
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]”
In the record above we have the following explicit tags:
|p||none||Policy to apply to email that fails the DMARC check. Can be “none”, “quarantine” or “reject”. None is used to collect feedback and gain visibility without impacting existing flows.|
|Rua||mailto:[email protected]||The list of URIs for receivers to send XML feedback to. Note that this is not a list of email addresses, as DMARC requires a list of URIs of the form “mailto:[email protected]”.|
And the following implicit tags (defaults if not declared):
|adkim||r||Specifies Alignment Mode for DKIM signatures. “r” is for Relaxed and “s” is for Strict. Relaxed mode allows Authenticated DKIM d= domains that share a common Organizational Domain with an email’s header-From: domain to pass the DMARC check. Strict mode requires exact matching between the DKIM d= domain and an email’s header-From: domain.|
|Aspf||r||Specifies Alignment Mode for SPF. “r” is for Relaxed and “s” is for Strict. Relaxed mode allows SPF Authenticated domains that share a common Organizational Domain with an email’s header-From: domain to pass the DMARC check. Strict mode requires exact matching between the SPF domain and an email’s header-From: domain.|
|Sp||p= value||Policy to apply to email from a sub-domain of this DMARC record that fails the DMARC check. This tag allows domain owners to explicitly publish a “wildcard” sub-domain policy.|
|Fo||0||Forensic reporting options. Possible values: “0” to generate reports if all underlying authentication mechanisms fail to produce a DMARC pass result, “1” to generate reports if any mechanisms fail, “d” to generate report if DKIM signature failed to verify, “s” if SPF failed.|
|Ruf||none||The list of URIs for receivers to send Forensic reports to.|
|Rf||afrf||The reporting format for individual Forensic reports. Can be either “afrf” or “iodef”.|
|Ri||86400||The reporting interval for how often you would like to receive aggregate XML reports. You will likely receive reports once a day regardless of this setting.|
|Pct||100||The percentage tag tells receivers to only apply policy against email that fails the DMARC check X amount of the time. For example, “pct=25” tells receivers to apply the “p=” policy 25% of the time against email that fails the DMARC check.
NOTE: you must have a policy of “quarantine” or “reject” for the percentage tag to do anything.
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:
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
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:
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:
- A message is sent from an Internet sender to a user in Office 365;
- Because MX records point to on-premises, the message is delivered to an on-premises Exchange server;
- After performing a lookup on the user, an on-premises Hybrid server forwards the email to EOP;
- 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.
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:
Note that there is no dkim under auth_results as I have not yet implemented DKIM.
These reports include three sections:
- 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.
- DMARC Record
- 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:
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: