Merge pull request #7355 from MicrosoftDocs/main

Auto Publish – main to live - 2026-04-30 07:30 UTC

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

defender-office-365/mdo-support-teams-about.md

@@ -47,8 +47,6 @@ Microsoft Defender for Office 365 Plan 1 provides the following extra Teams prot
 
 - **Report Teams items**: Users can report Teams items (messages or calls) as malicious or not malicious. Depending on the reported items settings in the organization, reported items go to the specified reporting mailbox, to Microsoft, or both. For more information, see [User reported settings in Teams](submissions-teams.md) and the following video:
 
-  [!VIDEO https://www.youtube.com/watch?v=ungHDS4XG4I]
-
 Microsoft 365 E5 and Defender for Office 365 Plan 2 extend Teams protection with a set of extra capabilities designed to disrupt the attack chain:
 
 - **Remove users from Teams chat**: To remediate malicious attacks, you can remove users from teams chats directly from the [Teams message entity panel](teams-message-entity-panel.md#remove-users-from-teams-chats-in-the-teams-message-entity-panel).

defender-office-365/submissions-admin.md

@@ -10,7 +10,7 @@ ms.collection:
 ms.custom: seo-marvel-apr2020
 description: "Admins can learn how to use the Submissions page in the Microsoft Defender portal to submit messages, URLs, and email attachments to Microsoft for analysis. Reasons for submission include: legitimate messages that were blocked, suspicious messages that were allowed, suspected phishing email, spam, malware, and other potentially harmful messages."
 ms.service: defender-office-365
-ms.date: 10/27/2025
+ms.date: 04/29/2026
 appliesto:
   - ✅ <a href="https://learn.microsoft.com/defender-office-365/eop-about" target="_blank">Built-in security features for all cloud mailboxes</a>
   - ✅ <a href="https://learn.microsoft.com/defender-office-365/mdo-about#defender-for-office-365-plan-1-vs-plan-2-cheat-sheet" target="_blank">Microsoft Defender for Office 365 Plan 1 and Plan 2</a>
@@ -245,6 +245,9 @@ After a few moments, the block entry is available on the **URL** tab on the **Te
 
 ### Report good email to Microsoft
 
+> [!NOTE]
+> Submitting a message as "should not have been blocked" doesn't automatically override impersonation protections in your tenant. For recurring legitimate senders flagged by [domain or user impersonation protection](anti-phishing-policies-about.md#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365), update the **Trusted senders and domains** section in the [anti-phishing policy](anti-phishing-policies-mdo-configure.md#use-the-microsoft-defender-portal-to-modify-anti-phishing-policies) that detected the message, or create an allow entry in the [Tenant Allow/Block List](tenant-allow-block-list-about.md).
+
 1. In the Defender portal at <https://security.microsoft.com>, go to **Actions & submissions** \> **Submissions**. Or, to go directly to the **Submissions** page, use <https://security.microsoft.com/reportsubmission>.
 
 2. On the **Submissions** page, verify that the **Emails** tab is selected.

defender-xdr/alert-policies.md

@@ -2,7 +2,7 @@
 title: Alert policies in the Microsoft Defender portal
 ms.author: guywild
 author: guywi-ms
-ms.date: 03/31/2026
+ms.date: 04/29/2026
 ms.topic: article
 ms.service: defender-xdr
 ms.localizationpriority: medium
@@ -115,6 +115,9 @@ You can also define user tags as a condition of an alert policy. This definition
 
 - **Email notifications**. You can set up the policy so that email notifications are sent (or not sent) to a list of users when an alert is triggered. You can also set a daily notification limit so that once the maximum number of notifications is reached, no more notifications are sent for the alert during that day. In addition to email notifications, you or other administrators can view the alerts that are triggered by a policy on the **Alerts** page. Consider enabling email notifications for alert policies of a specific category or that have a higher severity setting.
 
+    > [!NOTE]
+    > Some alert policies generate aggregated alerts. In these cases, activity from multiple users or entities might be included in a single alert when events occur within the policy's aggregation window. Aggregation behavior depends on the alert type and workload, and might not be configurable for certain system alerts. Licensing affects which alert policies and configuration options are available, but doesn't necessarily change aggregation behavior.
+
 ## Default alert policies
 
 Microsoft provides built-in alert policies that help identify Exchange admin permissions abuse, malware activity, potential external and internal threats, and information governance risks. On the **Alert policies** page, the names of these built-in policies are in bold and the policy type is defined as **System**. These policies are turned on by default. You can turn off these policies (or back on again), set up a list of recipients to send email notifications to, and set a daily notification limit. The other settings for these policies can't be edited.

sentinel/includes/service-limits-table-manaement-ingestion.md

@@ -14,12 +14,11 @@ The following table lists the service parameters and limits for the Microsoft Se
 | Category                                         | Parameter/limit                              |
 |--------------------------------------------------|----------------------------------------------|
 | Workspaces per tenant                             | 20 workspaces                |
-| Data ingestion per minute to a data collection endpoint    | 50 GB                              |
-| Default ingestion volume rate threshold in LALog Analytics workspaces | 6 GB/min uncompressed   |
-| Ingestion requests per minute to a data collection endpoint | 15,000                            |
 | Lake Retention (Asset data)                       | 12 years                                    |
 | Lake Retention (Aux)                              | 12 years                                    |
 | Maximum size for field values (Log Analytics)     | 32 KB (truncated above the limit)           |
 | Table setup latency during onboarding              | 90-120 minutes                             |
 | New table setup latency                            | 90-120 minutes                             |
 | Switching data between tiers latency               | 90-120 minutes                             |
+
+For information on Log Analytics workspace ingestion limits, see [Log Analytics workspaces, data collection volume and retention](/azure/azure-monitor/fundamentals/service-limits#logs-ingestion-api).