+Delegated Access Permission (DAP) partners are Syndication and Cloud Solution Providers (CSP) Partners. They're frequently network or telecom providers to other companies. They bundle Microsoft 365 subscriptions into their service offerings to their customers. When they sell a Microsoft 365 subscription, they're automatically granted Administer On Behalf Of (AOBO) permissions to the customer tenancies so they can administer and report on the customer tenancies.

+The procedures in this article require you to connect to [Connect to Microsoft 365 with PowerShell](connect-to-microsoft-365-powershell.md).

+- You need to know how to add a TXT record to the registered DNS zone for your DNS registrar. For more information on how to add a TXT record, see [Add DNS records to connect your domain](../admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider.md). If those procedures don't work for you, you'll need to find the procedures for your DNS registrar.

+This command creates the domain in Microsoft Entra ID but doesn't associate it with the publicly registered domain. That comes when you prove that you own the publicly registered domain to Microsoft 365 for enterprises.

+>[!NOTE]

+> The Azure Active Directory module is being replaced by the Microsoft Graph PowerShell SDK. You can use the Microsoft Graph PowerShell SDK to access all Microsoft Graph APIs. For more information, see [Get started with the Microsoft Graph PowerShell SDK](/powershell/microsoftgraph/get-started).

+First, use a **Microsoft Entra DC admin**, **Cloud Application Admin**, or **Global admin** account to [connect to your Microsoft 365 tenant](connect-to-microsoft-365-powershell.md).

+Assigning and removing licenses for a user requires the **Domain.ReadWrite.All** permission scope or one of the other permissions listed in the ['Assign license' Graph API reference page](/graph/api/user-assignlicense).

+Connect-MgGraph -Scopes "Domain.ReadWrite.All"

+Run the following command to create a new domain:

+```powershell

+New-MgDomain -Id <customer TenantId> -DomainNameReferences <FQDN of new domain>

+```

+Import-Module Microsoft.Graph.Identity.DirectoryManagement

+(Get-MgDomainVerificationDnsRecord -DomainId <domain ID, i.e. contoso.com> | Where-Object {$_.RecordType -eq "Txt"}).AdditionalProperties.text

+ `MS=ms########`

+Before Microsoft 365 will start accepting traffic that is directed to the publicly registered domain name, you must prove that you own and have administrator permissions to the domain. You prove you own the domain by creating a TXT record in the domain. A TXT record doesn't do anything in your domain, and it can be deleted after your ownership of the domain is established. To create the TXT records, follow the procedures at [Add DNS records to connect your domain](../admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider.md). If those procedures don't work for you, you need to find the procedures for your DNS registrar.

+Confirm-MgDomain -DomainId <FQDN of new domain> -InputObject @{TenantId=<customer TenantId>}

+Get-MgDomain -DomainId <FQDN of new domain>

+This will return something like this:

+Id AuthenticationType AvailabilityStatus IsAdminManaged IsDefault IsInitial IsRoot IsVerified Manufact

+ urer

+-- -- - --

+contoso.com Managed True True True True True

+If any customer tenant data covered by the Advanced Data Residency feature is not stored at rest within the customer's eligible _Local Region Geography_, then a data migration is needed to address customer data residency compliance and tenant location requirements fulfilled by ADR.

+After receiving the Advanced Data Residency licenses and applying them to the customer's tenant, the customer administrator must select the option to initiate the data migration process for ADR workloads that do not currently reside in their _Local Region Geography_. To initiate data migration for a tenant, the customer administrator should visit the "Data location" section in the Microsoft 365 admin center by navigating to **Settings > Org settings > Organization profile > Data location**. From here, the customer administrator can see the current location of the customer's data-at-rest and what _Local Region Geography_ their customer data currently resides in or is eligible to be migrated to upon selection.

+#### Microsoft 365 Admin Center Data Location

+> The data migration process described in the sections below will not initiate until the customer administrator completes this task.

+The following screenshot is an example of the Microsoft 365 admin center Data location view that an ADR customer can expect to see before opting for migration to their _Local Region Geography_.

+#### Before Migration Opt-in

+Once a customer administrator chooses the option to initiate migration, they are provided with confirmation of their opt-in date and migration initiation as shown in the screenshot below.

