HVE for Microsoft 365: When to Use It, When Not To, and Who Should Be Allowed to Send at Scale
Microsoft recently announced the General Availability of High Volume Email for Microsoft 365, also known as HVE, in Exchange Online. This is an important and long-awaited capability for organizations that need to send large volumes of internal email from applications, devices, or line-of-business systems without using regular user mailboxes as bulk-sending engines. But HVE should not be misunderstood. It does not mean that every mailbox in Exchange Online should now be used for mass email. It does not mean Exchange Online has become a general-purpose marketing platform. And it does not remove the need for proper outbound email governance. Why HVE Matters For years, many organizations have used regular Exchange Online mailboxes, shared mailboxes, or service accounts to send automated messages from applications, scanners, monitoring platforms, ticketing platforms, and custom business applications. That approach creates several problems. Standard mailboxes are designed for human and business communication, not for sustained high-volume automated traffic. Exchange Online has recipient limits, message rate limits, outbound spam protections, and tenant-level controls to protect the service and reduce abuse. HVE introduces a more appropriate model for specific high-volume scenarios. Instead of using a normal mailbox for automated traffic, organizations can create dedicated HVE accounts and use specific SMTP endpoints, admin controls, reporting, and governance for approved high-volume internal messaging scenarios. What HVE Is Designed For HVE is designed for automated, operational, and transactional messaging at scale, primarily for internal recipients within the tenant. Examples include: Internal application notifications. Line-of-business system messages. Device-generated messages. Operational alerts. Security advisories. Internal workflow communications. Monitoring platform alerts. IT service notifications. Large-scale internal announcements generated by systems. This is especially relevant when the organization needs to send messages at scale but still wants to keep the workload within Microsoft 365 governance and Exchange Online mail flow. In practical terms, HVE is useful when the sender is not a human user, but a controlled business system. What HVE Is Not HVE is not a replacement for marketing platforms. HVE is not a general-purpose internet bulk email engine. HVE is not a way to bypass Exchange Online sending limits for external campaigns. HVE is not the correct platform for newsletters, promotional campaigns, large-scale customer communication, or high-volume external transactional email. For external transactional, marketing, or customer-facing bulk email, organizations should evaluate platforms designed for that purpose, such as Azure Communication Services Email, SendGrid, Amazon SES, Mailchimp, Brevo, or another specialized delivery platform. When to Use HVE Use HVE when the workload matches these characteristics: The sender is an application, device, service, or business system. The recipients are primarily internal users in the Microsoft 365 tenant. The volume is higher than what should be sent from a standard mailbox. The workload is operational, automated, or transactional. The organization needs centralized Microsoft 365 administration and reporting. The organization wants to avoid impacting user mailbox sending limits. The use case is approved, documented, monitored, and governed. Good examples: A security platform sending internal security advisories. A monitoring system sending infrastructure alerts to internal teams. A business workflow system sending high-volume approval or status notifications. An IT service platform sending internal notifications. A service management platform sending ticket updates to internal users. A device management system sending operational messages to internal teams. When Not to Use HVE Do not use HVE when the workload is external bulk email. Avoid HVE for: Marketing campaigns. Newsletters to customers. Promotional email. Mass external invitations. External transactional email at scale. Customer invoices and receipts in high volume. OTP or password reset flows for external users. External portal notifications. Any workload where deliverability, bounce handling, reputation management, unsubscribe handling, analytics, or customer consent management are required. Those workloads require a platform designed for external delivery, reputation management, suppression lists, opt-out, tracking, bounce handling, and compliance. Who Should Be Allowed to Use HVE HVE should not be enabled casually for every team or every application. It should be treated as a controlled platform capability. Recommended eligible senders: Approved line-of-business applications. Corporate systems owned by IT, Security, Operations, Facilities, or Service Management teams. Managed devices or services with a clear business purpose. Internal platforms that send operational messages to employees. Applications with documented ownership, authentication, monitoring, and expected volume. Recommended non-eligible senders: Normal users. Shared mailboxes used by humans. Marketing teams sending to external audiences. Unmanaged scripts. Legacy systems with no owner. Applications with unknown volume. Systems that send to external recipients at scale. Any application using HVE just to avoid standard mailbox limits. The core principle is simple: HVE should be enabled for workloads, not for convenience. Governance Model Before enabling HVE, organizations should define a governance model. At minimum, each HVE account should have: A named business owner. A technical owner. A documented purpose. Expected daily and monthly volume. Recipient scope. Authentication method. Monitoring process. Incident response path. Decommissioning criteria. Review frequency. HVE accounts should not become invisible service accounts that nobody owns. They should be treated as privileged communication identities. Security and Authentication HVE supports OAuth authentication, and Microsoft provides guidance for restricting OAuth authentication to specific Microsoft Entra ID applications. This is important because organizations should avoid broad, uncontrolled access. They should restrict which applications can send through each HVE account, monitor usage, and separate workloads by purpose. For example: One HVE account for security alerts. One HVE account for monitoring systems. One HVE account for IT service notifications. One HVE account for internal operational communications. This separation improves visibility, investigation, accountability, and risk containment. HVE vs Standard Exchange Online Mailboxes A standard Exchange Online mailbox should be used for normal human communication. A shared mailbox should be used for collaborative business processes. An HVE account should be used for approved high-volume internal system email. A dedicated external delivery platform should be used for marketing, bulk external communication, or high-volume transactional email. Scenario Recommended Platform Human business email Exchange Online mailbox Team or department mailbox Shared mailbox Low-volume application notifications Standard Exchange Online, if approved High-volume internal system notifications HVE Internal operational alerts at scale HVE Marketing campaigns Marketing platform External transactional email Transactional email service Customer newsletters Marketing automation platform OTP/password reset for external users Dedicated transactional platform External bulk email Dedicated bulk email provider HVE and the Mailbox External Recipient Rate Limit Cancellation Microsoft also announced that the Mailbox External Recipient Rate Limit in Exchange Online was cancelled indefinitely. However, that cancellation should not be interpreted as permission to use Exchange Online for uncontrolled bulk sending. Microsoft was clear that other limits remain unchanged, including the existing Recipient Rate Limit and the Tenant-level External Recipient Rate Limit. That distinction is important. The cancellation of one mailbox-level external recipient limit does not remove the need for proper architecture. Exchange Online still has service limits. Outbound spam controls still apply. Tenant-level protections still matter. And HVE is still not a marketing engine. Practical Architecture Decision Before enabling HVE, ask these questions: Who is sending? Is the sender a human, shared mailbox, application, or device? Who are the recipients? Are they internal or external? What is the expected volume? Is the workload operational, transactional, promotional, or human communication? Does the business need Microsoft 365 mail flow and governance? Does the use case require bounce handling, unsubscribe, tracking, or reputation management? Is the application properly authenticated and monitored? Who owns the account? Who approves the sending pattern? Who responds if the account is abused? If the workload is internal, automated, high-volume, and business-approved, HVE may be the right answer. If the workload is external, promotional, customer-facing, or marketing-driven, use a dedicated email delivery platform. Recommended Enablement Approach Organizations should enable HVE in phases. First, identify existing systems currently using user mailboxes, shared mailboxes, or SMTP AUTH for automated sending. Second, classify each workload as internal, external, operational, transactional, marketing, or human communication. Third, migrate only approved internal high-volume workloads to HVE. Fourth, move external high-volume workloads to dedicated email delivery platforms. Fifth, monitor usage and review HVE accounts regularly. This avoids turning HVE into another uncontrolled sending layer. Conclusion High Volume Email for Microsoft 365 is an important addition to Exchange Online. It gives organizations a native way to support high-volume internal system messaging without using standard mailboxes for automated high-volume traffic. But HVE is not a free pass for bulk email. It is not a marketing platform. It is not a replacement for transactional email services. And it should not be enabled for every mailbox or every application. The right approach is workload classification. Use Exchange Online for corporate communication. Use HVE for approved high-volume internal system messaging. Use dedicated platforms for external bulk, marketing, and transactional email. The question is not only: “Can this system send email through Microsoft 365?” The better architectural question is: “What type of email is this, who is the audience, and what is the correct platform for this workload?” That is where proper email architecture begins.
Exchange Server to Exchange Online Migration: A Pre-Migration Readiness Checklist
Over the years, I have worked on numerous Exchange Server to Exchange Online migration projects alongside Exchange administrators, IT teams, and MSPs. One consistent pattern I have noticed is that most migration issues do not originate during the migration itself — they surface because of gaps in pre-migration readiness. This checklist reflects what I have found most useful before starting any Exchange to Exchange Online migration. Inventory and Assessment Before touching any migration tooling, run a full inventory of your on-premises Exchange environment. This includes the Exchange Server version (2013, 2016, 2019), the number of mailboxes, database sizes, public folders, shared mailboxes, archive mailboxes, and any resource mailboxes such as rooms and equipment. Many teams also forget to document their distribution groups, dynamic distribution groups, and mail-enabled contacts. All of these need to be accounted for before you begin. 2. Active Directory and Entra ID Readiness Check that your Active Directory is clean: no duplicate UPNs, no lingering objects, and no ambiguous legacy Exchange attributes. Verify that Microsoft Entra Connect (formerly AAD Connect) is installed, configured, and synchronizing without errors. Confirm the UPN suffix used in AD matches a verified domain in your Microsoft 365 tenant. Attribute mismatches between on-premises AD and Entra ID are one of the most common causes of post-migration issues with authentication and mail flow. 3. Mail Flow and DNS Document all current MX records and any third-party mail filtering (SEG, anti-spam appliances). Plan whether you will cut over MX during the migration or keep a hybrid mail flow via Exchange connector. Verify SPF, DKIM, and DMARC records are in place for each domain. Applications and devices that use on-premises SMTP relay also need to be identified early — these often get missed and cause disruption after the migration window. 4. Licensing and Tenant Configuration Confirm you have sufficient Exchange Online licenses assigned or ready to assign before the migration starts. Review your tenant for any conditional access policies that may block newly migrated users. Check the Microsoft 365 admin center for any service health issues that could affect the migration window. Also confirm your tenant's default accepted domains and any aliases that need to be added. 5. Coexistence and Hybrid Considerations If you are running a hybrid migration (which is the recommended approach for most organisations with more than a few hundred mailboxes), confirm the Hybrid Configuration Wizard has been run and that the hybrid connector tests pass. Free/busy lookup, OAB distribution, and cross-premises message tracking should all be tested before you move any mailboxes. A common oversight is failing to validate OAuth configuration for modern authentication in hybrid — this affects calendar sharing and delegate access after migration. 6. Data and Backup Before migrating any mailbox, verify that a recent backup of your Exchange databases exists and is recoverable. If you are running a DAG, confirm all database copies are healthy and no replay queues are building up. It is also worth checking the size and age of any archive mailboxes — large archives can significantly extend migration time and should be planned for separately. What patterns have you seen in your environments? Are there specific pre-migration steps that have saved (or cost) you the most time? Happy to discuss further.
Offboarding mailboxes fails with “PropTagToPropertyDefinitionConversionException.”
Hybrid M365 setup, just recently upgraded the on-prem server from Exchange 2019 to Exchange SE. After doing so, migrations from Exchange Online back to Exchange On-prem fail at 10% with the error “PropTagToPropertyDefinitionConversionException.” I opened a case with M365 exchange support, and after some time, they came back to tell me that the Exchange Online portion of the process is not at fault, and that I have to engage the on-premise support team (this seems a little nuts to me, as its all connected and all supported, but I've been in this business for 30 years now, and it's not the first time I've seen buck-passing), and/or ask this community for help. Hence, this post. That error appears exactly two places on the internet, as far as I can tell: a blog (in German) from an Exchange expert doing cross-tenant migrations, and a page at https://west.jcteams.info/bhit11/docs/EX1232513.html that seems to describe my exact issue. Neither had useful suggestions - mostly, they say this: Set-MoveRequest -Identity "<UserPrincipalName>" -SkipMoving FolderRestrictions Resume-MoveRequest -Identity "<UserPrincipalName>" That didn't actually work, but when I tried the same parameters with Set-MigrationBatch, they worked as long as I ignored the message "The SkipMoving parameter is deprecated. Use the MoveOptions parameter instead. If you have any scripts that use the SkipMoving parameter, update them to use the MoveOptions parameter." So what was a simple process is now a more cumbersome workaround. Does anyone have an idea on how to troubleshoot "PropTagToPropertyDefinitionConversionException?"Impact of Reduced DigiCert SSL Certificate Validity on Exchange Hybrid Environment
DigiCert is reducing certificate validity periods because of new industry requirements approved by the CA/Browser Forum. This is not a DigiCert-only decision all public Certificate Authorities must follow these limits. DigiCert is making this change to align with the CA/Browser Forum’s Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods. This ballot sets a timeline for all Certificate Authorities (CAs) to reduce TLS certificate validity from 398 days to 200 days in 2026, 100 days in 2027, and 47 days in 2029. Impact on Microsoft Exchange Hybrid For environments like Hybrid (Exchange Server SE Hybrid with Edge servers): You'll need to renew your public SSL certificate more frequently. Manual renewal processes will become increasingly difficult. Consider implementing certificate lifecycle automation where supported. Existing certificates remain valid until they expire; the new limits apply to newly issued or renewed certificates. In Hybrid environment (Exchange Server SE, Exchange Hybrid, multiple Mailbox servers, Edge servers, and DigiCert public SSL certificates): No need to rerun the Hybrid Configuration Wizard (HCW) solely because you renewed the SSL certificate, provided the renewed certificate uses the same subject name/SANs and is assigned to the required Exchange services. The primary impact is operational: you'll need a robust and preferably automated certificate renewal and deployment process across your Mailbox servers, Edge servers, and any load balancers to keep pace with the shorter certificate validity periods.Exchange Hybrid Configuration Wizard - Error 1603 - Connector registration failed
Did any of you encounter this error while installing hcw on an exchange server? Here is the event viewer error details: Connector registration failed: Make sure you are a Global Administrator of your Active Directory to register the Connector. Error: '"The registration request was denied. "'
Hybrid Exchange 2019 move to M365
Dear All, I am asked to move/ migrate the existing Hybrid Exchange to M365. All mailboxes are located in M365. MX Record is pointing to the third-party spam filtering company which we are not too sure either stay with them or not. My next concern is the Send and Receive connectors. has any one of you done similar task like this? any help or document/ link would be much appreciated. Regards
Preserving permissions during EXO migration
Hi, Can you help me understand the outcome of preserving the permissions in our scenario. Exchange Server 2016 (soon Exchange SE) in a hybrid with Exchange Online. We are moving 75% of the mailboxes to Exchange Online. What ways will preserve or break the full-access or sendas permissions? I guess best way would be to migrate both the user and the shared mailbox at the same time in the same batch to keep the permission? If we migrate the user in batch 1 and shared mailbox in batch 2 will that preserve/break the full access/send as? If we migrate the shared mailbox in batch 1 and usermailbox in batch 2 will that preserve/break the full access/send as? If the permission is linked directly on the shared mailbox or via a security group is there a difference? Thanks!
Mailbox for Service Account (exchange online)
Hi Our organisation isn't ready to move to Exchange Online yet, though we have Office 365 e3 licencing. I need to create a service account that can send emails via Outlook 365 for use In Power Automate. The documentation I have seen for adding a mailbox to an existing AAD user requires assigning an exchange licence to the account via the licence portal. I can't see any such licences though we do have e3 licencing which are visible that I assume covers this? Unfortunately the admin who did the original configuration has moved on and I don't have a global admin role so have to go through a support team that can't help me with my lack of knowledge in the area! Any advice would be very much appreciated as what ( i think) should be a simple task has taken a lot of time to try and get to the bottom of! Thanks, Dale.Cross Tenant Mailbox Migration: NotAcceptedDomainException
This week I'm performing a new cross tenant mailbox migration. I have some experience with this kind of migrations, ( it's the third one I'm in charge of ), and with the new procedure, ( will paste the link with the instructions at the end of this article ), an Azure Key Vault is no longer required, so I was very confident and thought that I would no have any issue. But, as sometimes occurs, I was wrong The setup was quite easy, and the mail users configuration was like always, so no a big deal. But now comes the point... Once I launched the migration batch, half of the users started syncing correctly and the ther ones failed, ( neither a MoveRequest was able to start for them ). Once I checked the errors, I got the same for all the failed ones: " NotAcceptedDomainException: You can't use the domain because it's not an accepted domain for your organization ". Ok. No problem... ( I thought ). I work with Exchange since more than 10 years and this is a common error message. ( Again I was wrong ). I started to check the mail users, looking for some misspelled domain, missing alias, spaces, etc... Basically, the troubleshooting for this kind of errors. But from my perspective all looked good. So, I decided to reconfigure all the mailusers with a script, launch a delta sync, and resume the failed moverequest. But again, same error for all of them. Checked again, with PS, from source and target tenant, checked in AD, all the proxy addresses... Nothing, all was correct! Non sense... Ok. At that point I decid to compare some syncing mail users with some failed ones, looking for anything that could be a pattern. And "voilá"! The syncing users were all licensed in O365... The failed ones not! After assigning a license to the failed ones and resume the MoveRequest, all started to work smoothly. For sure, I would have saved many hours of work if the error message had been: " The user is not licensed ". But, yeah... It would have been too simple 🙂 Summarizing, make sure that the mail users have an O365 license before you start the migration batch. And remember, not always the error messages are what they seems to be 🙂 Cross Tenant Mailbox Migration procedure, ( Preview 😞 https://docs.microsoft.com/en-us/microsoft-365/enterprise/cross-tenant-mailbox-migration?view=o365-worldwide
