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.
- Accommodates a maximum message size of 10 MB (including attachments).
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.
The Real Person!
The Real Person!
Why not to use SMTP Relay Option 3: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365#option-3-configure-a-connector-to-send-emails-using-microsoft-365-or-office-365-smtp-relay
Is is a bad solution for sending mails in your opinion?
Well, it’s a solution that works today, However, after Microsoft deprecates SMTP AUTH with basic authentication, those methods won’t work.
The Real Person!
The Real Person!
As I understand, Option 1 (from the link above) will no longer work, but Option 3 will continue to work because it does not require authentication
Yeah. I replied too quickly last night. Too engrossed in watching election results. If you set up a connector, it should continue to work after the deprecation of basic authentication for the SMTP AUTH protocol.
The Real Person!
The Real Person!
Great article. I just tested it using basic auth from one of our apps, worked fine. Looking at the Microsoft (MS) documentation (and as your article pointed out), the use of basic auth is contrary to the direction MS are advocating with Oauth2. I hope that MS retain Basic Auth for HVE.
The Real Person!
The Real Person!
Greate article. Congratulations.
The Real Person!
The Real Person!
Just a quick question again on the 10 external user limit per minute. If you send 1 email to 200 users I assume thats fine?
You just cant send more than 10 different external emails in under a minute?
I just want to confirm that as the rest of our staff has now asked about this. We have a very small need as a post secondary to send some external mail using a smtp relay (currently uses office 365 which will be depreciated). Most is internal and in a few years it will be almost 100% internal. But we just want to understand the exact limitation so hopefully my understanding above is correct.
You can’t send to more than 10 external recipients per minute. But wait until the software is GA to see what limits Microsoft sets at that point. I will say that I did not find the limitation to be a problem because I built the necessary pauses into PowerShell scripts to send messages. Each external recipient counts as 1 recipient, so sending one email to 200 recipients is sending to 200 recipients.
The Real Person!
The Real Person!
Ok not great, using it like you are through powershell is fine, but I know our network team has firewall alerts fire off mostly internal but to maybe 10 or 11 external isp emails.
To me that falls in the category of what HVE is used for, but then were already over the limit. I dont know how they decided on this. Pretty sure when I asked on the microsoft page they said they have no plans to change this in the general release.
HVE is mainly for internal messaging. It has some external capability but that’s not what it is designed for. If you want a service to handle things like sending newsletters out to customers, investigate ECS https://practical365.com/ecs-email-communication-services/
The Real Person!
The Real Person!
When you mention adding a sleep to get around the 10 mail external limit I take it that has to be done by the application developer somewhere?
The Real Person!
The Real Person!
I also think I misread that. It says 10 message limit per external user per minute.
So I assume that’s 10 different messages being submitted in under a minute to external users.
For some reason I originally read it as only 10 external users can get sent a message each minute. Which would defeat the purpose of high volume email.
Although I’m still curious how a 5 second pause for each message would get you over the minute?
It’s a preview, so some artificial limitations exist in the current impleementation. Also, HVE is intended more for internal than external communications. There is no rate limit for internal email, and the limit for external email emphasizes the target HVE is intended to serve.
The Real Person!
The Real Person!
For sure we don’t send a lot external but some get fired off to external addresses, the scary thing though is 10 messages per minute, hopefully the odd application we house does not exceed this, most is for internal I just can’t say there’s for sure a scenario where it might not exceed it. Wonder why this was not documented the only thing mentioned is 2000 per day.
Also do you know if hve accounts passwords will expire?
I was hoping this was a solution to some of our programs using office 365 smtp basic auth but seems there’s some real limitations.
The limitations will be different when HVE is GA. Don’t judge HVE capacity to send email based on the preview.
HVE accounts and passwords are like other Entra ID accounts. It’s up to you how to maintain/expire passwords.
Yes. in Powershell, it’s the Start-Sleep cmdlet. See the example script referenced in the article.
The Real Person!
The Real Person!
I’ve heard it will be added when it’s fully released, next month maybe. It’s not that bad, just means I need to go back to a few application owners to get them to change their settings again.
The Real Person!
The Real Person!
Have been using HVE for a few months now, it’s worth noting that a lot of applications that need to relay mail won’t work with HVE because they don’t support a username and password. The trial only gives the option of Basic and not oAuth authentication, so that restricts things further.
I covered this point with the HVE developers. As noted in the article, “Microsoft told me that HVE will support OAuth connections soon.” Soon means soon.
The Real Person!
The Real Person!
As far as i understood from first community feedback there ist currently no possibility to restrict the usage /login of HVE Accounts to trusted IPs via Conditional Access. We implemented those restrictions for our decentralized printer locations (scan2email) for the SMTP Client Auth submission (Basic Auth) method. Any info on this topic would be appreciated. Maybe we will have more info on GA.
You’ll have to wait for GA. I don’t work for Microsoft, so I can’t commit to anything on their behalf.
CA requires an app identity to apply restrictions. Maybe this will come through modern authentication for SMTP connections to HVE.