Exchange Online’s New High Volume Email (HVE) Solution

HVE SMTP-based Messaging Designed for Internal Communications (and Some External Email)

As a shared service, Exchange Online has always limited the ability of mailboxes to send higher-than-normal volumes of email. The rationale is no single account should be able to hog resources to the detriment of others. Exchange Online uses a mechanism called the recipient rate limit to set a threshold for the traffic that an individual mailbox can generate. The recipient rate limit controls the number of individual recipients for outgoing messages that can be on messages sent from a mailbox. The current rate is 10,000 recipients daily. When computing the number of recipients in a day, a distribution list or Microsoft 365 group counts as a single recipient.

The imposition of the recipient rate limit is an effective solution to prevent tenants from sending large quantities of unsolicited commercial email (spam). Throttling kicks in when a single mailbox attempts to send an unexpectedly large number of messages. Things will become even harder for potential spammers when Exchange Online introduces the external recipient rate (ERR) limit to restrict sending to 2,000 recipients daily. The ERR is scheduled for implementation in January 2025 (Microsoft 365 message center notification MC787382).

It’s still possible to send large quantities of messages from an Exchange Online tenant by dividing traffic across multiple mailboxes or using distribution lists to address multiple recipients. However, what’s clear is that the Microsoft 365 messaging team has its eyes firmly focused on curtailing unwanted sending behavior, and future blocks might be erected to limit spammers if needed.

Many third-party solutions exist for legitimate sending of large quantities of email to external recipients. Azure Communication Services (ACS), or rather, the Email Communication Service resource within ACS, is Microsoft’s solution for managing high-volume email communications with external recipients.

What High-Volume Email Does

The downside of applying a recipient rate limit is that the limit applies to both internal and external email. That might not seem such a big problem for small businesses, but a 10,000-recipient limit can become a barrier in large tenants in scenarios like employee communications. High-Volume Email (HVE) is a new Exchange Online feature that Microsoft hopes will address the problem. According to Microsoft’s April 1 announcement for the preview, HVE is “designed primarily for line of business applications and other high-volume SMTP AUTH submissions that enables you to send internal messages beyond the current limits of Exchange Online.”

The three takeaways from that statement are “apps,” “SMTP AUTH”, and “internal messages.” In a nutshell, HVE:

• Is used by apps, not by end users.
• Processes messages submitted by SMTP Auth (generated and submitted using PowerShell or another language) rather than email clients like Outlook or OWA.
• Sends to internal recipients (those with email addresses belonging to a domain owned by the tenant) rather than external recipients (those with email addresses that don’t belong to the tenant). HVE supports the delivery of messages to external recipients with a limit of 2,000 recipients per HVE account daily.

Microsoft isn’t charging tenants to participate in the preview. Given that one of Microsoft’s goals for HVE is to use “a consumption-based billing model,” expect this to change after HVE is generally available. It’s likely that use of HVE will incur charges on a Pay-As-You-Go (PAYG) basis paid through an Azure subscription, like other Microsoft 365 solutions such as Microsoft 365 Backup.

HVE Accounts

HVE accounts are Entra ID accounts without Exchange Online mailboxes. The accounts are a way to authenticate when submitting messages via SMTP for Exchange Online to process. The accounts also serve as an accounting object in that HVE allows each tenant to send messages to up to 100,000 recipients daily (ten times the recipient rate limit). During the preview, a tenant can support up to 20 HVE accounts to spread traffic across. Microsoft says that they will increase these limits when HVE reaches general availability later this year. Creating a new HVE account can be done using PowerShell:

$NewPassword = ConvertTo-SecureString -AsPlainText "Dublin@@!!"
New-MailUser -LOBAppAccount -Name "HVE01" -Password $NewPassword -PrimarySmtpAddress HVE01@office365itpros.com

But it’s easier to use the facility to create HVE accounts in the Mail flow section of the Exchange admin center (Figure 1).

Curiously, the Exchange admin center does not allow administrators to update account settings, like the display name for the sender shown in message headers. Apparently, a UI update is on the way.

Receiving an email from a sender like “HVE01 account” isn’t likely to excite anyone. I changed the display name to “Office 365 for IT Pros Email Communications” using the PowerShell Set-User cmdlet. It’s also possible to update an account’s display name through the Entra admin center.

Using SMTP AUTH

In April 2024, Microsoft announced their intention to retire basic authentication for SMTP AUTH in Exchange Online in September 2025. This marks the conclusion of the long-running project to eradicate basic authentication for email connection protocols. The fact that HVE uses SMTP AUTH to connect to Exchange Online seems to run contrary to the advice given by Microsoft to customers for the last several years and certainly confused some following the HVE announcement.

Basic authentication means that the credentials for HVE accounts are transmitted to Exchange Online in clear text over a secure connection. This is less of a problem than it might seem because all communication occurs within the tenant and the HVE accounts are only used for HVE access. Given that Exchange Online now supports OAuth for SMTP connections, and Microsoft told me that HVE will support OAuth connections soon.

To allow HVE accounts to use basic authentication with SMTP AUTH, you must create an Exchange Online authentication policy. Here’s how to create the authentication policy and assign it to a HVE account. You can see that the only protocol enabled for basic authentication is SMTP AUTH:

New-AuthenticationPolicy -Name "High Volume Email" -AllowBasicAuthSmtp
Set-User HVE01 -AuthenticationPolicy "High Volume Email"

Without assigning the ability to the HVE accounts to submit messages using basic authentication with SMTP AUTH, any attempt to send a message will fail with the error “5.7.139 Authentication unsuccessful, basic auth is blocked.”

Sending Messages with HVE

