Configure trusted ARC sealers

Email authentication helps validate mail sent to and from your Microsoft 365 organization to prevent spoofed senders that are used in business email compromise (BEC), ransomware, and other phishing attacks.

But some legitimate email services might modify messages before they're delivered to your Microsoft 365 organization. Modifying inbound messages in transit can and likely will cause the following email authentication failures in Microsoft 365:

• SPF fails because of the new message source (IP address).
• DKIM fails because of content modification.
• DMARC fails because of the SPF and DKIM failures.

Authenticated Received Chain (ARC) helps reduce inbound email authentication failures from message modification by legitimate email services. ARC preserves the original email authentication information at the email service. You can configure your Microsoft 365 organization to trust the service that modified the message, and to use that original information in email authentication checks.

When to use trusted ARC sealers?

A Microsoft 365 organization needs to identify trusted ARC sealers only when messages delivered to Microsoft 365 recipients are regularly affected in the following ways:

• The intermediary service modifies the message header or email content.
• The message modifications cause authentication to fail for other reasons (for example, by removing attachments).

After an admin adds a trusted ARC sealer in the Defender portal, Microsoft 365 uses the original email authentication information that the ARC sealer provides to validate the messages sent through the service into Microsoft 365.

What do you need to know before you begin?

• You open the Microsoft Defender portal at https://security.microsoft.com. To go directly to the Email authentication settings page, use https://security.microsoft.com/authentication.

• To connect to Exchange Online PowerShell, see Connect to Exchange Online PowerShell.

• You need to be assigned permissions before you can do the procedures in this article. You have the following options:

  • Microsoft Defender XDR Unified role based access control (RBAC) (If Email & collaboration > Defender for Office 365 permissions is Active. Affects the Defender portal only, not PowerShell): Authorization and settings/Security settings/Core Security settings (manage) or Authorization and settings/Security settings/Core Security settings (read).

  • Exchange Online permissions: Membership in the Organization Management or Security Administrator role groups.

  • Microsoft Entra permissions: Membership in the Global Administrator^*. Members of the Security Administrator role can't access email authentication settings in the Defender portal.

    Important

    ^* Microsoft strongly advocates for the principle of least privilege. Assigning accounts only the minimum permissions necessary to perform their tasks helps reduce security risks and strengthens your organization's overall protection. Global Administrator is a highly privileged role that you should limit to emergency scenarios or when you can't use a different role.

Use the Microsoft Defender portal to add trusted ARC sealers

1. In the Microsoft Defender portal at https://security.microsoft.com, go to Email & collaboration > Policies & rules > Threat policies > Email Authentication Settings in the Rules section > ARC . Or, to go directly to the Email authentication settings page, use https://security.microsoft.com/authentication.

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

   Tip

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

3. In the Add trusted ARC sealers flyout that opens, enter the trusted signing domain in the box (for example, fabrikam.com).

   The domain name must match the domain that's shown in the d value in the ARC-Seal and ARC-Message-Signature headers in affected messages. Use the following methods to view the message header:

   • View internet message headers in Outlook.
   • Use the Message Header Analyzer at https://mha.azurewebsites.net.

   Repeat this step as many times as necessary. To remove an existing entry, select next to the entry.

   When you're finished in the Add trusted ARC sealers flyout, select Save.

Use Exchange Online PowerShell to add trusted ARC sealers

If you'd 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

  Get-ArcConfig
  

  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:

  Set-ArcConfig -Identity [TenantId\]Default -ArcTrustedSealers "Domain1","Domain2",..."DomainN"
  

  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, aaaabbbb-0000-cccc-1111-dddd2222eeee.

  This example configures "cohovineyard.com" and "tailspintoys.com" as the only trusted ARC sealers in the organization.

  Set-ArcConfig -Identity Default -ArcTrustedSealers "cohovineyard.com","tailspintoys.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.

Vendor-specific ARC sealer configuration

When you add a trusted ARC sealer in Microsoft 365, you enter the domain shown in the d value of the ARC-Seal header. The following table lists the ARC sealer domains for common email security vendors:

Proofpoint

Proofpoint Protection Server (PPS) adds ARC headers when messages are processed through the gateway. The ARC-Seal header uses d=pphosted.com.

