Fixes per build report

Author: chrisda

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

@@ -14,7 +14,7 @@ ms.collection:
   - m365-security
   - tier2
 ms.custom: TopSMBIssues
-ms.localizationpriority: normal
+ms.localizationpriority: medium
 description: Admins can learn about pass and fail scenarios for email authentication in Microsoft 365.
 ms.service: defender-office-365
 ms.date: 10/08/2025
@@ -43,7 +43,7 @@ But first, a few definitions as described in the following table:
 |[DKIM](email-authentication-dkim-configure.md)|DomainKeys Identified Mail. Digitally signs important elements of a message (including the From address header) to verify the message wasn't altered in transit, which helps prevent spoofing.|
 |[DMARC](email-authentication-dmarc-configure.md)|Domain-based Message Authentication, Reporting, and Conformance. Uses SPF and DKIM results to verify alignment between domains in the MAIL FROM address and From address to help prevent spoofing.|
 |[ARC](email-authentication-arc-configure.md)|Authenticated Received Chain. Preserve email authentication results across intermediaries that modify messages in transit.|
-|[compauth](email-authentication-about#composite-authentication.md)|Composite authentication. A proprietary Microsoft 365 technology that combines multiple email authentication signals.|
+|[compauth](email-authentication-about.md#composite-authentication)|Composite authentication. A proprietary Microsoft 365 technology that combines multiple email authentication signals.|
 |MAIL FROM address|Also known as the `5321.MailFrom` address, P1 sender, or envelope sender. Used in the transmission of messages between SMTP email servers. Typically recorded in the **Return-Path** header field in the message header. Used as the address for non-delivery reports (also known as NDRs or bounce messages).|
 |From address|Also known as the `5322.From` address or P2 sender. The email address in the **From** header field. Shown as the sender's email address in email clients.|
 

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

@@ -169,18 +169,18 @@ The following table describes the three-digit `reason` codes used with `compauth
 |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`).|
-| &nbsp100|SPF passed or DKIM passed and the domains in the MAIL FROM and From addresses are aligned.|
-| &nbsp101|The message was DKIM signed by the domain used in the From address.|
-| &nbsp102|The MAIL FROM and From address domains were aligned, and SPF passed.|
-| &nbsp103|The From address domain aligns with the DNS PTR record (reverse lookup) associated with the source IP address|
-| &nbsp104|The DNS PTR record (reverse lookup) associated with the source IP address aligns with the From address domain.|
-| &nbsp108|DKIM failed due to a message body modification attributed to previous legitimate hops. For example, the message body was modified in the organization's on-premises email environment.|
-| &nbsp109|Although the sender's domain has no DMARC record, the message would pass, anyway.|
-| &nbsp111|Despite a DMARC temporary error or permanent error, the SPF or DKIM domain aligns with the From address domain.|
-| &nbsp112|A DNS timeout prevented the DMARC record from being retrieved.|
-| &nbsp115|The message was sent from a Microsoft 365 organization where the From address domain is configured as an [accepted domain](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains).|
-| &nbsp116|The MX record for the From address domain aligns with the PTR record (reverse lookup) of the connecting IP address.|
-| &nbsp130|The ARC result from a [trusted ARC sealer](email-authentication-arc-configure.md) overrode the DMARC failure.|
+|  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.|
+|  103|The From address domain aligns with the DNS PTR record (reverse lookup) associated with the source IP address|
+|  104|The DNS PTR record (reverse lookup) associated with the source IP address aligns with the From address domain.|
+|  108|DKIM failed due to a message body modification attributed to previous legitimate hops. For example, the message body was modified in the organization's on-premises email environment.|
+|  109|Although the sender's domain has no DMARC record, the message would pass, anyway.|
+|  111|Despite a DMARC temporary error or permanent error, the SPF or DKIM domain aligns with the From address domain.|
+|  112|A DNS timeout prevented the DMARC record from being retrieved.|
+|  115|The message was sent from a Microsoft 365 organization where the From address domain is configured as an [accepted domain](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains).|
+|  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`).|
 |3xx|The message wasn't checked for composite authentication (`compauth=none`).|
 |4xx|The message bypassed composite authentication (`compauth=none`).|