+#### After Migration Opt-in

+The "Data location" section in the Microsoft 365 admin center (referenced in the screenshots above) displays the most up-to-date location of each workload throughout the data migration process. Customer administrators can also view any Message center notifications related to their migration within the Microsoft 365 admin center by navigating to **Health > Message center**.

+Microsoft adheres to the [Microsoft Online Services Service Level Agreement (SLA)](https://go.microsoft.com/fwlink/p/?LinkId=523897) for service availability and uses reasonable efforts to complete an Advanced Data Residency add-on customer data migration within 12 months from the time the customer administrator selects the option to initiate migration. However, large, complex customers, and situations outside of Microsoft's control, may require more time for migration to complete.

+Data moves are a back-end service operation with minimal impact to a customer's operations. For information related to specific workloads, customer administrators can refer to the ΓÇ£MigrationΓÇ¥ sections in the following Workload Data Residency Capabilities pages: [Exchange Online](m365-dr-workload-exo.md#migration), [SharePoint and OneDrive](m365-dr-workload-spo.md#migration-with-advanced-data-residency), [Microsoft Teams](m365-dr-workload-teams.md#migration), [Microsoft Copilot for Microsoft 365](m365-dr-workload-copilot.md#migration), [Microsoft Defender for Office P1](m365-dr-workload-mdo-p1.md#migration), [Office for the Web](m365-dr-workload-office-for-web.md#migration), [Viva Connections](m365-dr-workload-viva-connections.md#migration), [Viva Topics](m365-dr-workload-viva-topics.md#migration), [Microsoft Purview](m365-dr-workload-purview.md#migration), and [Other Services](m365-dr-workload-other.md).

+No action is needed from the customer while Microsoft moves each ADR workload and associated customer tenant data to the customer's eligible _Local Region Geography_.

+Customer administrators can visit the Message center or ΓÇ£Data locationΓÇ¥ section within the Microsoft 365 admin center throughout the migration process to review any migration notices and see when each workload service completes migration. From the Microsoft 365 admin center, customer administrators can access the Message center by navigating to **Health > Message center** and the "Data location" section by navigating to **Settings > Org settings > Organization profile > Data location**.

+The following screenshots are examples of the Microsoft 365 admin center Data location view that an ADR customer can expect to see during and after their migration.

+#### During Migration

+#### After Migration

+Data moves are a back-end service operation with minimal, if any, effect on end users. Microsoft adheres to the [Microsoft Online Services Service Level Agreement (SLA)](https://go.microsoft.com/fwlink/p/?LinkId=523897) for service availability and notifies customers of any service maintenance done via Message center in the Microsoft 365 admin center.

+Given the complex nature of services included in an E3 or E5 license, the migration of customer data from one data center to another could cause minor disruption or temporary unavailability of certain services. For more information, customer administrators can refer to the "Migration" section of each workload page within [Workload Data Residency Capabilities](m365-dr-workload-exo.md).

+Microsoft does not provide a granular status to indicate progress toward migration completion for individual customer scenarios.

+Customer administrators can stay informed of migration updates through Message center notifications and by reviewing the ΓÇ£Data locationΓÇ¥ section within the Microsoft 365 admin center to see when a workload completes migration to their _Local Region Geography_. From the Microsoft 365 admin center, customer administrators can access the Message center by navigating to **Health > Message center** and the "Data location" section by navigating to **Settings > Org settings > Organization profile > Data location**.

+For more information on Migration, customer administrators can refer to the following pages:

+[Overview and Definitions - Microsoft 365 Enterprise](m365-dr-overview.md#migrationsmoves)

+[Where your Microsoft 365 customer data is stored - Microsoft 365 Enterprise](o365-data-locations.md)

+- must-keep

+In Microsoft Entra there are two types of user objects: cloud only users and synchronized users. Follow the appropriate instructions for your type of user.

+>For new users with no OneDrive provisioned, license the account and wait at least 48 hours after a user's PDL is synchronized to Microsoft Entra ID for the changes to propagate before the user logs in to OneDrive. (Setting the preferred data location before the user logs in to provision their OneDrive ensures that the user's new OneDrive will be provisioned in the correct location.)

+>[!NOTE]

+> The Azure Active Directory module is being replaced by the Microsoft Graph PowerShell SDK. You can use the Microsoft Graph PowerShell SDK to access all Microsoft Graph APIs. For more information, see [Get started with the Microsoft Graph PowerShell SDK](/powershell/microsoftgraph/get-started).

+First, use a **Microsoft Entra DC admin**, **Cloud Application Admin**, or **Global admin** account to [connect to your Microsoft 365 tenant](connect-to-microsoft-365-powershell.md).

+```powershell

+Connect-Graph -Scopes User.ReadWrite.All

+```

+Use the following script format:

+$userUPN="<user's UPN>"

+$user = Get-MgUser -UserId $userUPN

+Update-MgUser -UserId $user.Id -PreferredDataLocation <international location code>

+In this example, you set the user adelev@contoso.com's preferred data location to EUR:

+```powershell

+$userUPN="adelev@contoso.com"

+$user = Get-MgUser -UserId $userUPN

+Update-MgUser -UserId $user.Id -PreferredDataLocation EUR

+You can check to confirm that the preferred data location was updated properly by navigating to the Microsoft 365 Admin Center and selecting **Settings > Users > Active Users > [username]**. Select the user from the list, and you'll find Preferred Data Location under the **Account** tab of the user's page.

+>For new users with no OneDrive provisioned, license the account and wait at least 48 hours after a user's PDL is set for the changes to propagate before the user logs in to OneDrive. (Setting the preferred data location before the user logs in to provision their OneDrive ensures that the user's new OneDrive will be provisioned in the correct location.)

+## OneDrive Provisioning and the effect of PDL

+If the user already has a OneDrive site created in the _Tenant_, setting their PDL won't automatically move their existing OneDrive. To move a user's OneDrive, see [OneDrive Geo Move](move-onedrive-between-geo-locations.md).

+If the user doesn't have a OneDrive site within the _Tenant_, OneDrive will be provisioned for them in accordance to their PDL value, assuming the PDL for the user matches one of the company's satellite locations.

+During the Microsoft Defender for Endpoint onboarding process, devices onboarded to Defender for Endpoint are gradually populated into the device inventory as they begin to report sensor data. Following this, the device inventory is populated by devices that are discovered in your network through the device discovery process. The device inventory has three tabs that list devices by:

+- **Uncategorized devices**: Devices that couldn't be properly classified

+Access the device inventory page by selecting **Devices** from the **Assets** navigation menu in the [Microsoft Defender portal](https://security.microsoft.com/machines).

+The device inventory opens on the **Computers and Mobile** tab. You can see at a glance information such as device name, domain, risk level, exposure level, OS platform, criticality level, onboarding status, sensor health state, mitigation status and other details for easy identification of devices most at risk.

+- The number of devices that aren't yet onboarded.

+- The number of devices with high exposure.

+- The number of newly disocovered devices.

+**OS Platform** | Filter by the OS platforms you're interested in investigating </br></br>(_Computers and mobile and IoT devices only_).

+**Windows version** | Filter by the Windows versions you're interested in investigating. If 'future version' appears in the Windows version field, it can mean:</br></br> - This is a pre-release build for a future Windows release</br> - The build has no version name</br> - The build version name isn't yet supported </br></br> In all these scenarios, where available, the full OS version can be seen in the device details page.</br></br> (_Computers and mobile only_).

+**Sensor health state** | Filter by the following sensor health states, for devices onboard to Microsoft Defender for Endpoint:</br> - **Active**: Devices that are actively reporting sensor data to the service.</br> - **Inactive**: Devices that stopped sending signals for more than seven days.</br> - **Misconfigured**: Devices that have impaired communications with service or are unable to send sensor data.</br> Misconfigured devices can further be classified to: </br> - No sensor data </br> - Impaired communications </br> For more information on how to address issues on misconfigured devices, see, [Fix unhealthy sensors](/microsoft-365/security/defender-endpoint/fix-unhealthy-sensors).</br></br> (_Computers and mobile only_).

+**Onboarding status** | Onboarding status indicates whether the device is currently onboarded to Microsoft Defender for Endpoint or not. Device discovery must be enabled for this filter to appear. You can filter by the following states: </br> - **Onboarded**: The endpoint is onboarded to Microsoft Defender for Endpoint.</br> - **Can be onboarded**: The endpoint was discovered in the network as a supported device, but isn't currently onboarded. Microsoft highly recommends onboarding these devices.</br> - **Unsupported**: The endpoint was discovered in the network, but isn't supported by Microsoft Defender for Endpoint.</br> - **Insufficient info**: The system couldn't determine the supportability of the device.</br></br> (_Computers and mobile only_).

+**Antivirus status** | Filter the view based on whether the antivirus status is disabled, not updated or unknown.</br></br> (_Computers and mobile only_).

+**First seen** | Filter your view based on when the device was first seen in the network or when it was first reported by the Microsoft Defender for Endpoint sensor.</br></br>(_Computers and mobile and IoT devices only_).

+**Internet facing** | Filter the list based on whether the device is internet facing.

+**Group** | Filter the list based on the group you're interested in investigating.</br></br> (_Computers and mobile only_).

+| 45748 | Fixed inaccuracy in Zscaler Client Connector | 14-Mar-24

+| 49672 | Fixed inaccuracy in CVE-2024-0819 | 20-Mar-24

+| 30583 | Fixed inaccuracy in Opera Browser | 21-Mar-24

+| - | Fixed inaccuracy in Autodesk Civil 3D and Anydesk | 21-Mar-24

+| 44979 | Defender Vulnerability Management doesn't currently support CVE-2017-13774 | 26-Mar-24

+| 46812 | Fixed inaccuracy in Dell Supportassist | 26-Mar-24

+| 48178 | Fixed inaccuracy in RuneLite | 26-Mar-24

+| 49660 | Fixed inaccuracy in RSUPPORT RemoteView Agent | 26-Mar-24

+| 46828 | Defender Vulnerability Management doesn't currently support OsiSoft Pi Server | 26-Mar-24

+| 48034 | Defender Vulnerability Management doesn't currently support CVE-2023-35637 | 26-Mar-24

+| - | Fixed inaccuracy in Adobe Acrobat Reader and Reader DC | 26-Mar-24

+| 46021 | Defender Vulnerability Management doesn't currently support CVE-2023-6129 | 26-Mar-24

+| - | Fixed inaccuracy in Ultraedit | 26-Mar-24

+| - | Defender Vulnerability Management doesn't currently support CVE-2023-47248 | 26-Mar-24

+| - | Fixed inaccuracy in Mitel 6920 & 6930 Firmwares | 31-Mar-24

+ > To activate Exchange Online permissions in Microsoft Defender XDR Unified RBAC, Defender for Office 365 permissions must be active.

+#### Device discovery configuration

+Device discovery settings must be activated to "Standard Discovery" at a minimum. Learn how to configure device discovery in [Set up device discovery](/microsoft-365/security/defender-endpoint/configure-device-discovery).

+Review [manage mailbox auditing](/purview/audit-mailboxes) to learn about managing mailbox auditing.

+ Different conditions use AND logic (for example, _\<recipient1\>_ and _\<member of group1\>_). The recipient must satisfy _all_ of the specified conditions, which is typically difficult or redundant. For more information, see [Recipient filters in anti-malware policies](anti-malware-protection-about.md#recipient-filters-in-anti-malware-policies).

+Recipient filters use conditions and exceptions to identify the internal recipients that the policy applies to. At least one condition is required in custom policies. Conditions and exceptions aren't available in the default policy (the default policy applies to all recipients). You can use the following recipient filters for conditions and exceptions:

+- **Users**: One or more mailboxes, mail users, or mail contacts in the organization.

+- **Groups**:

+ - Members of the specified distribution groups or mail-enabled security groups (dynamic distribution groups aren't supported).

+ - The specified Microsoft 365 Groups.

+- **Domains**: One or more of the configured [accepted domains](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in Microsoft 365. The recipient's primary email address is in the specified domain.

+You can use a condition or exception only once, but the condition or exception can contain multiple values:

+- Multiple **values** of the **same condition or exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_):

+ - **Conditions**: If the recipient matches **any** of the specified values, the policy is applied to them.

+ - **Exceptions**: If the recipient matches **any** of the specified values, the policy isn't applied to them.

+- Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+- Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+- **Users, groups, and domains** and **Exclude these users, groups, and domains**: Recipient filters to identify the internal recipients that the policy applies to. At least one condition is required in custom policies. Conditions and exceptions aren't available in the default policy (the default policy applies to all recipients). You can use the following recipient filters for conditions and exceptions:

+ - **Users**: One or more mailboxes, mail users, or mail contacts in the organization.

+ You can use a condition or exception only once, but the condition or exception can contain multiple values:

+ - Multiple **values** of the **same condition or exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_):

+ - **Conditions**: If the recipient matches **any** of the specified values, the policy is applied to them.

+ - **Exceptions**: If the recipient matches **any** of the specified values, the policy isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ > [!TIP]

+ > At least one selection in the **Users, groups, and domains** settings is required in custom anti-phishing policies to identify the message **recipients that the policy applies to**. Anti-phishing policies in Defender for Office 365 also have [impersonation settings](#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365) where you can specify **sender email addresses or sender domains that receive impersonation protection** as described later in this article.

+ You can use a condition only once, but the condition can contain multiple values:

+ - Multiple **values** of the **same condition** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy is applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ - **Exclude these users, groups, and domains**: To add exceptions for the internal recipients that the policy applies to (recipient exceptions), select this option and configure the exceptions.

+ You can use an exception only once, but the exception can contain multiple values:

+ - Multiple **values** of the **same exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+ - **Show "via" tag**: This setting is available only if you selected **Enable spoof intelligence** on the previous page. Adds tag named via (`chris@contoso.com` via fabrikam.com) to the From address if it's different from the domain in the DKIM signature or the **MAIL FROM** address. This setting is selected by default.

+ You can use a condition only once, but the condition can contain multiple values:

+ - Multiple **values** of the **same condition** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy is applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ - **Exclude these users, groups, and domains**: To add exceptions for the internal recipients that the policy applies to (recipient exceptions), select this option and configure the exceptions.

+ You can use an exception only once, but the exception can contain multiple values:

+ - Multiple **values** of the **same exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+ Different conditions use AND logic (for example, _\<recipient1\>_ and _\<member of group1\>_). The recipient must satisfy _all_ of the specified conditions, which is typically difficult or redundant. For more information, see [Recipient filters in anti-spam policies](anti-spam-protection-about.md#recipient-filters-in-anti-spam-policies).

+Recipient filters use conditions and exceptions to identify the internal recipients that the policy applies to. At least one condition is required in custom policies. Conditions and exceptions aren't available in the default policy (the default policy applies to all recipients). You can use the following recipient filters for conditions and exceptions:

+- **Users**: One or more mailboxes, mail users, or mail contacts in the organization.

+- **Groups**:

+ - Members of the specified distribution groups or mail-enabled security groups (dynamic distribution groups aren't supported).

+ - The specified Microsoft 365 Groups.

+- **Domains**: One or more of the configured [accepted domains](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in Microsoft 365. The recipient's primary email address is in the specified domain.

+You can use a condition or exception only once, but the condition or exception can contain multiple values:

+- Multiple **values** of the **same condition or exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_):

+ - **Conditions**: If the recipient matches **any** of the specified values, the policy is applied to them.

+ - **Exceptions**: If the recipient matches **any** of the specified values, the policy isn't applied to them.

+- Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+- Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ You can use an exception only once, but the exception can contain multiple values:

+ - Multiple **values** of the **same exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, ZAP for Teams protection isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, ZAP for Teams protection isn't applied to them.

+4. On the **Users, groups, and domains** page, identify the internal senders that the policy applies to (recipient conditions):

+ You can use a condition only once, but the condition can contain multiple values:

+ - Multiple **values** of the **same condition** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy is applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ - **Exclude these users, groups, and domains**: To add exceptions for the internal senders that the policy applies to, select this option and configure the exceptions.

+ You can use an exception only once, but the exception can contain multiple values:

+ - Multiple **values** of the **same exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+ - **Specific recipients**: Configure one of the following recipient conditions that appear:

+ You can use a condition only once, but the condition can contain multiple values:

+ - Multiple **values** of the **same condition** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy is applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ - **Exclude these recipients**: If you selected **All recipients** or **Specific recipients**, select this option to configure recipient exceptions.

+ You can use an exception only once, but the exception can contain multiple values:

+ - Multiple **values** of the **same exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+ You can use an exception only once, but the exception can contain multiple values:

+ - Multiple **values** of the **same exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+You can use a recipient condition or exception only once, but the condition or exception can contain multiple values:

+- Multiple **values** of the **same condition or exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_):

+ - **Conditions**: If the recipient matches **any** of the specified values, the policy is applied to them.

+ - **Exceptions**: If the recipient matches **any** of the specified values, the policy isn't applied to them.

+- Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+- Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+> One alert to release the message might be created for multiple release requests for that message. Use the **quarantine** link in the **Details** section of the alert message to take action on the release request from users in the organization for the past 7 days.

+ - **Daily** (this value results in no data being shown in charts)

+- **Recipient filters**: Conditions and exceptions to identify the internal recipients that the policy applies to. At least one condition is required. You can use the following recipient filters for conditions and exceptions:

+ - **Users**: One or more mailboxes, mail users, or mail contacts in the organization.

+ - **Groups**:

+ - Members of the specified distribution groups or mail-enabled security groups (dynamic distribution groups aren't supported).

+ - The specified Microsoft 365 Groups.

+ - **Domains**: One or more of the configured [accepted domains](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in Microsoft 365. The recipient's primary email address is in the specified domain.

+ You can use a condition or exception only once, but the condition or exception can contain multiple values:

+ - Multiple **values** of the **same condition or exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_):

+ - **Conditions**: If the recipient matches **any** of the specified values, the policy is applied to them.

+ - **Exceptions**: If the recipient matches **any** of the specified values, the policy isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ You can use a condition only once, but the condition can contain multiple values:

+ - Multiple **values** of the **same condition** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy is applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ - **Exclude these users, groups, and domains**: To add exceptions for the internal recipients that the policy applies to (recipient exceptions), select this option and configure the exceptions.

+ You can use an exception only once, but the exception can contain multiple values:

+ - Multiple **values** of the **same exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+> This article is intended for business customers who have [Microsoft Defender for Office 365](mdo-about.md). If you're using Outlook.com, Microsoft 365 Family, or Microsoft 365 Personal, and you're looking for information about Safelinks in Outlook.com, see [Advanced Outlook.com security for Microsoft 365 subscribers](https://support.microsoft.com/office/882d2243-eab9-4545-a58a-b36fee4a46e2).

+Recipient filters use conditions and exceptions to identify the internal recipients that the policy applies to. At least one condition is required. You can use the following recipient filters for conditions and exceptions:

+- **Users**: One or more mailboxes, mail users, or mail contacts in the organization.

+- **Groups**:

+ - Members of the specified distribution groups or mail-enabled security groups (dynamic distribution groups aren't supported).

+ - The specified Microsoft 365 Groups.

+- **Domains**: One or more of the configured [accepted domains](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains) in Microsoft 365. The recipient's primary email address is in the specified domain.

+You can use a condition or exception only once, but the condition or exception can contain multiple values:

+- Multiple **values** of the **same condition or exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_):

+ - **Conditions**: If the recipient matches **any** of the specified values, the policy is applied to them.

+ - **Exceptions**: If the recipient matches **any** of the specified values, the policy isn't applied to them.

+- Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+- Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ You can use a condition only once, but the condition can contain multiple values:

+ - Multiple **values** of the **same condition** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy is applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ You can use an exception only once, but the exception can contain multiple values:

+ - Multiple **values** of the **same exception** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy isn't applied to them.

+ - Different **types of exceptions** use OR logic (for example, _\<recipient1\>_ or _\<member of group1\>_ or _\<member of domain1\>_). If the recipient matches **any** of the specified exception values, the policy isn't applied to them.

+For more information about what Microsoft does to your submissions, [check this out](submissions-report-messages-files-to-microsoft.md#report-suspicious-email-messages-to-microsoft).

+ - **Allow entry note (optional)**: Enter optional information about why you're allowing this item.

+> When you make a submission to Microsoft, everything associated with the submission is copied and included in the continual algorithm reviews. This copy includes all data associated with submission, including: message content, headers, any attachments, related data about routing and all other data directly associated with the submission.

+>

+> Microsoft treats your submission as your organization's permission to analyze all the information to fine tune the submission hygiene algorithms. Your submission is held in secured and audited data centers in the USA. The submission is deleted as soon as it's no longer required. Microsoft personnel might read your submitted messages and attachments, which is normally not permitted for customer data in Microsoft 365. However, your submission is still treated as confidential between you and Microsoft, and your data isn't shared with any other party as part of the review process. Microsoft may also use AI to evaluate and create responses tailored to your submissions.

+> When a user reports a Teams message to Microsoft, everything associated with the message is copied to include in the continual algorithm reviews. This copy includes the all the data associated with the message, including: message content, headers, any attachments, related data about routing and all other data directly associated with the submission.

+> Microsoft treats your feedback as your organization's permission to analyze all the information to fine tune the submission hygiene algorithms. Your message is held in secured and audited data centers in the USA. The submission is deleted as soon as it's no longer required. Microsoft personnel might read your submitted messages and files, which is normally not permitted for Teams messages in Microsoft 365. However, your message is still treated as confidential between you and Microsoft, and your message or file isn't shared with any other party as part of the review process. Microsoft might also use AI to evaluate and create responses tailored to your submissions.

+ > The default settings on the **User reported settings** page include **Send reported messages to** \> **Microsoft and my reporting mailbox** with a blank value for the reporting mailbox. In PowerShell, there's no report submission rule. This default configuration means the reporting mailbox is the global admin's Exchange Online mailbox. The global admin isn't _shown_ as the reporting mailbox in the output of the **Get-ReportSubmissionPolicy** and **Get-ReportSubmissionRule** cmdlets or on the **User reported settings** page until _after_ the first user in the organization reports a message from Outlook. [Learn more about what Microsoft does to your submitted messages](submissions-report-messages-files-to-microsoft.md#report-suspicious-email-messages-to-microsoft).

+- **Audit mode**: Special _evaluation policies_ are created for anti-phishing (which includes impersonation protection), Safe Attachments, and Safe Links. These evaluation policies are configured to _detect_ threats only. Defender for Office 365 detects harmful messages for reporting, but the messages aren't acted upon (for example, detected messages aren't quarantined). The settings of these evaluation policies are described in the [Policies in audit mode](#policies-in-audit-mode) section later in this article. We also automatically turn on SafeLinks time of click protection in audit mode for non-email workloads (for example, Microsoft Teams, SharePoint, and OneDrive for Business)

+- **Blocking mode**: The Standard template for [preset security policies](preset-security-policies.md) is turned on and used for the trial, and the users you specify to include in the trial are added to the Standard preset security policy. Defender for Office 365 _detects and takes action on_ harmful messages (for example, detected messages are quarantined).

+ - **Domains**: All recipients in the organization with a primary email address in the specified [accepted domain](/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains).

+ You can use a recipient condition only once, but the condition can contain multiple values:

+ - Multiple **values** of the **same condition** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy is applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+ [Enhanced Filtering for Connectors](/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors) (also known as _skip listing_) is automatically configured on the connector that you specify.

+ You can use a recipient condition only once, but the condition can contain multiple values:

+ - Multiple **values** of the **same condition** use OR logic (for example, _\<recipient1\>_ or _\<recipient2\>_). If the recipient matches **any** of the specified values, the policy is applied to them.

+ - Different **types of conditions** use AND logic. The recipient must match **all** of the specified conditions for the policy to apply to them. For example, you configure a condition with the following values:

+ - Users: `romain@contoso.com`

+ - Groups: Executives

+ The policy is applied to `romain@contoso.com` _only_ if he's also a member of the Executives group. Otherwise, the policy isn't applied to him.

+- The security policies in the Standard preset security policy have a higher priority than the evaluation policies, which means the policies in the Standard preset security are always applied _before_ the evaluation policies, even if both are present and turned on.

+- _Create, modify or delete an evaluation or trial_: Membership in the **Security Administrator** or **Global Administrator** roles.

+- _View evaluation policies and reports in audit mode_: Membership in the **Security Administrator** or **Security Reader** roles.

+ZAP actions might be overridden by [Safe sender lists](create-safe-sender-lists-in-office-365.md), mail flow rules, and other organizational block and allow settings. For malware and high-confidence phishing verdicts, ZAP always takes action to protect users. Carefully consider the implications of bypassing filtering, as it may affect the security posture of your organization.