I recently carried out an Office 365 Proof-of-Concept for one of our local government customers.
Whilst I was there, I discovered that emails sent from the on-premises mail servers to myself were working fine but emails from the Office 365 tenant were not getting through.
A quick trawl through the Office 365 Message Trace shows that the email was successfully passed to the hybrid servers on-premises. Examining the transport logs on-premises showed that the email was successfully passed off to the customer’s Hosted Email Security (HES) solution, offered by Trend Micro.
When the customer and I looked through the HES control panel, we found that the emails were being quarantined by the Mail Disclaimer rule because HES was “unable to modify the message due to DKIM signatures”. This presented us with a head-scratching moment because a check of the Exchange Admin Center showed that DKIM was not enabled for any of their domains.
A quick search through TechNet found the answer: even though there was no DKIM policy enabled on the tenant, Office 365 was applying a default policy which create a DKIM header similar to the following:
From: Second Example <second.example@fabrikam.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
s=selector1-fabrikam-com; d=contoso.onmicrosoft.com; t=1429912795;
h=From:To:Message-ID:Subject:MIME-Version:Content-Type;
bh=<body hash>;
b=<signed field>;
Now that we had a cause, we were able to create a work-around by implementing a Disclaimer Mail Flow Rule in Exchange Online and configure HES to ignore any emails with a DKIM signature header for its disclaimer rule.
In all the deployments I’ve carried out, this is the first time I’ve run into this problem with a cloud mail hygiene service. It remains to be seen if this is something specific to Trend Micro’s HES or just specific to this customer.
