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

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.

Comments (26)
  1. Arie. says:

    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 mail will pass spf but fail DKIM.

  2. Terry Zink says:

    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.

  3. Exchange Admin says:

    Is there any estimated date when this DMARC will be available on EOP?

  4. Terry Zink says:

    @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.

  5. Dr.Why says:

    How will know when DMARC is fully active on our O365 tenant?

  6. tzink says:

    @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).

  7. Esequiel says:

    Why DMARC is tagged as bestguesspass in the header? I can't see in anywhare what it means.

  8. Terry Zink says:

    @Esequiel: dmarc=bestguesspass is explained here:…/what-is-dmarc-bestguesspass-in-office-365.aspx

  9. Anonymous says:

    I do the rule ETR…, but if the soofed email address is a distribution group the header and the SCL was changed, but the message was not send to the junk mail foldes that is my action on the spam filter, but if the soofed address are from a user the message is moved to that.

  10. Joe Sutherland says:

    Two questions for you about, "EOP will not enforce DMARC failures if your primary MX does not point to EOP."

    1. Does EOP simply not enforce the action (quarantine, reject, etc.) in the dmarc record in this case, or would you actually not mark a fail in the headers, either?

    2. Can you elaborate on how "do not have EOP as their primary MX record" is determined? Specifically, can you address the following scenario:

    I often use the MX record of the tenant domain for all accepted domains in the tenant to simplify DNS configuration and because the tenant domain can never be removed from the tenant, so I don't have to worry about that MX record changing (bad historical experience scars here). Given a tenant name of, an accepted domain of, and an accepted domain of, the MX records Office 365 would define would be,, and I would typically point MX records for both domains to the tenant MX record ( Would this configuration cause the "do not have EOP as their primary MX record" trigger to fire since the defined CNAME is not what Office 365 specified?


  11. tzink says:


    1. We would mark it in the headers but not enforce it in the spam filter.

    2. For "Primary MX is not EOP" I mean this: suppose the domain is A domain whose primary MX is EOP would look like this: IN MX 10

    A domain whose primary MX is NOT EOP would look like this in the case of an on-prem mail filter that then routes through EOP: IN MX 10

    Or, the MX points to another service: IN MX 10

    In either of those two cases, because the connecting IP is the on-premise mail server, or the cloud filtering service, SPF will fail. Because SPF fails and DKIM may fail or may not exist, DMARC will be unreliable and therefore we will suppress it.

    > I often use the MX record of the tenant domain for

    > all accepted domains in the tenant to simplify DNS

    > configuration and because the tenant domain can

    > never be removed from the tenant,

    That's fine.

  12. sanyi says:

    "Terry: DKIM is not required to pass DMARC, it is an either/or."

    So how can you enforce both DKIM and SPF check? Imagine that you specified o365 EOP in your DNS SPF record and an other o365 subscriber send out fake mail using your domain name? On the receiver side the SPF check will pass as the same o365 EOP servers will send out the mail. DMARC will pass as SPF is enough. This spoofing could be eliminated if both SPF and DKIM would be enforced but I see no DMARC setup for such restriction.

  13. tzink says:


    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.

  14. Octa says:

    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 😉


  15. tzink says:

    @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.

  16. Raj says:

    This information is really useful…Thanks to the publisher…Would update the comments if there is any deviation…

  17. Kevin says:

    Since you say that Exchange Online is already using DMARC, can I just set up the ETR for incoming mail that have “dmarc=failed” in the headers without making a DMARC DNS entry? Or am I just wasting my time if I do not make a DMARC DNS entry because not having one renders the ETR effectively useless?

    1. tzink says:

      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 automatically
      2. Other verifiers (e.g., Gmail, Yahoo, etc.) can benefit because they rely upon your DMARC record explicitly

  18. Yves says:

    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.

  19. Ben Hooper says:

    Ever encountered “dmarc=permerror” when the DNS record is valid?

    1. tzink says:

      It’s probably not a valid DNS record, I would think we are doing strict syntax checking. Common errors are putting in colons as opposed to the equal sign in a DMARC record, or putting in SPF record syntax into a DMARC record.

    2. I see a lot of temperrors reported, but only from Microsoft. Wish Microsoft would fix their DNS servers.

  20. Laurens Koot says:

    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.

    1. tzink says:

      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.

  21. 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 where the is the spoofed sender? I don’t understand the need for DMARC here?

  22. Cam says:

    What will happen to an email that fails spf and passes dkim and vice versa? Will this get delivered normally?

Comments are closed.

Skip to main content