Merge pull request #10467 from MicrosoftDocs/main

Auto Publish – main to live - 2026-01-08 02:00 UTC

Author: learn-build-service-prod[bot]

Exchange/ExchangeHybrid/email-delivery/email-messages-incorrectly-quarantined.md

@@ -13,7 +13,7 @@ ms.custom:
 ms.reviewer: alehud, v-six
 appliesto: 
   - Exchange Online
-  - Exchange Online Protection
+  - Built-in security features for all cloud mailboxes
   - Exchange Server 2010 Enterprise
   - Exchange Server 2010 Standard
   - Exchange Server 2013 Enterprise

Exchange/ExchangeHybrid/email-delivery/emails-are-rejected-and-receive-ndrs.md

@@ -13,7 +13,7 @@ ms.custom:
 ms.reviewer: jhayes, rorylen, v-six
 appliesto: 
   - Exchange Online
-  - Exchange Online Protection
+  - Built-in security features for all cloud mailboxes
   - Exchange Server 2010 Enterprise
   - Exchange Server 2010 Standard
 search.appverid: MET150
@@ -32,26 +32,26 @@ You run the Hybrid Configuration wizard in Exchange Server 2010 to set up a shar
 
 ## Cause
 
-This issue can occur if the IP addresses that are associated with Exchange Online Protection changed. These IP addresses aren't automatically updated in the on-premises environment. Therefore, the IP addresses that are set in the on-premises Exchange Online Protection receive connector may become invalid. When this issue occurs, mail that's routed from Microsoft 365 users through Exchange Online Protection to the on-premises environment may be rejected.
+This issue can occur if the IP addresses that are associated with Microsoft 365 changed. These IP addresses aren't automatically updated in the on-premises environment. Therefore, the IP addresses that are set in the on-premises receive connector for Microsoft 365 may become invalid. When this issue occurs, mail that's routed from Microsoft 365 users to the on-premises environment may be rejected.
 
 ## Resolution
 
 To fix this issue, use the following steps:
 
-- Rerun the Hybrid Configuration wizard. Rerunning the wizard configures the on-premises Exchange Online Protection receive connector to use the correct IP addresses.
+- Rerun the Hybrid Configuration wizard. Rerunning the wizard configures the on-premises receive connector for Microsoft 365 to use the correct IP addresses.
 
   > [!NOTE]
   > This step applies only to the Hybrid Configuration wizard in Exchange Server 2010. When you run the Hybrid Configuration wizard in Exchange Server 2013, no receive connectors are created or are necessary.
 
-- Manually update the IP addresses that are listed under **Receive mail from remote servers that have these IP addresses** for the on-premises Exchange Online Protection receive connector.
+- Manually update the IP addresses that are listed under **Receive mail from remote servers that have these IP addresses** for the on-premises receive connector for Microsoft 365.
 
 ## More information
 
-In a shared namespace and centralized mail control scenario, an Exchange Online Protection receive connector must be created on the hybrid Exchange 2010 hub transport server to make sure that the on-premises environment receives mail from Microsoft 365 users. The Hybrid Configuration wizard creates the receive connector on the appropriate Exchange 2010 server. Then, the wizard configures the connector with the IP addresses to enable incoming Exchange Online Protection traffic from Microsoft 365 users to be routed to the on-premises environment.
+In a shared namespace and centralized mail control scenario, an receive connector for Microsoft 365 must be created on the hybrid Exchange 2010 Hub transport server to make sure that the on-premises environment receives mail from Microsoft 365 users. The Hybrid Configuration wizard creates the receive connector on the appropriate Exchange 2010 server. Then, the wizard configures the connector with the IP addresses to enable incoming traffic from Microsoft 365 users to be routed to the on-premises environment.
 
-The following screenshot shows an example of an Exchange Online Protection receive connector that the Hybrid Configuration wizard creates.
+The following screenshot shows an example of an receive connector for Microsoft 365 that the Hybrid Configuration wizard creates.
 
-:::image type="content" source="media/emails-are-rejected-and-receive-ndrs/example-of-eop-receive-connector.png" alt-text="Screenshot of an Exchange Online Protection receive connector.":::
+:::image type="content" source="media/emails-are-rejected-and-receive-ndrs/example-of-eop-receive-connector.png" alt-text="Screenshot of a Microsoft 365 receive connector.":::
 
 For more information about the Hybrid Configuration wizard in Exchange 2010, see [Hybrid Deployments with the Hybrid Configuration wizard](/previous-versions/office/exchange-server-2010/hh529920(v=exchg.141)).
 

Exchange/ExchangeHybrid/email-delivery/hybrid-messages-not-routed-through-on-premises.md

