High Volume Email (HVE) in Microsoft 365: internal mail from applications and devices without a licensed mailbox

HVE is Microsoft's replacement for SMTP AUTH with a service mailbox. A dedicated HVE account, no licence, no rate limit, pay per recipient. It works from any network, including Azure VMs. Two conditions: recipients must be in your tenant, and the device must do TLS 1.2 and log in.

Does HVE fit your case?

Recipients	Internal only. "HVE accounts cannot be used for external email delivery."
Works from Azure or a hosted application	Yes. Port 587, nothing to do with port 25.
Device needs TLS	Yes, required. TLS 1.2 or 1.3.
Device needs a login	Yes. HVE account username and password, or an OAuth token.
Rate limits	None per recipient or per message. Up to 50 recipients per message, 10 MB per message.
Accounts	Up to 100 HVE accounts per tenant. They cannot receive mail and cannot be in distribution lists.
Cost	$0.000042 per delivered recipient, so $42 per million. 3,000 messages a month is about $0.13. Billed through Azure pay-as-you-go.
Sent Items	No.
Cloud	Microsoft 365 Worldwide only. Not GCC, GCC High or 21Vianet at the time of writing.

Step 1. Set up pay-as-you-go billing once

An HVE account without a billing policy cannot send. The policy links Microsoft 365 to an Azure subscription that pays the per-recipient fee.

You need an Azure subscription. A new one from the Azure portal is fine; HVE costs cents.
In the Microsoft 365 admin center go to Billing → Pay-as-you-go and connect the Azure subscription. Create a billing policy.
On the same page connect the policy to the High Volume Email service.

You need Global Administrator or Billing Administrator in Microsoft 365 and Owner on the Azure subscription.

Step 2. Create the HVE account

In the Exchange admin center:

Mail flow → High Volume Email → Add an HVE account.
Display name, primary address in an accepted domain, for examplescanner-hve@contoso.com, and a password that meets your policy.
Select the billing policy from step 1. Review, Create.

Or in Exchange Online PowerShell:

Connect-ExchangeOnline
New-MailUser -HVEAccount -Name "Scanner HVE" -PrimarySmtpAddress scanner-hve@contoso.com
Get-BillingPolicy -ResourceType HVE
Set-HVEAccountBillingPolicy -Identity scanner-hve@contoso.com -BillingPolicyId "<guid from the line above>"
Set-HVEAccountSettings -Identity scanner-hve@contoso.com -ReplyTo it@contoso.com

The ReplyTo matters: the HVE account has no mailbox, so replies from your users would otherwise bounce. Wait until the Account status column showsActive.

Step 3. Check the authentication rules of your tenant

If Security Defaults are on in Entra ID, basic authentication is blocked for everything, including HVE. Then the device must use OAuth, see step 5, or you create an authentication policy that allows basic auth for the HVE account only.
SMTPClientAuthenticationDisabled in the transport config does not block HVE. HVE has its own endpoint.
Conditional Access policies that block legacy authentication apply to HVE basic auth too. Exclude the HVE account or use OAuth.

Step 4. Configure the device or application

Setting	Value
SMTP server or smart host	`smtp.hve.mx.microsoft`. The older `smtp-hve.office365.com` still works but will be retired.
Port	587
TLS or STARTTLS	Enabled, TLS 1.2 or 1.3
Authentication	Username `scanner-hve@contoso.com` and its password, or OAuth
From address	The HVE account address
To	Mailboxes, shared mailboxes or groups in your tenant, up to 50 per message

For many recipients, send to one distribution list instead of 50 addresses. Billing counts recipients after the list is expanded.

Step 5. OAuth instead of a password (optional)

For an application you control, use client credentials instead of a stored password:

Entra admin center → App registrations → New registration.
API permissions → Add → APIs my organization uses → Office 365 Exchange Online → Application permissions → Mail.Send. Grant admin consent.
Certificates & secrets: add a client secret or, better, a certificate.
Request a token for the scope https://outlook.office.com/.default and present it with AUTH XOAUTH2 as user=scanner-hve@contoso.com.
Restrict which applications may use the account, so Mail.Send does not become a tenant-wide right:
```
Add-HVEAppAccess -Identity scanner-hve@contoso.com -AppIds <service principal object id>
```
Use the object ID from Enterprise applications, not from App registrations.

With this configuration the application can send only as HVE accounts. Other mailboxes stay closed unless you open them with RBAC for Applications.

Step 6. Test and watch usage

Send a test to yourself. Then Exchange admin center → Reports → Mail flow → High Volume Email shows recipient and message volume per account. If the test fails:

Symptom	Cause
`535 5.7.3 Authentication unsuccessful`	Wrong password, Security Defaults on, or a Conditional Access policy blocks legacy auth.
Account status Not active	No valid billing policy. Step 1 and 2.
Mail to an external address bounces	By design. HVE is internal only.
Device cannot connect at all	No TLS 1.2 on the device, or it tries port 465. HVE is 587 with STARTTLS only.

When HVE cannot work

Any external recipient. This is the hard limit.
The device has no TLS 1.2 or cannot authenticate: old scanners, Windows 2012 era applications, hardware that only speaks plain SMTP to a host in its own subnet.
No Azure subscription allowed in your organisation, because billing goes through one.

For external recipients from a device that can log in, seeAzure Communication Services Email. For a device that cannot log in, with a static IP, the relay connector. For a device that cannot log in, without a static IP, SMTP Bridge.

Sources: Microsoft Learn, Manage High Volume Email for Microsoft 365(April 2026, updated August 2026) and Use OAuth authentication for High Volume Email (March 2026).