1. Verify the ARC sealer domain from a message header: Look for the following pattern in message headers:

   ARC-Seal: i=1; a=rsa-sha256; d=pphosted.com; s=arcselector;
     t=1657920000; cv=none;
     b=<signature>
   

2. Add the trusted ARC sealer in Microsoft 365: Connect to Exchange Online PowerShell and run the following command:

   Set-ArcConfig -Identity Default -ArcTrustedSealers "pphosted.com"
   

   Note

   Some Proofpoint deployments use a custom domain for ARC sealing (for example, proofpoint.com or a customer-specific domain). Always check actual message headers to confirm the d= value before you configure trusted sealers.

Mimecast

Mimecast Email Security adds ARC headers when it processes inbound and outbound mail. The ARC-Seal header uses d=mimecast.com.

1. Verify the ARC sealer domain from a message header: Look for the following pattern in message headers:

   ARC-Seal: i=1; a=rsa-sha256; t=1623745127; cv=none;
     d=mimecast.com; s=arc-2018;
     b=<signature>
   

2. Add the trusted ARC sealer in Microsoft 365: Connect to Exchange Online PowerShell and run the following command:

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

   Tip

   If you're migrating from Mimecast to Microsoft 365 native protection, keep the Mimecast trusted ARC sealer configured until you fully cut over MX records and all queued messages are delivered.

Barracuda

Barracuda Email Gateway Defense and Email Security Gateway add ARC headers using d=barracudanetworks.com.

1. Verify the ARC sealer domain from a message header: Look for the following pattern in message headers:

   ARC-Seal: i=1; a=rsa-sha256; d=barracudanetworks.com; s=arc1;
     t=1680000000; cv=none;
     b=<signature>
   

2. Add the trusted ARC sealer in Microsoft 365: Connect to Exchange Online PowerShell and run the following command:

   Set-ArcConfig -Identity Default -ArcTrustedSealers "barracudanetworks.com"
   

Sophos

Sophos Central Email Security adds ARC headers using d=sophos.com.

1. Verify the ARC sealer domain from a message header: Look for the following pattern in message headers:

   ARC-Seal: i=1; a=rsa-sha256; t=1686324586; cv=none;
     d=sophos.com; s=arc;
     b=<signature>
   

2. Add the trusted ARC sealer in Microsoft 365: Connect to Exchange Online PowerShell and run the following command:

   Set-ArcConfig -Identity Default -ArcTrustedSealers "sophos.com"
   

Multiple vendors

If your organization uses multiple email services that add ARC seals, connect to Exchange Online PowerShell and add all vendor domains in a single command:

Set-ArcConfig -Identity Default -ArcTrustedSealers "pphosted.com","mimecast.com","barracudanetworks.com","sophos.com"

Find your vendor's ARC sealer domain

If your vendor isn't listed in the previous table, use the following steps to identify the correct ARC sealer domain:

1. Send a test email through the intermediary service to a Microsoft 365 mailbox.
2. Open the message headers (in Outlook: File > Properties > Internet Headers, or use the Message Header Analyzer).
3. Search for ARC-Seal: in the headers.
4. Note the d= value. This value is the domain to add as a trusted ARC sealer.

Validate a trusted ARC sealer

If there's an ARC seal from a service before the message reaches Microsoft 365, check the message header for the latest ARC headers after the message is delivered.

In the last ARC-Authentication-Results header, look for arc=pass and oda=1. These values indicate:

• The previous ARC has been verified.
• The previous ARC sealer is trusted.
• The previous pass result can be used to override the current DMARC failure.

For example:

ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
172.17.17.17) smtp.rcpttodomain=microsoft.com
smtp.mailfrom=sampledoamin.onmicrosoft.com; dmarc=bestguesspass action=none
header.from=sampledoamin.onmicrosoft.com; dkim=none (message not signed);
arc=pass (0 oda=1 ltdi=1
spf=[1,1,smtp.mailfrom=sampledoamin.onmicrosoft.com]
dkim=[1,1,header.d=sampledoamin.onmicrosoft.com]
dmarc=[1,1,header.from=sampledoamin.onmicrosoft.com])

To check whether the ARC result was used to override a DMARC failure, look for compauth=pass and reason=130 in the last Authentication-Results header. For example:

