From 51667a80bb277184727f510cf045de19d29cc736 Mon Sep 17 00:00:00 2001 From: Chirouette <92925687+Chirouette@users.noreply.github.com> Date: Wed, 30 Apr 2025 14:36:26 +0300 Subject: [PATCH 1/2] Update email-authentication-arc-configure.md customers are getting confused on scenarios when ARC is failing thinking that it will impact the EOP decision to either reject or pass the message - discussed with our Beta engineer Mithun and agreed to update the documentation with this statement --- defender-office-365/email-authentication-arc-configure.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/defender-office-365/email-authentication-arc-configure.md b/defender-office-365/email-authentication-arc-configure.md index b0c6ebfd13..02993e7dd3 100644 --- a/defender-office-365/email-authentication-arc-configure.md +++ b/defender-office-365/email-authentication-arc-configure.md @@ -145,6 +145,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 ``` +> **Note:** +> When the ARC result is **pass** and originates from a **trusted ARC sealer**, it can be used to preserve authentication context and potentially override failures in SPF, DKIM, or DMARC caused by message modifications during transit. +> However, the final spoofing determination is based on the **Composite Authentication (CompAuth)** outcome. A message may still be delivered even if ARC fails, provided SPF, DKIM, and DMARC evaluations, along with CompAuth, result in a pass. + ## Trusted ARC sealer mail flow diagrams From 982ab0d12db9736edabafb20ac7742427bc75a44 Mon Sep 17 00:00:00 2001 From: Chris Davis Date: Wed, 30 Apr 2025 08:23:42 -0700 Subject: [PATCH 2/2] Update email-authentication-arc-configure.md --- defender-office-365/email-authentication-arc-configure.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/defender-office-365/email-authentication-arc-configure.md b/defender-office-365/email-authentication-arc-configure.md index 02993e7dd3..6af672d20d 100644 --- a/defender-office-365/email-authentication-arc-configure.md +++ b/defender-office-365/email-authentication-arc-configure.md @@ -17,7 +17,7 @@ ms.custom: - seo-marvel-apr2020 description: Authenticated Received Chain (ARC) is an email authentication method that tries to preserve authentication results across devices and any message modification that occurs between the sender and recipient. ms.service: defender-office-365 -ms.date: 1/29/2024 +ms.date: 04/30/2025 appliesto: - ✅ Exchange Online Protection - ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2 @@ -145,9 +145,9 @@ 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 ``` -> **Note:** -> When the ARC result is **pass** and originates from a **trusted ARC sealer**, it can be used to preserve authentication context and potentially override failures in SPF, DKIM, or DMARC caused by message modifications during transit. -> However, the final spoofing determination is based on the **Composite Authentication (CompAuth)** outcome. A message may still be delivered even if ARC fails, provided SPF, DKIM, and DMARC evaluations, along with CompAuth, result in a pass. + +> [!NOTE] +> The ARC result **pass** from a **trusted ARC sealer** can potentially override failures in SPF, DKIM, or DMARC caused by message modification during transit. However, the final spoofing determination is based on the [composite authentication](email-authentication-about.md#composite-authentication) (CompAuth) outcome. Messages that fail ARC might still be delivered if they pass SPF, DKIM, DMARC, and composite authentication evaluations. ## Trusted ARC sealer mail flow diagrams