Share via

Using DMARC in Office 365

  • Article

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: protection.outlook.com; spf=pass
(sender IP is xx.xx.xx.xx) smtp.mailfrom=user@contoso.com
 dkim=none (message not signed) header.d=none; dmarc=none  action=none header.from=contoso.com;

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,https://agari.com/ – Microsoft used Agari to improve its SPF authentication
    - ReturnPath, https://www.returnpath.com/ – provides good tools for senders and receivers
    - DMARCIAN, https://dmarcian.com/ – 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 _dmarc.microsoft.com):

    _dmarc.microsoft.com.   3600    IN      TXT     "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; 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 contoso.com points its MX at itself and uses EOP as a secondary MX record, its MX record looks like the following:contoso.com     3600   IN  MX  0  mail.contoso.com
    contoso.com     3600   IN  MX  10 contoso-com.mail.protection.outlook.comAll (or most) email will first hit mail.contoso.com 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.

Comments

  • Anonymous
    December 09, 2014
    Sorry but something doesn't add up. Office365 does not (yet) support DKIM signing, so how can you set up a =reject outgoing dmarc policy? all outlook.com mail will pass spf but fail DKIM.

  • Anonymous
    December 11, 2014
    If you are an on-premise customer (on-premise mail server that relays email through Exchange Online), you can setup p=reject. When email is relayed through Exchange Online and out to the rest of the Internet, it will pass SPF which can align with the 5322.From address, and thereby pass DMARC. DKIM is not required to pass DMARC, it is an either/or.

  • Anonymous
    December 15, 2014
    Is there any estimated date when this DMARC will be available on EOP?

  • Anonymous
    December 16, 2014
    @Exchange Admin: We are rolling it out now, it should be stamping the header with the results of a DMARC check by the end of December 2014, and enforcing actions by Q1 of 2015.

  • Anonymous
    January 20, 2015
    How will know when DMARC is fully active on our O365 tenant?

  • Anonymous
    February 26, 2015
    @Dr Why: as of Feb 26, 2015, DMARC enforcement is done for 90% of all customers except for the ones that we can detect as not routing their email directly through Office 365 (i.e., mail flows first through some other service).

  • Anonymous
    April 22, 2015
    Why DMARC is tagged as bestguesspass in the header? I can't see in anywhare what it means.

  • Anonymous
    May 07, 2015
    @Esequiel: dmarc=bestguesspass is explained here: blogs.msdn.com/.../what-is-dmarc-bestguesspass-in-office-365.aspx

  • Anonymous
    June 10, 2015
    The comment has been removed

  • Anonymous
    December 14, 2015
    The comment has been removed

  • Anonymous
    December 14, 2015
    The comment has been removed

  • Anonymous
    February 17, 2016
    The comment has been removed

  • Anonymous
    February 19, 2016
    @sanyi: If an Office 365 customer sends email as you to another Office 365 customer, it won't pass DKIM alignment (since it won't have your key) and it won't pass SPF alignment since we can detect this and look back to the original IP which won't be in your SPF record. The only problem is when another customer spoofs you and sends to an non-Office 365 receiver (e.g., Yahoo, Google, etc.). We're planning to stop this behavior altogether. When a customer sends email through our system using connectors (on-prem connector to Office 365), we attribute the message to them. If we can't attribute it to them (IP is shared among several customers, or sending domain is not provisioned to them) we attribute the email to the default tenant. We're planning to remove this functionality in the future so customers can no longer spoof each other - in other words, shut it down at the source.

  • Anonymous
    February 22, 2016
    Hi,is there any way to test DMARC ETR without using anonymous mailer that seems to me already blocked by EOP? Using telnet I cannot forge the correct header (I'm not a good spammer ;) Thanks

  • Anonymous
    February 22, 2016
    @Octa: You need to send from an IP that is not listed on one of our blocklists. Or, if it is listed, create an IP allow rule for your tenant in the Office Admin Center. That will set the SCL to -1. Then, create an ETR rule that sets the SCL to 0 and have it run ahead of the DMARC rule.

  • Anonymous
    February 25, 2016
    This information is really useful...Thanks to the publisher...Would update the comments if there is any deviation...

  • Anonymous
    March 25, 2016
    The comment has been removed

    • Anonymous
      March 28, 2016
      DMARC in Exchange Online doesn't require you to set up an ETR because we already take the proper action, as describe How Office 365 implements DMARC. For your own domain, we already have an antispoofing feature that works without a DMARC record. However, publishing one makes the experience better in two ways:1. You can control who can and cannot send as you rather than relying upon our implicit verification of figuring it out automatically2. Other verifiers (e.g., Gmail, Yahoo, etc.) can benefit because they rely upon your DMARC record explicitly

  • Anonymous
    April 14, 2016
    Its a pity O365 ETR cannot do a lookup on 5322 and 5321 addresses and if they don't match then simply reject the message. You wouldn't need a DMARC then.

  • Anonymous
    June 14, 2016
    The comment has been removed

    • Anonymous
      June 21, 2016
      The comment has been removed
    • Anonymous
      July 19, 2016
      The comment has been removed

  • Anonymous
    August 31, 2016
    You mentioned that DMARC failures will not be enforced if you are using another "hop" before the mail is delivered to Office 365. Is it completely ignoring DMARC or does it adhere to the rua/ruf records. What I am trying to achieve is that Office 365 (which is placed behind another mailserver, so not the primary MX server) will send delivery reports for received mails.

    • Anonymous
      August 31, 2016
      Ultimately, if there is another hop in front of Office 365, then DMARC may be checked (stamped in the Authentication-Results header) but not enforced. We also would never send ruf nor rua reports.

  • Anonymous
    November 20, 2016
    In the example ETR rule above, if the 'and message header includes' condition is omitted wouldn't this still quarantine all spoofed incoming mail from outside of contoso.com where the contoso.com is the spoofed sender? I don't understand the need for DMARC here?

  • Anonymous
    December 12, 2017
    What will happen to an email that fails spf and passes dkim and vice versa? Will this get delivered normally?