Updates per TR

Author: chrisda

defender-office-365/email-auth-sec-ops-guide.md

@@ -90,7 +90,7 @@ These scenarios describe messages that **passed email authentication checks** or
 > [!NOTE]
 > In mail forwarding scenarios where the forwarding service is another Microsoft 365 organization, you don't need to configure **trusted ARC sealers** for **microsoft.com**. ARC signatures are automatically trusted by receiving Microsoft 365 organizations when the message passes validation.
 
-### Message delivered to allow entries for spoofed senders in the Tenant Allow/Block List
+### Message delivered due to allow entries for spoofed senders in the Tenant Allow/Block List
 
 - **What it means**: The message bypassed normal authentication failure actions because [allow entries for spoofed senders exist in the Tenant Allow/Block List](tenant-allow-block-list-email-spoof-configure.md#create-allow-entries-for-spoofed-senders). In Microsoft 365, an allow entry for spoofed senders can override failures. Even when email authentication checks normally fail, the message is allowed due to this explicit trust configuration.
 - **Header example**: `compauth=fail reason=000` (but an organization policy allowed the message: **Tenant Allow/Block List spoof allowed**).
@@ -99,7 +99,7 @@ These scenarios describe messages that **passed email authentication checks** or
 
   Generally, **there's no immediate action** for these messages, since they're intentionally allowed. However, it's good practice for admins to **periodically review allow entries for spoofed senders** to ensure only necessary senders are allowed. Overusing the Tenant Allow/Block List allows delivery of (possibly malicious) messages that would normally fail authentication checks.
 
-### 6. Authenticated via PTR (reverse DNS) alignment
+### Authenticated via PTR (reverse DNS) alignment
 
 - **Header example**: `compauth=pass` with codes like `reason=116` or `reason=111` to indicate PTR record use.
 - **What it means**: The message passed authentication **based on PTR (reverse DNS) validation** as a fallback. In some cases when SPF and DKIM checks don't yield a conclusive pass, Microsoft 365 can look at the sender's PTR record. If the sending server's IP address has a PTR record (reverse DNS) that matches the domain in the message's **From** address, the system might treat the message as authenticated.
@@ -225,7 +225,7 @@ This section contains a simplified table that summarizes the scenarios, the reco
 |ARC validated (non-Microsoft service trusted via ARC)|No action needed (if message modification by a non-Microsoft service is expected). Ensure non-Microsoft services use ARC.|[Configure trusted ARC sealers](email-authentication-arc-configure.md)|
 |Allowed by Tenant Allow/Block List (allowed by organization policy: Tenant Allow/Block List spoof allowed)|No immediate action required. Admins should periodically review allow entries for spoofed senders.|[View entries for spoofed senders in the Tenant Allow/Block List](tenant-allow-block-list-email-spoof-configure.md#use-the-microsoft-defender-portal-to-view-entries-for-spoofed-senders-in-the-tenant-allowblock-list)|
 |Authenticated via PTR record (reverse DNS lookup)|Sender should configure SPF or DKIM (don't rely on PTR lookup).|[Set up SPF identify valid email sources for your Microsoft 365 domain](email-authentication-spf-configure.md)|
-|DMARC Failed (policy quarantine or reject)|Sender to ensure: <ul><li>SPF or DKIM pass.</li><li>MAIL FROM domain or DKIM signing domain is aligned with the From domain.</li></ul>. <br/> Recipient to configure Enhanced Filtering for Connectors and ARC in complex mail routing scenarios (intermediary services). <br/.<br/> Recipient to consider shifting message modifications (footers, disclaimers, subject, etc.) to Microsoft 365 to prevent DKIM failures.|[Use DMARC to validate email](email-authentication-dmarc-configure.md) <br/><br/> [Enhanced Filtering for Connectors](/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors) <br/><br/> [Configure trusted ARC sealers](email-authentication-arc-configure.md) <br/><br/> [Considerations for integrating non-Microsoft security services with Microsoft 365](mdo-integrate-security-service.md)|
+|DMARC Failed (policy quarantine or reject)|Sender to ensure: <ul><li>SPF or DKIM pass.</li><li>MAIL FROM domain or DKIM signing domain is aligned with the From domain.</li></ul> <br/> Recipient to configure Enhanced Filtering for Connectors and ARC in complex mail routing scenarios (intermediary services). <br/><br/> Recipient to consider shifting message modifications (footers, disclaimers, subject, etc.) to Microsoft 365 to prevent DKIM failures.|[Use DMARC to validate email](email-authentication-dmarc-configure.md) <br/><br/> [Enhanced Filtering for Connectors](/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors) <br/><br/> [Configure trusted ARC sealers](email-authentication-arc-configure.md) <br/><br/> [Considerations for integrating non-Microsoft security services with Microsoft 365](mdo-integrate-security-service.md)|
 |SPF check failed|Sender to update SPF record (include all source IP addresses and fix errors).|[Set up SPF identify valid email sources for your Microsoft 365 domain](email-authentication-spf-configure.md)|
 |DKIM none|Sender should configure DKIM signing using the From address domain.|[How to use DKIM for email in your custom domain](email-authentication-dkim-configure.md)|
 |DKIM check failed (no key for signature)|Sender should correct DKIM configuration for the domain (publish the DKIM public key).|[Set up DKIM](email-authentication-dkim-configure.md)|

defender-office-365/message-headers-eop-mdo.md

@@ -168,7 +168,7 @@ The following table describes the three-digit `reason` codes used with `compauth
 |001|The message failed implicit authentication (`compauth=fail`). The sending domain didn't have email authentication records published, or if they did, they had a weaker failure policy (SPF `~all` or `?all`, or a DMARC policy of `p=none`).|
 |002|The organization has a policy for the sender/domain pair that's explicitly prohibited from sending spoofed email. An admin manually configures this setting.|
 |010|The message failed DMARC, the DMARC policy action is `p=reject` or `p=quarantine`, and the sending domain is one of your organization's accepted domains (self-to-self or intra-org spoofing).|
-|1xx|The message passed implicit authentication (`compauth=pass`).|
+|1xx|The message passed explicit or implicit authentication (`compauth=pass`).|
 |  100|SPF passed or DKIM passed and the domains in the MAIL FROM and From addresses are aligned.|
 |  101|The message was DKIM signed by the domain used in the From address.|
 |  102|The MAIL FROM and From address domains were aligned, and SPF passed.|
@@ -182,8 +182,15 @@ The following table describes the three-digit `reason` codes used with `compauth
 |  116|The MX record for the From address domain aligns with the PTR record (reverse lookup) of the connecting IP address.|
 |  130|The ARC result from a [trusted ARC sealer](email-authentication-arc-configure.md) overrode the DMARC failure.|
 |2xx|The message soft-passed implicit authentication (`compauth=softpass`).|
+|  201|The PTR record for the From address domain aligns with the subnet of the PTR record for the connecting IP address.|
+|  202|The From address domain aligns with the domain of the PTR record for the connecting IP address.|
 |3xx|The message wasn't checked for composite authentication (`compauth=none`).|
 |4xx|The message bypassed composite authentication (`compauth=none`).|
-|6xx|The message failed implicit email authentication  (`compauth=fail`). The sending domain is one of your organization's accepted domains (self-to-self or intra-org spoofing)|
+|501|DMARC wasn't enforced. The message is a valid non-delivery report (also known as an NDR or bounce message), and contact between the sender and recipient is previously established.|
+|502|DMARC wasn't enforced. The message is a valid NDR for a message sent from this organization.|
+|6xx|The message failed implicit email authentication  (`compauth=fail`).|
+|  601|The sending domain is an [accepted domain](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in your organization (self-to-self or intra-org spoofing).|
 |7xx|The message passed implicit authentication (`compauth=pass`).|
+|  701-704|DMARC wasn't enforced because this organization has a history of receiving legitimate messages from the sending infrastructure.|
 |9xx|The message bypassed composite authentication (`compauth=none`).|
+|  905|DMARC wasn't enforced due to complex routing. For example, internet messages are routed through an on-premises Exchange environment or a non-Microsoft service before reaching Microsoft 365.|