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.

Related Posts

Hotmail moves to SPF authentication

Hotmail has recently stopped using Sender ID for email authentication and switched to authenticating with SPF. The protocol differences between SenderID and SPF were subtle and most senders who were getting a pass at Hotmail were already publishing SPF records.
From an email in my inbox from September:

Read More

ESPs, Non-portable Reputation and Vendor Lock-in

I’ve seen some mentions recently of ESPs suggesting that if you use your own domain in the From: of mail you send through an ESP then that ESP can’t “do email authentication” properly unless they require you to edit your domains DNS settings. That’s not really so, but there is a kernel of truth in there.
The real situation is, unsurprisingly, a bit more complicated.
What authentication features should you look for in an ESP?

Read More

DMARC: Please Be Careful!

(Cross posted from Spam Resource.)
Every couple of days, somebody new pops up on the DMARC-Discuss mailing list to ask some question or share an observation. It’s great to see people interested and joining the conversation. Clearly, DMARC interest and adoption are growing. What’s really frustrating, though, is that for about a quarter of the new subscribers, their first mailing list message goes to the spam folder in my Gmail account. It has become sort of an intelligence test I apply to new subscribers — I’ve stopped digging those messages out of the spam folder. I’m figuring that if they can’t figure out how to implement a DMARC record, or they don’t understand that it’s not really compatible with mailing lists nor is it meant for hobbyist domains, then I think perhaps they’ve got some things they’ve got to figure out before they’re ready to join the discussion.
To that end, let me take a moment to jot down some recommendations for folks who are considering implementing DMARC.

Read More