When you receive emails into Exchange Online and you filter the external messages before arrival with a third party filter such as Mimecast, Proofpoint or others, then you can have DMARC failures that result in messages being junked or quarantined in Exchange Online. Trusted ARC Sealer is a feature of Exchange Online to allow you to trust the DMARC results from the previous service (the third party) within Exchange Online.
This DMARC failure is typically because SPF fails or DKIM fails. SPF fails because the email is arriving from the third-party and not the original sender, and this is fixed with Enhanced Filtering. DKIM fails typically because message is modified by the interim third-party service. I cannot speak for all third party services here, but you always see this with Mimecast, and so I strongly recommend these settings if you front your Exchange Online with Mimecast. You will also see this if the modification of the message occurs with the removal of attachments or adding disclaimers etc. before arrival to Exchange Online.
Here is an example of selected email headers from an email sent from my own Microsoft 365 tenant to a client who also in Microsoft 365/Exchange Online and is behind Mimecast (that is MX points to Mimecast).
ARC-Authentication-Results: i=3; mx.microsoft.com 1; spf=pass (sender ip is 40.107.6.126) smtp.rcpttodomain=contoso.com smtp.mailfrom=c7solutions.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=c7solutions.com; dkim=fail (body hash did not verify) header.d=c7solutions.com; arc=pass (0 oda=0 ltdi=0 93)
Authentication-Results: spf=pass (sender IP is 40.107.6.126) smtp.mailfrom=c7solutions.com; dkim=fail (body hash did not verify) header.d=c7solutions.com;dmarc=fail action=none header.from=c7solutions.com;compauth=pass reason=100
Looking at the top most ARC-Authentication-Results header, you can see that DKIM failed (body hash did not verify) but that the ARC (Authenticated Receive Chain) headers placed in the message by Mimecast where deemed OK by Microsoft (arc=pass).
Looking at the overall results of the message authentication (Authentication-Results header), we can see the same summary – DKIM failed as the message body was modified in some way and so did not verify. This failure might be enough to junk or quarantine this email, and this outcome is what we are hoping to change.
What we want to be able to do is trust the header added by the third-party who fronts our email rather than taking the failing header at Exchange Online. This is Authenticated Receive Chain (ARC).
The message will also have an ARC-Authentication-Results header added by the third-party and that will be further into the message headers as you see them in your email client. For example, in the same email I see the following, where i=2 (the second ARC-Authentication-Results header, compared with i=3 above:
ARC-Authentication-Results: i=2; relay.mimecast.com; dkim=pass header.d=c7solutions.com header.s=selector1 header.b=xxxxxxx; dmarc=pass (policy=none) header.from=c7solutions.com; spf=pass (relay.mimecast.com: domain of brian.reid@c7solutions.com designates w.x.y.z as permitted sender) smtp.mailfrom=brian.reid@c7solutions.com
In the Mimecast added ARC-Authentication-Results you see that Mimecast says dkim=pass. So if dkim passed when the message arrived at Mimecast, but failed when it arrived at Exchange Online, Mimecast modified the message after receipt of the email. [Mimecast break messages into their component parts and reassembles them before sending on – this breaks the dkim verified signature for the message body as far as any downstream service is concerned].
What we want to be able to do is trust the header added by the third-party who fronts our email rather than taking the failing header at Exchange Online. This is Authenticated Receive Chain (ARC). The ARC header is digitally signed (or sealed) and so we can tell Exchange Online to trust the header in safety that Exchange Online will only do this is the ARC-Seal that verifies it is valid. The ARC-Seal and other ARC headers are part of the message headers.
To add a trusted ARC sealer to Exchange Online go to the Trusted ARC Sealers page at https://security.microsoft.com/authentication and add the domain value you find in an email you have received that has routed through your trusted third-party. For example, for Mimecast this is “dkim.mimecast.com“. This domain value will be found in the domain ‘d’ tag in ARC-Seal and ARC-Message-Signature headers (on the email headers for the message) that the third-party added to the message (there will also be an ARC-Seal and ARC-Message-Signature headers for microsoft.com placed in the message by Microsoft). So its likely the second (i=2) ARC-Seal header where you will find the domain (d=) value to use.
Ensure that this domain is working with ARC before you use it though. In the first ARC-Authentication-Results header (added by Microsoft) check that they added arc=pass as shown at the top of this article. This means that the ARC-Seal was sealed correctly. If arc=fail then trusted ARC sealers will not work because the sealing of the previous header has failed.
You can also add the domain using Set-ArcConfig in Exchange Online PowerShell. See the documentation at https://learn.microsoft.com/microsoft-365/security/office-365-security/email-authentication-arc-configure for more on the use of this cmdlet.
Once you have added a trusted ARC sealer, wait 30-60 minutes for the change to take effect in Exchange Online and then send in a new external message and see if dkim checks are now successful. You can tell if Trusted ARC Sealers is working with the oda=1 header found in the top most ARC-Authentication-Results header. Before you add the trusted ARC sealers this will be oda=0 and be close to headers such as “dkim=fail (body hash did not verify)” also mentioned above.
After turning on Trusted ARC Sealers for the third-party domain (dkim.mimecast.com in this case) I see the following in my email headers:
ARC-Authentication-Results: i=3; mx.microsoft.com 1; spf=pass (sender ip is 40.107.8.127) smtp.rcpttodomain=contoso.com smtp.mailfrom=c7solutions.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=c7solutions.com; dkim=fail (body hash did not verify) header.d=c7solutions.com; arc=pass (0 oda=1 ltdi=1 spf=[1,2,smtp.mailfrom=brian.reid@c7solutions.com] dkim=[1,2,header.d=c7solutions.com] dmarc=1,2,header.from=c7solutions.com])
Now you can see oda=1 and information extracted from the ARC-Seal of the previous email service.
Authentication-Results: spf=pass (sender IP is 40.107.8.127) smtp.mailfrom=c7solutions.com; dkim=fail (body hash did not verify) header.d=c7solutions.com;dmarc=fail action=none header.from=c7solutions.com;compauth=pass reason=130
Here the last bit of information and reason=130 means ARC Trusted Sealer was used to verify the sender and though DMARC failed, determine that the email really did pass DMARC because it passed it at the previous email filtering company.
At the start of this blog post we list some 3rd party email gateway/filters and then discuss ARC with regard to what Mimecast do. Its worthwhile noting here that ProofPoint do not do ARC nor is it on their roadmap for the next few years.
Leave a Reply