@@ -13,7 +13,7 @@ ms.custom:
 ms.reviewer: joelric, v-six
 appliesto: 
   - Exchange Online
-  - Exchange Online Protection
+  - Built-in security features for all cloud mailboxes
   - Exchange Server 2016 Enterprise Edition
   - Exchange Server 2016 Standard Edition
   - Exchange Server 2013 Enterprise
@@ -33,11 +33,11 @@ Consider the following scenario:
 - You configured the outbound send connector in Exchange Online to use a remote domain of "*", and you enabled centralized mail transport on that connector.
 - A user or application in the on-premises organization sends an email message to a mailbox that's hosted in Exchange Online, for example, *[email protected]*. And the Exchange Online recipient, *[email protected]*, has a forwarding SMTP address that's set to an external recipient (*[email protected]*).
 
-In this scenario, the message tracking logs show the message that was forwarded to *[email protected]* isn't routed back through the on-premises organization, as expected. Instead, the message is sent directly through Exchange Online Protection.
+In this scenario, the message tracking logs show the message that was forwarded to *[email protected]* isn't routed back through the on-premises organization, as expected. Instead, the message is sent directly through Microsoft 365.
 
 ## More information
 
-This behavior is by design. To forward the message, an exact copy of the original message is created and sent to the external recipient. Mail routing logic sees that this new message originated in the on-premises environment and therefore doesn't send the message back to the on-premises environment. Instead, it's routed directly to the external recipient domain through Exchange Online Protection.
+This behavior is by design. To forward the message, an exact copy of the original message is created and sent to the external recipient. Mail routing logic sees that this new message originated in the on-premises environment and therefore doesn't send the message back to the on-premises environment. Instead, it's routed directly to the external recipient domain through Microsoft 365.
 
 This behavior also applies to other similar scenarios. For example, email is sent from on-premises to a distribution group hosted in Exchange Online, and there is an external recipient in the distribution group. In this scenario, email sent to that external recipient will be routed directly instead of following centralized mail routing, because the message originates from the on-premises environment.
 

Exchange/ExchangeHybrid/send-emails/emails-show-addresses-not-display-names-in-from.md

@@ -41,7 +41,7 @@ To fix this issue, follow these steps:
 
 1. Check the mail route.
 
-    The simplest route is Exchange 2010 mailbox server to Exchange 2010 hub server (hybrid server) to the Exchange Online Protection (EOP) inbound connector to Exchange Online. Make sure that there are no unnecessary network devices such as anti-spam gateway devices between the Exchange 2010 hub server (hybrid server) and EOP. Those devices could remove the necessary header.
+    The simplest route is Exchange 2010 mailbox server to Exchange 2010 hub server (hybrid server) to the inbound connector in Microsoft 365. Make sure that there are no unnecessary network devices such as anti-spam gateway devices between the Exchange 2010 hub server (hybrid server) and Microsoft 365. Those devices could remove the necessary header.
 
 2. Check the remote domain of the on-premises Exchange server. To do this, follow these steps:
 
@@ -72,9 +72,9 @@ To fix this issue, follow these steps:
    3. In the output, make sure that the `TrustedMailnboundEnabled` attribute is set to **True**.
    4. If the attribute in step 3C isn't set to **True**, use the `Set-RemoteDomain` command to change the value to **True**.
 
-4. Make sure that Transport Layer Security (TLS) is implemented and enabled in both environments and that the fully qualified domain name (FQDN) is set correctly. Check the on-premises send connector and the EOP inbound connector by using the Exchange Server Deployment Assistant at [Exchange Deployment Assistant](/exchange/exchange-deployment-assistant?view=exchserver-2019&preserve-view=true).
+4. Make sure that Transport Layer Security (TLS) is implemented and enabled in both environments and that the fully qualified domain name (FQDN) is set correctly. Check the on-premises send connector and the Microsoft 365 inbound connector by using the Exchange Server Deployment Assistant at [Exchange Deployment Assistant](/exchange/exchange-deployment-assistant?view=exchserver-2019&preserve-view=true).
 
-5. Check the Exchange certificate of the send connector on the on-premises Exchange servers that are responsible for delivering mail to EOP. The Exchange certificate should have Simple Mail Transfer Protocol (SMTP) enabled and should match the FQDN of the send connector.
+5. Check the Exchange certificate of the send connector on the on-premises Exchange servers that are responsible for delivering mail to Microsoft 365. The Exchange certificate should have Simple Mail Transfer Protocol (SMTP) enabled and should match the FQDN of the send connector.
 
 If the issue persists after you follow these steps, contact Microsoft 365 Support.
 

