An update on DKIM-on-IPv4 and DMARC in Office 365
If you’re wondering when Office 365 is going to release inbound validation for DKIM-on-IPv4 and DMARC support, I have an update for you.
1.
We are currently evaluating DKIM-on-IPv4 everywhere in the service but are fixing the remaining bugs
Today, we stamp the DKIM results in a temporary header, X-DkimResult (or X-DkimResult-Test), but eventually we will stamp it in the Authentication-Results header. For example, if the signing domain in the d= field in the DKIM-Signature header is d=example.com:
Authentication-Results: spf=pass (sender IP is 1.2.3.4)
smtp.mailfrom=user\@example.com; contoso.com; dkim=pass (signature
was verified) header.d=example.com;
The temporary header does show the DKIM evaluation but we found that there were problems when the Exchange mail server was modifying (formatting) message content. We have addressing the remaining corner cases as we find them and have driven down the number of DKIM failures that weren’t really failures but instead were caused by Content Transformation (an agent in Exchange that formats messages).
I have some rules in my personal tenant that look for DKIM failures based upon that temporary header and I can confirm that they have decreased dramatically.
We have to fix a bug with the Authentication-Results stamping
We have a bug where the Authentication-Results header is being overwritten; it’s stamped but then stripped and stamped again but the DKIM result is not included (this is due to some infrastructure in the spam filter that we are replacing). We need to fix that because stamping the results of DKIM in clear text is important.
Even after we release DKIM, there will still be some problems if downstream mail servers try to re-authenticate
As I mention above, the Exchange mail server formats message content. We evaluate DKIM before the content has been transformed, but the email is recreated and passed to the mailbox storage (or passed to another outbound connector) after the message has been transformed. We have to fix that but it won’t be done before we release DKIM. This issue occurs on all versions of on-premise Exchange except Exchange 2013 that has the latest updates.
There’s a problem with DMARC where customers whose primary MX records do not point to Exchange Online Protection (EOP) generate DMARC failures
This is described in point #3 in my blog post How to use DMARC in Office 365. Basically, we were seeing DMARC failures and it didn’t make sense, but upon troubleshooting we noticed it is because customers sometimes route email through themselves first which can break DMARC under certain circumstances.
We are working on a solution for this.
We are aiming to release DKIM-on-IPv4 and DMARC in Q1 of 2015, but the above describes where we are right now.
Comments
Anonymous
January 15, 2015
The comment has been removedAnonymous
January 19, 2015
What about an update on DKIM signing?Anonymous
January 19, 2015
@Brandon - I don't have an update on outbound DKIM signing other than it is on our roadmap.Anonymous
July 24, 2015
The comment has been removedAnonymous
August 09, 2015
Terry, any update on outbound DKIM signing yet?Anonymous
August 09, 2015
Terry, never mind...I found your recent post: blogs.msdn.com/.../not-using-the-additional-spam-filtering-option-for-spf-hard-fail-to-block-apparently-internal-email-spoofing.aspxAnonymous
February 01, 2016
The comment has been removed