Authentication-Results: spf=fail (sender IP is 10.10.10.10)
smtp.mailfrom=contoso.com; dkim=fail (body hash did not verify)
header.d=contoso.com;dmarc=fail action=none
header.from=contoso.com;compauth=pass reason=130

Trusted ARC sealer mail flow diagrams

The diagrams in this section contrast mail flow and the effect on email authentication results with and without a trusted ARC sealer. In both diagrams, the Microsoft 365 organization uses a legitimate email service that modifies inbound mail before it's delivered to Microsoft 365. This modification interrupts mail flow, which can cause email authentication failures by changing the source IP and updating the email message header.

This diagram demonstrates the result without a trusted ARC sealer:

This diagram demonstrates the result with a trusted ARC sealer:

Common ARC failure scenarios

When ARC doesn't work as expected, use the following troubleshooting reference.

Quick reference: ARC failure symptoms

Wrong ARC sealer domain configured

Problem: You added your own domain (for example, contoso.com) instead of the vendor's ARC sealing domain.

The message headers show the vendor's actual ARC sealing domain:

ARC-Seal: i=1; a=rsa-sha256; d=pphosted.com; s=arcselector;
  cv=none; b=<signature>

But when you run Get-ArcConfig in Exchange Online PowerShell, the output shows the wrong domain is configured:

ArcTrustedSealers : {contoso.com}

Resolution: Use the vendor's ARC sealing domain. For example:

Set-ArcConfig -Identity Default -ArcTrustedSealers "pphosted.com"

Intermediary service not adding ARC headers

Problem: Messages pass through your gateway but contain no ARC headers. The intermediary service either doesn't support ARC or ARC isn't enabled.

Diagnosis: Search message headers for ARC-Seal:. If no ARC-Seal header exists, the intermediary isn't sealing.

Resolution: Enable ARC signing in your vendor's management console:

Broken ARC chain (cv=fail)

Problem: The ARC chain validation shows cv=fail, meaning a previous ARC seal in the chain couldn't be verified.

The message headers show a failed chain validation:

ARC-Seal: i=2; a=rsa-sha256; d=mimecast.com; s=arc-2018;
  cv=fail; b=<signature>

This failure typically has the following causes:

• A previous intermediary modified the message after adding its ARC seal (breaking the chain).
• DNS issues prevented lookup of the ARC sealer's public key.
• The ARC public key was rotated but cached DNS records haven't expired.

Resolution: Use the following steps to diagnose and fix the broken chain:

1. Check the cv= value at each ARC instance (i=1, i=2, etc.) to identify where the chain broke.
2. Verify that the ARC sealer's public key is published in DNS. For example, use nslookup -type=TXT arcselector._domainkey.pphosted.com to query the key record.
3. If DNS returns no result, contact the vendor about their ARC key publication.
4. If the chain breaks between two services you control, ensure message modifications happen before ARC sealing, not after.

ARC passes but messages still go to Junk Email

Problem: ARC validation passes (arc=pass, compauth=pass reason=130), but messages are still delivered to the Junk Email folder.

Explanation: ARC overrides DMARC authentication failures only. It doesn't bypass:

• Content-based spam filtering (SCL values from content analysis).
• Bulk email filtering (BCL threshold).
• Anti-spam policy actions.
• Mail flow rule actions.
• Safe/Blocked sender lists.

Diagnosis: Check the X-Forefront-Antispam-Report header:

X-Forefront-Antispam-Report: CIP:10.10.10.10; CTRY:US; LANG:en; SCL:5;
  SFV:SPM; H:mail.fabrikam.com; PTR:mail.fabrikam.com; CAT:SPM;

If CAT:SPM or SCL:5 or higher, the message was filtered as spam by content filtering, which is independent of ARC.

Resolution: Try the following options to resolve spam filtering:

• Create a mail flow rule to set SCL to -1 for messages from trusted senders or IP addresses.
• Add the sender domain to an anti-spam policy allow list.
• Submit the message as a false positive via the Microsoft Defender portal.

CompAuth reason codes reference

Next steps

Check your ARC headers with Message Header Analyzer at https://mha.azurewebsites.net.

Review the SPF, DKIM, DMARC configuration procedures.

To diagnose and fix email authentication failures, see Troubleshoot email authentication in Microsoft 365.