Exchange/ExchangeOnline/administration/release-messages-prompted-client-certificate.md

@@ -1,6 +1,6 @@
 ---
 title: Can't release a message for a certificate
-description: Describes an issue that returns a website 'na01-quarantine.dataservice.protection.outlook.com' requires a client certificate error when a Mac user tries to release a message from Exchange Online Protection quarantine.
+description: Describes an issue that returns a website 'na01-quarantine.dataservice.protection.outlook.com' requires a client certificate error when a Mac user tries to release a message from quarantine in Microsoft 365.
 author: cloud-writer
 ms.author: meerak
 manager: dcscontentpm
@@ -13,17 +13,17 @@ ms.custom:
 ms.reviewer: v-six
 appliesto: 
   - Exchange Online
-  - Exchange Online Protection
+  - Built-in security features for all cloud mailboxes
 search.appverid: MET150
 ms.date: 01/24/2024
 ---
-# Mac users can't release messages from Exchange Online Protection quarantine
+# Mac users can't release messages from quarantine in Microsoft 365
 
 _Original KB number:_   2909418
 
 ## Problem  
 
-When a user tries to release a message from the Exchange Online Protection quarantine when using the Safari browser on a Mac, the user is prompted for a certificate as follows:
+When a user tries to release a message from quarantine in Microsoft 365 when using the Safari browser on a Mac, the user is prompted for a certificate as follows:
 
 > The website "na01-quarantine.dataservice.protection.outlook.com" requires a client certificate.
 

Exchange/ExchangeOnline/administration/self-help-diagnostics.md

