Improving Exchange Online Email Deliverability Through Third Party Filtering Services – Trusted ARC Sealer


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.

To apply ARC signing to inbound messages through Mimecast, all you need is an Inbound DNS Authentication policy with SPF, DKIM, and DMARC checks enabled

https://community.mimecast.com/s/article/email-security-cloud-gateway-configuring-dns-authentication-policy

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.

Comments

6 responses to “Improving Exchange Online Email Deliverability Through Third Party Filtering Services – Trusted ARC Sealer”

  1. Simon Shaw avatar
    Simon Shaw

    If this works – I owe you a beer!

    1. Brian Reid avatar

      Then you owe me a beer!

  2. Another Simon avatar
    Another Simon

    Amazing Thanks!
    I just came across this article which trying to understand why so many emails were going to junk… we use a third party gateway (mimecast), and after making this change can see it has changed for the positive. I wish I had found this sooner.

    Where do I send the beer 😉

    1. Brian Reid avatar

      Consider it a freeby. By the look of your email address it would have significant costs to ship the beer!

  3. Ryan M. avatar
    Ryan M.

    Most informative article on ARC and DKIM and third party services. Thank you! What I take from this is, if you’re sending e-mails through O365 -> Mimecast -> Customer, then the customer is the one who needs to add dkim.mimecast.com to their Trusted ARC Sealers in Microsoft Defender, correct?

    1. Brian Reid avatar

      The company that is using Mimecast inbound needs to add the Trusted ARC Sealers setting. Your specific example in the comment is not clear enough to work that out. So here are the two things that I read your comment could mean:
      1. O365 > Deliver to recipients MX > Mimecast > Customer
      2. O365 > Outbound via Mimecast > Deliver to recipients MX > Customer

      In these, #1 is where the customer, to reduce their false positives and spam becuase they are double filtering (Mimecast and EOP), should implement ARC. In #2 ARC is not used as the recipient is not double filtering as Mimecast is used by the sender. In #2 your DKIM should be done by Mimecast (as that is your final sender) and SPF should contain M365 and Mimecast IPs (your region only)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.