SPF + DKIM are two ways to verify the sender of an e-mail, and DMARC is the next step, allowing you to say if SPF or DKIM has success then the mail is acceptable.
SPF operates on the SMTP envelope, the HELO/EHLO or MAIL FROM: domain, while DKIM is a digital signature on headers inside the e-mail.
With DMARC, it is validated that the visible From: address, also called header.from or RFC5233.from is matching the DKIM signature, or that that the domain of the SPF validation matches the RFC5222.from domain. DMARC validation is done on recipients mail server.
Enabling DKIM signing of outgoing messages in Office365 is trivial. And so is setting up SPF. Both requires access to create/modify DNS records.
Our problems
We have a shared mailbox, call it shared@main.com - We have 2 users, peter@main.com and anne@subbrand.com that both handles mails in the shared@main.com mailbox.This always worked fine to our knowledge. And we added dkim signatures to all outgoing mail on main.com and subbrand.com. This works perfectly on mail from peter@main.com and anne@subbrand.com.
The issue comes when anne@subbrand.com wants to answer on behalf of shared@main.com. Microsoft has decided to include the dkim of subbrand.com, and only that dkim in the mail sent out.
Looking at the dkim deployment guide http://www.dkim.org/specs/draft-ietf-dkim-deployment-11.html is clearly states in 6.5 that multiple signatures are allowed, but there is no agreement between recipients of which one to validate.
But looking in 7.3.2 it is clearly written, that is ADSP signature validation is to take place, the signature must match RFC5322.from - But Microsoft picks the dkim of the primary domain of the person sending the mail, not the dkim matching the RFC5322.from.
The result of this is, that when DMARC looks for dkim key, it will find a non-aligned dkim key, and these mails from shared@main.com will fail the DMARC dkim validation.
Luckily we use the same servers, so we can fall back to the SPF you might think. But no. If anne@subbrand.com uses the Exchange Online web interface, SPF / SMTP From seems to be postmaster@eur01-db5-obe.outbound.protection.outlook.com - And that does not match main.com.
And if she is using Desktop Outlook, then the smtp.mailfrom is set to anne@subbrand.com - Which is also not the same as main.com
Conlusion
Microsoft just recently started to support incoming DMARC validation, and outgoing dkim. And it seems likely that they have had a low adoption rate, as I do not see the above situation as something rare or very special. But it probably was not listed as a test case for the developer.We can only hope that Microsoft will fix this soon, such that we can start enabling quarantine in our DMARC records. As it is now, too many mails going towards the Internet would be flagged as spam if we did it.
Workaround
To get things to work, and block at least CEO spam, we have had to create som transport rules. We know only the few cross-domain shared mailboxes are the issue, so we can whitelist these, if they have a dkim=pass and a signature from subbrand.com in the Authentication-Results
header.
Looking for something like: header.from=subbrand.com;main.com; dkim=pass will catch these. But you have to keep updating the transport rule.
But 3rd parties receiving our mails stills sees the p=none in the DMARC record. They can't implement the workaround.
Update 2016-07-01
Been communicating with Microsoft, both Premier support and Terry Zink thru a mailing list.
The issues comes from the SendOnBehalfOf, that never was part Internet mail standards, but is legacy from Lotus Notes / Exchange. You can not set these user rights in the GUI on EO, but can only set it thru Powershell.
If you change the permission on the mailbox to SendAs, then all identity of the author will be removed, and everything will be aligned with the shared mailbox. But this is a change we are probably not prepared to take, we will probably align the shared@main.com with the subbrand.com domain.
Another problem popped up, when people write to distribution groups that are not expanded at the client, when it then hits Exchange Online, the mail is "reborn" as a new virgin e-mail, with the protection.outlook.com smtp.helo, and no dkim at all (it was decided that is was internal in the first place). To Exchange Online the mail is new, from the outside, and unaligned in spf, and no dkim. So it will fail dmarc.
So we are still not where we can enable quarantine, but at least we have transport rules for filtering. If dmarc is fine, then SCL=-1. If not, we will do other checks on headers. Some key users will get marked as spam if not dmarc, so they can't use cloud distribution groups, only what is in the address book, and can be expanded locally.
