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:
- My own blog post: A brief introduction to DMARC
http://blogs.msdn.com/b/tzink/archive/2014/11/04/a-brief-introduction-to-dmarc.aspx - My article for Virus Bulletin: Using DMARC to improve your email reputation
https://www.virusbtn.com/pdf/conference/vb2014/VB2014-Zink.pdf - Video: My presentation on DMARC from Virus Bulletin
https://www.youtube.com/watch?v=wxX-XknaMYQ - Slideshare: DMARC training at the NANOG conference
http://www.slideshare.net/kka7/fighting-email-abuse-with-dmarc?qid=5e90be27-3fc0-41ed-9d71-253978cc6a12&v=default&b=&from_search=2 - DMARC overview and specification
http://dmarc.org/
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.
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:
- 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. - 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,http://agari.com/– Microsoft used Agari to improve its SPF authentication
- ReturnPath, http://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]( "image")
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.