Using DMARC in Office 365

Exchange Online Protection (EOP), also known as Office 365, will soon be supporting DMARC for authenticating email which is a feature designed to combat phishing and spoofing of email. If you’re unfamiliar with DMARC, here are a few links that explain it:

You can read through any number of the above links to see how DMARC works. Office 365 does things a little bit differently as I will explain below.


How to enable DMARC in Office 365

You don’t have to do anything to enable DMARC in Office 365. After we finish rolling it out, it will be enabled automatically. To verify that it is working, EOP adds the following DMARC verification information to the Authentication-Results header:

Authentication-results:; spf=pass
(sender IP is xx.xx.xx.xx)
 dkim=none (message not signed) header.d=none; dmarc=none  action=none;

The dmarc=<result> indicates whether the message passed or failed DMARC, with a range of actions that include pass, fail and none.  

The action=<action> indicates what the spam filter’s action will be based on the DMARC result, described below.


Behavior of DMARC for inbound messages in Office 365

One of the key changes that Office 365 has made that differs from the DMARC specification 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. In other words, for inbound email, EOP treats p=reject and p=quarantine the same way.

The reason for this is that there is some legitimate email that fails DMARC. Examples include sending email to mailing lists which is relayed to all list participants, and “Send-to-a-friend” articles from newspaper websites. If EOP rejected these messages per the DMARC specification, people could lose legitimate email with no way to retrieve it.

In EOP’s implementation, these types of emails will still fail DMARC but they will be marked as spam. However, users can still get them to their inboxes by adding safe senders or by administrators creating Exchange Transport rule (ETR) Allow 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 the way it works.

However, EOP also will set the Phishing Confidence Level to 8 in the event that a message fails DMARC with a reject action which means the message is a phish. This is stamped in the X-MS-Exchange-Organization-PCL header, and also in the X-Microsoft-Antispam: PCL:8 field. What this does (or will do when it is supported) is disable functionality within the message such as Reply, Reply All, Attachments and Links so the user cannot take action on it in various Microsoft email clients. The reject action is intended to keep the user from taking action on a message by keeping it away from them completely; EOP can't keep it away completely but setting the PCL and disabling features of the message is close to achieving the same thing.

If EOP overrides the p=reject action, this is indicated in the headers by putting an o.reject into the action=<action> field. For example:

dmarc=fail action=o.reject

This means that the message failed DMARC and the policy was p=reject, but EOP overrode the verdict to subsequently mark it as spam. A safe sender or ETR may yet override that verdict.

If a message fails DMARC and the action is reject or quarantine, but the message has a pct=<value> which says to not apply the DMARC action to every message, this is indicated by adding the pct tag to the action. For example:

dmarc=fail action=pct.quarantine

This means that the message failed DMARC and the action was quarantine, but the pct field was not 100% and the system randomly determined not to apply the DMARC action, as per the specified domain’s policy.


Behavior of DMARC for outbound messages in Office 365 EOP more-or-less follows the DMARC specification for outbound messages. If a message is outbound from EOP and fails DMARC, then if the action is p=quarantine it will be routed through the High Risk outbound IP pool. However, if the message fails DMARC and the action is p=reject, the message will be rejected. There is no override for outbound email. If you publish a DMARC reject policy (not p=quarantine, and not p=none), no other customer in Office 365 can spoof your domain because they will not be able to pass SPF or DKIM for your domain when relaying a message outbound through the service. However, if you do publish a DMARC reject policy but don’t have all of your email authenticated, some of it may be marked as spam for inbound email (as described above), or it will be rejected if you do not publish SPF and try to relay it outbound through the service.

How you can use DMARC if you use Office 365

