DMARC Analyzer 2.0 - Authenticated Received Chain

This article contains information on the Authenticated Received Chain (ARC) protocol, its role in addressing DMARC failures, use cases like forwarding and mailing lists, and steps to enable ARC in Microsoft 365 for Mimecast.

ARC (Authenticated Received Chain) is a new protocol that has been developed to correct situations in which DMARC would fail.

What does ARC do?

When a receiver can successfully validate an ARC chain, they have the following information:

• The Authentication-Results as seen by the first ARC participant handling the message. This includes the DMARC / DKIM and SPF results.
• The information to validate the sent data
• The information to link the sent signature to their intermediary to build up a reputation

This would allow intermediaries to add content to the message, providing they forward the message with a new (and correct) DKIM signature. It also provides data to reputation systems on the intermediaries handling the messages.

Situations where ARC can help

Mailing lists

When you’re a member of a mailing list, you’re able to send a message to all members of that list by addressing the mailing list itself. That receiving address will then ‘forward’ your message to all of the list members. The list often addresses extra information to the body of the message, for instance, a notification of the list of membership with options to unsubscribe.

Currently, these messages fail when applying DMARC, because their mail servers will break the SPF for that message. Due to the fact that the content of the mail changes, the DKIM signature is also invalidated.

Forwarding messages

When you have set up an account that forwards messages to another mailbox, you may experience issues with messages from senders with a DMARC policy set to reject or quarantine. This is because the forwarding services will break the SPF for that message. Some forwarders also change the content of the email by adding spam filtering results, additional disclaimers, or footers.

These situations can be summed up as ‘Indirect mail flows’. They are mail flows in which the initial receiver of the message is not the final receiver and acts as an intermediary.

How can ARC help?

As the forwarders in the above-described situation have initially received emails with a DMARC valid setup, it would be useful to forward these results encrypted to the next receiver of the messages.

ARC is designed as a specification that allows the Authentication-Results header (which describes the result of the messages) to be passed on to the next ‘hop’ in the line of the message's delivery.

When a receiver validates the results of an incoming message and sees the DMARC results failing, they will try to validate the provided ARC chain. When this proves valid, they can extract the authentication results of the initial hop.

Based on the results of these headers they may choose to use the ARC information to override the DMARC policy, depending on the reputation of the ARC intermediaries.

How to enable Microsoft O365 to recognize the Mimecast ARC signature

We only use ARC in Microsoft O365 for inbound emails to the customer. This is done to confirm the authentication (as well as other checks) that we have already done on those inbound emails. This is done because, like other intermediatory services, our presence will have broken DKIM and SPF. Accordingly, we have checked for SPF, DKIM, and DMARC upon receipt, based on the sending domain and receiving customer configuration. The ARC-Authentication-Results header will also contain the results of those.
 

Using the Microsoft 365 Defender portal to add trusted ARC sealers

1. In the Microsoft 365 Defender portal , navigate to Email & Collaboration | Policies & Rules | Threat policies | Email Authentication Settings in the Rules section | ARC . Alternatively, you can go directly to the Email Authentication settings page.

2. On the Email authentication settings page, verify that the ARC tab is selected, and then select  Add.

   If Trusted sealers are already listed on the ARC tab, select  Edit.

3. In the Add trusted ARC sealers pop up that opens, enter the Mimecast trusted signing domain dkim.mimecast.com in the box. Select Save. 

Using Exchange Online PowerShell to add trusted ARC sealers

If you would rather use PowerShell to view, add, or remove trusted ARC sealers, connect to Exchange Online PowerShell to run the following commands.

• View existing trusted ARC sealers

  PowerShellCopy

  Set-ArcConfig -Identity [TenantId\]Default -ArcTrustedSealers "dkim.mimecast.com"

  If no trusted ARC sealers are configured, the command returns no results.

• Add or remove trusted ARC sealers

  To replace any existing ARC sealers with the values you specify, use the following syntax:

  PowerShellCopy

  Set-ArcConfig -Identity [TenantId\]Default -ArcTrustedSealers "dkim.mimecast.com"

  The TenantId\ value isn't required in your own organization, only in delegated organizations. It's a GUID that's visible in many admin portal URLs in Microsoft 365 (the tid= value). For example, a32d39e2-3702-4ff5-9628-31358774c091.

  PowerShellCopy

  Set-ArcConfig -Identity Default -ArcTrustedSealers "dkim.mimecast.com"

  To preserve existing values, be sure to include the ARC sealers that you want to keep along with the new ARC sealers that you want to add.

  To add or remove ARC sealers without affecting the other entries, see the Examples section in Set-ArcConfig.

For more information, see the Configure trusted ARC sealers  article.