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

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

Who can you trust?

I’ve been recently dealing with a client who is looking at implementing authentication on their domains. He’s done a lot of background research into the schemes and has a relatively firm grasp on the issue. At this point we’re working out what policies he wants to set and how to correctly implement those policies.
His questions were well informed for the most part. A few of them were completely out of left field, so I asked him for some of his references. One of those references was the EEC Email Authentication Whitepaper.
My client was doing the best he could to inform himself and relies on industry groups like the EEC to provide him with accurate information. In this case, their information was incomplete and incorrect.
We all have our perspectives and biases (yes, even me!) but there are objective facts that can be independently verified. For instance, the EEC Authentication whitepaper claimed that Yahoo requires DKIM signing for access to their whitelist program. This is incorrect, a sender does not have to sign with DKIM in order to apply for the Yahoo whitelist program. A bulk sender does have to sign with DKIM for a Y! FBL, but ISPs are given access to an IP based FBL by Yahoo. I am shocked that none of the experts that contributed to the document caught that error.
Independent verification is one reason I publish the Delivery Wiki. It’s a resource for everyone and a way to share my knowledge and thought processes. But other experts can “check my work” as it were and provide corrections if my information is outdated or faulty. All too often, senders end up blaming delivery problems on evil spirits, or using “dear” in the subject line or using too much pink in the design.
Delivery isn’t that esoteric or difficult if you have a clear understanding of the policy and technical decisions at a range of ESPs and ISPs, the history and reasoning behind those decisions, and enough experience to predict the implications when they collide.
Many senders do face delivery challenges and there is considerable demand for delivery experts to provide delivery facts. That niche has been filled by a mix of people, of all levels of experience, expertise and technical knowledge, leading to the difficult task of working out which of those “experts” are experts, and which of those “facts” are facts.

Read More

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