If you’re an Office 365 customer, here’s how to make the most out of Office 365:

  1. If you’re a small customer and your domain doesn’t get spoofed, you don’t have to do anything! DMARC will start working to block more spam and phishing for you automatically.You may have to add safe senders or ETRs that allow mail from certain senders because they fail DMARC simply because of the way the email is sent (e.g., mail sent to distribution lists, send-to-a-friend). This is a minority of total legitimate email but some customers may be more sensitive to it than others. In parallel, EOP is working on ways to proactively exclude known good senders from DMARC failures but does not have an exhaustive list.

  2. If you’re a large customer that is prone to spoofing, or even a small sender that gets spoofed, you will need to set up DMARC records if you don’t have them already. SPF records are not sufficient, you need to set up DMARC records.a) First, determine if all of your email is authenticated. If so, you may be fortunate enough to publish a p=reject DMARC policy.

    However, most domains need a try-before-you-buy strategy. You can publish a DMARC policy with action=none and collect data.

    b) Second, it is useful to pick a 3rd party to work with to collect and analyze DMARC reports.

    Three from the industry are:

    - Agari, – Microsoft used Agari to improve its SPF authentication
    - ReturnPath, – provides good tools for senders and receivers
    - DMARCIAN, – has some good tools for smaller domains

    It is not required to set this up, however, the tools these companies provide make it possible to sort through large amounts of data very quickly.

    c) Set up DMARC records.

    Even if you can’t publish p=reject or p=quarantine, you can still publish p=none and collect feedback. For example, below is Microsoft’s DMARC record (published at the TXT record for   3600    IN      TXT     "v=DMARC1; p=none; pct=100;;; fo=1"

    Microsoft sends its DMARC reports back to Agari, a 3rd party.

    Once this record is published, all receivers who support DMARC – including Office 365 when the feature is released – will start checking DMARC and sending reports. You can use these reports to authenticate all of your email if you have published p=none so that you can eventually move to p=reject.

    d) Something unique to Office 365 – you can create a rule that applies only to your own inbound mail flow.

    Many companies publish p=none because they are unsure about how much email they may lose by publishing a more restrictive DMARC policy. Microsoft, for example, is not yet in a position to publish p=reject because email sent to other third parties like Gmail, Yahoo, AOL, and so forth may discard important email if it does. Your company may be in the same position.

    If you set up DMARC records, you can create an ETR that marks messages as spam for spoofed messages of your company that fail DMARC. This means that all spoofed email of your domain into Office 365 will be marked as spam, but anywhere else – at Gmail, Yahoo, AOL – will not be marked as spam (at least not due to DMARC). Some legitimate email may be marked as spam, but to get around this either ensure that the email is authenticated by updating SPF records or signing it with DKIM; or, add a safe sender or ETR allow rule for the sender.

    The ETR will look something like the following. You may want to add exceptions to the rule for known senders who spoof your domain but are not malicious.

    The advantage of this is that your domain cannot be spoofed by outside senders for inbound messages to your organization which is common in spear phishing, yet marketing messages that go over the Internet are not affected.

    You should still properly authenticate your email because it reduces false positives and it shrinks the list of exceptions. If you publish p=reject

    you will no longer need this rule.image


  3. If you are an Office 365 customer, and your domain's primary MX record does not point to EOP, you will not get the benefits of DMARCSome customers in Office 365 do not have EOP as their primary MX record. Customers do this most often by pointing their MX record at their own on-premise mail server and then routing email to EOP using a connector. The receiving domain is one of their Accepted-Domains but EOP is not the primary MX. For example, suppose points its MX at itself and uses EOP as a secondary MX record, its MX record looks like the     3600   IN  MX  0     3600   IN  MX  10 (or most) email will first hit since it is the primary MX, and then get routed to EOP. Indeed, some customers don't even list EOP as an MX record at all and simply hook up connectors to route the email.There are a few reasons why customers do this (which I won't go into), but there are many customers who do. If your domain does this, DMARC failures will not be enforced for your domain. The reason is because if we did enforce DMARC, you would get piles of false positives. First, a message that arrives from the Internet to an on-premise mail server which then gets routed to EOP will fail SPF since the connecting IP to EOP is not the original IP but the IP of the on-premise mail server. Second, a message that fails DKIM is not necessarily because of a DKIM forgery but because older versions of Exchange modify message content which break DKIM body hashes; unfortunately EOP cannot tell the difference between a modification-in-transit and a malicious spoof of DKIM.

    Because SPF fails, and because DKIM

    can fail, and because this is all due to routing, EOP will not enforce DMARC failures if your primary MX does not point to EOP. EOP can still detect if a message passes DMARC when the DKIM-signature passes.

That concludes how to use DMARC in Office 365. DMARC is a step forward in fighting spam and phishing, and Office 365 allows customers to further tweak it to get even more value out of it.