@@ -58,7 +58,7 @@ Several diagnostics currently cover the various areas within Exchange Online and
 |Retention policy diagnostics for a user mailbox|Check retention policy settings on a user mailbox.|[Run Tests: Retention Policy on a user mailbox](https://aka.ms/PillarRetentionPolicy)|[Retention tags and retention policies in Exchange Online](/exchange/security-and-compliance/messaging-records-management/retention-tags-and-policies)|
 |DomainKeys Identified Mail (DKIM) diagnostics|Validate that DKIM signing is configured correctly and the correct DNS entries have been published.|[Run Tests: DKIM](https://aka.ms/diagdkim)|[Use DKIM to validate outbound email sent from your custom domain](/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email)|
 |Compromised Account diagnostics|Identify suspicious activities against an account and return information that can be used to recover the account if compromised.|[Run Tests: Compromised Account](https://aka.ms/diagca)|[Responding to a compromised email account](/microsoft-365/security/office-365-security/responding-to-a-compromised-email-account)|
-|Email threat policies diagnostics for a recipient|List EOP/MDO threat policies and the inbound connector used for a received message.|[Run Tests: Email Threat Policies](https://aka.ms/diagmdopolicy)|[Order and precedence of email protection](/defender-office-365/how-policies-and-protections-are-combined)|
+|Email threat policies diagnostics for a recipient|List threat policies in [the built-in security features for all cloud mailboxes](/defender-office-365/eop-about) and in [Microsoft Defender for Office 365](/defender-office-365/mdo-about), and the inbound connector used for a received message.|[Run Tests: Email Threat Policies](https://aka.ms/diagmdopolicy)|[Order and precedence of email protection](/defender-office-365/how-policies-and-protections-are-combined)|
 |Proxy address conflict diagnostics|Find the Exchange recipient that uses an email address. Helpful if you receive an "Email/proxy address is in use" or similar error message when you try to create an Exchange Online mailbox. | [Run Tests: Proxy address in use](https://aka.ms/PillarProxyInUse) | [Proxy address conflict when adding an email address in Exchange Online](/exchange/troubleshoot/email-alias/proxy-address-being-used) |
 |Mailbox safe/blocked sender list diagnostics|Check and identify issues with the mailbox's safe senders and domains, blocked sender and domains in junk email settings.|[Run Tests: Mailbox Safe Blocked Sender List](https://aka.ms/safeblockdiag)| [Configure junk email settings on Exchange Online mailboxes](/defender-office-365/configure-junk-email-settings-on-exo-mailboxes)|
 

Exchange/ExchangeOnline/antispam-and-protection/cannot-send-emails-to-external-recipients.md

@@ -13,42 +13,42 @@ ms.custom:
 ms.reviewer: v-six
 appliesto: 
   - Exchange Online
-  - Exchange Online Protection
+  - Built-in security features for all cloud mailboxes
 search.appverid: MET150
 ms.date: 01/24/2024
 ---
-# Recipient rejects mail from Exchange Online or Exchange Online Protection and host name does not match IP address error
+# Recipient rejects mail from Microsoft 365 and host name does not match IP address error
 
 _Original KB number:_   3019655
 
 ## Symptoms
 
-When users try to send mail from Microsoft Exchange Online or Microsoft Exchange Online Protection to an external recipient, the destination message transfer agent (MTA) rejects the message. The error message that users receive may vary. Typically, it states that the source server's host name does not match its IP address.
+When users try to send mail from Microsoft 365 to an external recipient, the destination message transfer agent (MTA) rejects the message. The error message that users receive may vary. Typically, it states that the source server's host name doesn't match its IP address.
 
 ## Cause
 
-The recipient server requires that the server name that's contained in the message HELO string have a corresponding pointer (PTR) resource record (reverse IP lookup). Exchange Online and Exchange Online Protection use multiple IP addresses to send mail. Because of DNS limitations, all these IP addresses can't be mapped through the PTR record to the server name that's in the message HELO string.
+The recipient server requires that the server name that's contained in the message HELO string have a corresponding pointer (PTR) resource record (reverse IP lookup). Microsoft 365 uses multiple IP addresses to send mail. Because of DNS limitations, all these IP addresses can't be mapped through the PTR record to the server name that's in the message HELO string.
 
 ## Resolution
 
-The method in which Exchange Online and Exchange Online Protection send email by using multiple IP addresses is typical for most large mail systems and is by design. Contact the recipient system administrator for help.
+The method that Microsoft 365 uses to send email messages by using multiple IP addresses is standard for most large mail systems and is by design. Contact the recipient's system administrator for help.
 
 ## More information
 
-In Exchange Online and Exchange Online Protection, outgoing email settings use specific patterns. It's important to be aware of these patterns if your recipient servers use PTR record lookups for validation. This is because they explain why messages that are sent from the service might be rejected. The patterns are as follows:
+In Microsoft 365, outgoing email settings use specific patterns. It's important to be aware of these patterns if your recipient servers use PTR record lookups for validation. This is because they explain why messages sent from the service might be rejected. The patterns are as follows:
 
-1. The sending IP addresses that are used by Exchange Online and Exchange Online Protection have forward-confirmed reverse DNS records. This means that each sending IP address has both a forward (name-to-IP address) and a reverse (address-to-name) DNS record that contains matching information. For example:
+1. The sending IP addresses used by Microsoft 365 have forward-confirmed reverse DNS records. This means that each sending IP address has both a forward (name-to-IP address) and a reverse (address-to-name) DNS record that contains matching information. For example:
 
     ```console
     Outbound IP address: 157.56.110.65
     PTR record: 157.56.110.65 = mail-bn1on0065.outbound.protection.outlook.com
     A-record : mail-bn1on0065.outbound.protection.outlook.com = 157.56.110.65
     ```
 
-2. The HELO/EHLO strings that are used to identify the mail servers that are used by the service also contain `outbound.protection.outlook.com`. For example:  
+2. The HELO/EHLO strings which identify the mail servers that the Microsoft 365 service uses also contain `outbound.protection.outlook.com`. For example:  
    `na01-bn1-obe.outbound.protection.outlook.com`
 
-    All these HELO/EHLO strings have A records that contain some outgoing IP addresses that correspond to the sending mail servers. (However, the A records do not contain all these outgoing IP addresses.) For example:  
+    All these HELO/EHLO strings have A records that contain some outgoing IP addresses that correspond to the sending mail servers. However, the A records don't contain all these outgoing IP addresses. For example:  
     `HELO na01-bn1-obe.outbound.protection.outlook.com`
 
     A record: `na01-bn1-obe.outbound.protection.outlook.com`:
@@ -64,9 +64,9 @@ In Exchange Online and Exchange Online Protection, outgoing email settings use s
     207.46.163.158  
     207.46.163.149
 
-3. The PTR records of the IP addresses in the A record of the EHLO/HELO string will not match the HELO/EHLO string of the sending mail server. For example:  
+3. The PTR records of the IP addresses in the A record of the EHLO/HELO string won't match the HELO/EHLO string of the sending mail server. For example:  
    PTR record: 207.46.163.150: `mail-bn1lp0150.outbound.protection.outlook.com`
 
-   Notice that `mail-bn1lp0150.outbound.protection.outlook.com` does not match `na01-bn1-obe.outbound.protection.outlook.com`.
+   Notice that `mail-bn1lp0150.outbound.protection.outlook.com` doesn't match `na01-bn1-obe.outbound.protection.outlook.com`.
 
 Still need help? Go to [Microsoft Community](https://answers.microsoft.com/).