Forum Widgets
Latest Discussions
Emails from Azure Communication Services (ACS) are treated as external emails
When using Azure Communication Services (ACS) Email, messages are delivered to Microsoft 365 as external mail, even if the system sending them belongs to my own organization. This behavior can be expected because ACS sends emails from Microsoft’s cloud infrastructure rather than directly from my tenant. As a result, Distribution Groups (DG), Dynamic Distribution Groups (DDG), or Mail-enabled Security Groups (SG) that are configured to accept messages only from internal senders will reject these emails. The common workaround is to enable “Allow external senders” on the group. However, we don't want to open the group to the entire internet. Does anyone else have the same experience? What is the best solution, exchange transport rules? Thanks!Microsoft Rushes High-Volume Email to General Availability
Almost two years after it first previewed, Microsoft is making the High-Volume Email (HVE) solution generally available in March 2026. HVE runs on a pay-as-you-go basis, but Microsoft won’t start charging tenants for sending email until May 2026. Two months should be enough for people to decide if they want to use HVE for internal communications as it has no ability to send external email. https://office365itpros.com/2026/03/09/hve-ga/Measuring KPIs like Response Times for Shared Mailboxes
Shared mailboxes are not CRM systems. However, many Microsoft 365 tenants use shared mailboxes to handle customer queries and then want to measure KPIs such as agent responsiveness to customer queries or the number of queries handled per agent in a month. As explored in this article, it’s possible to use the Microsoft Graph and PowerShell to extract some KPI-like data from shared mailboxes. https://office365itpros.com/2026/03/05/shared-mailbox-kpi/
Proper whitelisting of microsoft.com on dnswl.org
I keep having the issue that system-generated e-mails, e.g. on Trace Reports get classified as spam by the receiving e-mail provider. The sender address is email address removed for privacy reasons and the e-mails go to my M365 mailbox and are redirected to my external monitoring mailbox with that e-mail provider. The e-mail provider calculates a score that includes checking the sender's IP address 52.101.69.91 with dnswl.org . Unfortunately, that address is only whitelisted for outlook.com and some secondary domains, but not for microsoft.com. Of course, the issue also occurs with mailto:email address removed for privacy reasons and other IP addresses, so this is an example. It started to occur around two weeks ago, not sure if the provider changed policies or Microsoft changed the whitelisting; of course the provider refuses to overrun dnswl.org it, e.g. by own whitelisting. Who at Microsoft could I ask to fix that kind of issues? I don't find any appropriate category in their support menues, M365 support says the cannot help (TrackingID#2603031420001611). Thanks in advance for any hints, this is my first posting here, so please forgive me, if this is a dumb question.
Report for email reply time for shared mailbox
Hi All, i am looking to crate report for management for our KPI. Management want to to know how quick teams are replying to email once it's landed to mailbox. Also, average reply time for the particular mailbox for a day or week or month. if nay one know how to achieve this please let me know it will be grate help. Thanks, PreyashExchange online - track deleted mail
I am 365 admin and see quite often people rapport "all my mails are in deleted post - and I have done nothing" or similar What is the best practice to investigate that. I know in powershell I have made some auditsearches, where it rapports like softdelete, hardelete etc - but is there any more specific way proving that the user actually did in on his own ? - I know with retention policies it is hard delete - but just wondering what the best practice is like to prove to the user that this is the user. Just write that it is soft deleted and means user have done it, often the user think is not understandableExchange database dismounted due to NTFS file extent limit reached – unexpected outage
Hi everyone, We experienced a serious outage on our Exchange 2016 server recently, and I wanted to share what we found during the root cause analysis – in case it helps someone else avoid the same scenario. Summary: After digging deep, we discovered that the issue was caused by the NTFS file system hitting its internal file extent limit on the .edb file. Once this threshold was reached, the database could no longer grow, and the system dismounted the database unexpectedly. No prior warning, just service interruption. Details: The .edb was around 1.2 TB in size. This isn’t a limit on database size itself — it’s about how fragmented the file is on disk. Once NTFS couldn’t track any more extents, the database stopped working. Microsoft doesn’t publish a clear fix for this; only scattered references to similar behavior in past cases. What we did: Created a fresh, clean database. Manually moved user mailboxes into the new DB. The old database couldn't be mounted anymore, so we brought the system live without historical mail – just to maintain continuity. We're now working on extracting data from the unmounted .edb using third-party tools. Looking for thoughts: Has anyone else hit the NTFS extent wall with Exchange? How do you monitor extent growth proactively? Did switching to ReFS solve this for you long-term? Open to any input or similar experiences – appreciate it in advance. Thanks!
Retire last Exchange Server but keep directory sync
Hello all -- I'm looking for guidance on the recommended way to retire our last Exchange 2019 server while maintaining directory synchronization in our environment. We do not have any mail flowing through our exchange server, never have. It was only installed 10 years ago for a hybrid deployment. I believe one supported path is to stand up a member server and install the Exchange Management Tools on it. Given that Exchange 2019 is already out of support, is the the long term path moving forward? I've also read about an attribute "IsExchangeCloudManaged". In this scenario, I can set this on a per-mailbox basis and manage attributes such as proxyaddresses, extension attributes, and other non-AD-managed attributes. Is this the more forward path to take? Thinking about our user provisioning process now, we have a PowerShell script that creates the user in AD and connects to our hybrid Exchange server to Enable-RemoteMailbox. In this scenario, we would still create the user in AD, wait for the sync to happen, then enable the IsExchangeCloudManaged. Would this now provide the ability to manage additional addresses, or even, shared mailboxes without having to migrate from AD --> EXO - all while keeping AD in sync with cloud mailboxes? Am I thinking about this correctly? Thanks for any insight sb
