Office365 checking DMARC on the inbound

According to a recent blog post, Office365 is starting to evaluate incoming messages for DMARC. I talked a little bit about DMARC in April when Yahoo started publishing a p=reject message.

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. What DMARC does is allow domain owners to publish policy statements in DNS telling receiver domains what to do with messages that do not authenticate. In addition, DMARC introduces the concept of “domain alignment.” What this means is that the authentication has to be from the same domain (or a sub-domain) as the address in the header-from: line. The idea behind DMARC is that organizational owners can use SPF and DKIM authentication to authenticate their actual domain in the header-from line. This moves authentication from a important but behind the scenes technology out to an end user visible technology.

What Office365 is doing is evaluating incoming messages by checking to see if the domain in the visible from is publishing a DMARC record by doing a DNS lookup on _dmarc.example.com and seeing if the domain publishes a policy (p=reject, p=quarantine or p=none). I find it hard to keep all this authentication talk straight in my head, so we’ll walk through an email in my inbox from a domain I know publishes a DMARC policy: LinkedIn.
We can look at LinkedIn’s DMARC record and see they are publishing a p=reject message.

_dmarc.linkedin.com. 43200 IN TXT "v=DMARC1\; p=reject\;rua=mailto:d@rua.agari.com,mailto:dmarc_agg@auth.returnpath.net\;ruf=mailto:d@ruf.agari.com,mailto:dmarc_afrf@auth.returnpath.net\;pct=100"

This tells us that LinkedIn claims any mail with a visible From address @linkedin.com that is not authenticated by LinkedIn should be rejected. For the actual authentication we use SPF and DKIM.
SPF looks at the domain in the return path to see if it authenticates. Pulling data out of the mail I got from linked in earlier today we see a return path and a connecting IP.

Return-Path: <s-2do5cr1bkppa7rrn6bb05ojrn8hezv0it5t5qvu5orpvw9oqteu14svt@bounce.linkedin.com>
Received: from mailb-dc.linkedin.com (mailb-dc.linkedin.com [108.174.6.155]) by mx.wordtothewise.com (Postfix) with ESMTPS id B026F17EC4E for <laura-linkedin@blighty.com>; Thu, 22 Jan 2015 14:51:37 -0800 (PST)

SPF does a TXT lookup on bounce.linkedin.com, that sends us to linkedin.com and we see a number of IPs listed.

bounce.linkedin.com.   "v=spf1 redirect=linkedin.com"
linkedin.com.       "v=spf1 ip4:8.18.31.21 ip4:8.18.31.22 ip4:69.28.149.0/24 ip4:199.101.162.0/25 ip4:108.174.3.0/24 ip4:108.174.6.0/24 ip6:2620:109:c00d:104::/64 ip6:2620:109:c006:104::/64 ip6:2620:109:c003:104::/64 ip4:216.136.162.65 mx mx:docusign.net ~all"

SPF passes as the IP we received the message from (108.174.6.155) is in the linkedin.com SPF record.
We can actually stop here, SPF has authenticated and DMARC only requires either SPF or DKIM to be valid. But let’s keep going.
DKIM cryptographically signs an email and assigns responsibility (authenticates) the domain in the d=value, in this case d=linkedin.com

Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1421967091; bh=M6KAF0X71EsB2NXpXSB0cB2ZaXEq7pcw31B8cHashmk=; h=From:Subject:MIME-Version:Content-Type:To:Date:X-LinkedIn-Class: X-LinkedIn-Template:X-LinkedIn-fbl; b=U2WtG04z5aII8BjRBiurVonfR9ZB5bmqs51Aon0OrscuGe6k2U7ml9xPf3NNYeiTA +MrAsjUVpPr4mUD9uRrILKfO4Yu+szi3LBaJbCc2SrcmDq7kaanOqEswkUn1UfDEs4 hfO5gxZ7VKdovTVwHp1Rbe/tGb1DR+V09QgDBUjY=

Our mail server does check DKIM on the inbound, so we look at the authentication results to see if the mail passed.

Authentication Results: dkim=pass (1024-bit key) header.d=linkedin.com)

This email is also authenticated by DKIM.
Finally, the authenticated domains (in this case bounce.linkedin.com authenticated with SPF and linkedin.com authenticated with DKIM) are compared with the address in the from line.

Anthony Chiulli <member@linkedin.com>

All of these domains are in the same organizational domain (linkedin.com) so the message is authenticated with DMARC.
If the message was not authenticated by SPF and DKIM, or the authentication mapped back to domains that were not linkedin.com then the mail would fail DMARC authentication. Companies checking DMARC on the inbound could reject the message for failing DMARC authentication.
There are some sticky corners where valid mail will fail DMARC authentication. Due to this, Microsoft is not going to reject mail that fails DMARC even when the sender publishes a p=reject. Instead, they will quarantine that message. In Microsoft’s own words:

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.

Microsoft isn’t the only company who is only partially implementing DMARC, but they are the first to make a public statement about it.
Companies using Office365 seeing odd or unexpected mail failures should check their quarantine/bulk/spam folders and follow the directions on the Office365 website if those failures are due to a DMARC fail.
HT: Anthony Chiulli from Salesforce.