Organizations will probably use PowerShell to submit messages to HVE. The typical scenario is for a script to import recipient addresses from a file into an array and then loop through the array to send email to each recipient. The recipient can be a personal email address or the email address of any other mail-enabled object such as a distribution list, shared mailbox, or a Microsoft 365 group.

HVE accounts don’t have regular mailboxes, so the Graph API-based methods to send email don’t work with HVE. Instead, we step back in time to the old Send-MailMessage cmdlet. Microsoft deprecated Send-MailMessage a couple of years ago because it cannot guarantee secure transmission to SMTP servers. This doesn’t matter for HVE because all communications are within the tenant boundary. However, it would be nice to suppress the warning posted for each use of the cmdlet:

WARNING: The command 'Send-MailMessage' is obsolete. This cmdlet does not guarantee secure connections to SMTP servers. While there is no immediate replacement available in PowerShell, we recommend you do not use Send-MailMessage at this time. See https://aka.ms/SendMailMessage for more information.

In the future, Microsoft might publish a documented procedure to configure email clients like Outlook Classic and Thunderbird so that regular clients can submit messages to HVE. That’s not available now, but even so, I suspect that PowerShell will remain the focus for most because of the ability to personalize message content before submission.

I wrote a version of the classic “send welcome messages to new users” script to show how to do the job with HVE. The script (available from GitHub) does the following:

• Connects to Exchange Online.
• Runs the Get-ExoMailbox cmdlet to find recently added mailboxes.
• Asks the operator for the password for the HVE account to use. In a production environment, it would be better to store the username and password in a secure location like Azure Key Vault and retrieve the credentials from there.
• For each user, create a hash table containing the message parameters for submission and then run the Send-MailMessage cmdlet to submit the message to HVE.

The code to build the message parameters and submit the message is shown below.

$SendHVEMessageParams = @{
    From = 'HVE1@office365itpros.com'
    To = $User.PrimarySmtpAddress
    Bcc = 'Customer.Services@office365itpros.com'
    Subject = "Welcome to Microsoft 365"
    Body = $Content
    Credential = $HVECredentials
    UseSsl = $true
    SmtpServer = 'smtp-hve.office365.com'
    Port = 587
    BodyAsHtml = $True
}   
Try {
    Send-MailMessage @SendHVEMessageParams -ErrorAction Stop 
} Catch {
    Write-Host ("Failed to send email to {0} with error {1}" -f $Recipient, $_.Exception.Message)
}

Important points about the message parameters include:

• Specify the HVE account as the sender. HVE doesn’t support the Exchange Online Send As permission.
• HVE doesn’t support a reply-to address yet. A workaround is to include a mailto: address in the body content.
• Submit messages to the special HVE SMTP server smtp-hve.office365.com using port 587. Only HVE accounts can authenticate against this endpoint.
• Make sure that PowerShell uses TLS 1.2 or 1.3.

If no error appears, you can assume that HVE has accepted and sent the message. You won’t be able to tell if a message fails to be delivered to its final destination because HVE does not process non-delivery notifications.

Throttling

The HVE preview imposes some rate limits for message submission. Some are documented, such as no more than 2,000 external recipients daily. The most important restriction that Microsoft doesn’t document is the 10-message submission limit per minute for messages containing external recipients. This limit is encountered very quickly because most people will try and submit a bunch of messages to see how HVE handles the load. As soon as HVE hits the limit, it refuses to accept further submissions and signals the error:

Mailbox unavailable. The server response was: 4.5.104 Message rejected. Excessive message rate from sender. The HVE message can't be submitted because the rate limit for external emails has been exceeded.

The limit is easily overcome by inserting a Start-Sleep 5-second pause after the submission of each message sent to an external recipient. Another workaround is to create some more HVE accounts (the preview allows up to 20 HVE accounts per tenant) and spread the submission load across the available HVE accounts. However, it’s annoying that HVE is quite so hardline here as the low limit handicaps any testing of HVE capabilities.

You can’t get around the 2,000 external recipient daily limit. Once the threshold is reached, HVE signals this error, and no further messages can be sent from the HVE account until the limit is reset.

Failed to send email to xxx@xxx.org with error Mailbox unavailable. The server response was: 4.5.102 Message rejected. Excessive message rate from sender. The HVE message can't be submitted because the sender's submission tenant quota for external recipients was exceeded.

HVE Reporting

HVE gets its own section in the EAC reports menu. The data available is always at least a day old and the report shows how many messages each HVE account handled during the selected reporting period (Figure 2). There’s no breakdown between external and internal recipients and there’s no indication of how many errors occurred during submissions or delivery.

An export option is available but doesn’t seem to include anything except the number of messages processed per day.

It’s also possible to request that Exchange run a background report containing “details about the messages that were sent from your High Volume email accounts.” This option covers messages sent at least two days ago. The generated report (Figure 3) is a simple list of messages, recipients, and message identifiers, which can be used to run a standard Exchange Online message trace.

According to Microsoft, a new reporting framework will be available at GA that will deliver much faster access to submission data.

HVE Summary

HVE is still in preview, so gaps and issues are bound to exist. The documentation is OK, but some examples would have been nice. It’s noticeable that HVE coverage in independent blogs essentially repeats the Microsoft documentation without adding any value (surely a form of plagiarism?). With functional examples and clear explanations of how features work, people can do great things. So far, that hasn’t happened for HVE.

The bottom line is that the availability of HVE removes another reason for Microsoft 365 tenants to keep an on-premises server to handle email sent by apps and devices. Microsoft has some work to smoothen the rough edges and improve functionality before HVE achieves general availability. However, their bigger challenge might be to convince customers to move over to a pay-as-you-go service for email.