Exchange Online High Volume Email (HVE): Configure for Internal Notifications Without Breaking Mail Flow

Exchange Online · Mail Flow · Internal Notifications · 2026

Send large volumes of internal notifications from LOB apps and devices — without hitting Exchange limits or breaking existing mail flow.

📅 Check official docs for current release status 💰 Billing model: check official docs 🔧 Exchange Online PowerShell

Exchange Online has always had sending limits. The recipient rate limit (10,000 recipients per day per mailbox) and the message rate limit exist to protect the shared infrastructure from abuse — and they work. But for organisations running internal notification systems, HR communications, automated alerting from line-of-business applications, or scan-to-email workflows, these limits become an operational constraint.

High Volume Email (HVE) is Microsoft's answer to that constraint. Microsoft announced a March 2026 GA target, but the official documentation page is still marked as Public Preview at the time of writing — check the official HVE documentation for the current release status before planning a production rollout, and it does something specific: it provides a dedicated SMTP endpoint with no internal recipient rate limit, designed exclusively for sending to recipients inside your tenant. It does not change how regular mailboxes work, it does not affect your existing mail flow rules, and it does not require you to purchase additional licences for the accounts.

This article covers everything you need to configure HVE correctly — account creation, authentication, Conditional Access exemptions, and the errors you will almost certainly encounter on first attempt.

!

Internal recipients only. Since June 2025, HVE only delivers to recipients within your tenant. Sending to external addresses returns a hard bounce: 550 5.5.105 External sending is not supported for High Volume Email accounts. For high-volume email to external recipients, use Azure Communication Services Email — Microsoft's dedicated service for programmatic and transactional email to external addresses.

1

Pricing: Check the official HVE documentation for the current billing status and pricing model before rollout. Microsoft has indicated that a billing model will apply after the current promotional period, but the final model and timing should be confirmed there.

2

HVE accounts have no mailbox and no licence. They are MailUser objects used exclusively for SMTP submission. Do not assign an Exchange Online licence to them — it is unnecessary and may cause unexpected behaviour.

3

Basic Auth supported until September 2028 on the HVE endpoint (smtp-hve.office365.com), separate from the standard endpoint (smtp.office365.com) where Basic Auth is being phased out. OAuth is also supported and recommended for new implementations.

In this article

Exchange limits vs HVE Create an HVE account Authentication Conditional Access Test the configuration Monitoring Common errors Checklist

Exchange Online limits vs HVE: what changes and what doesn't

HVE does not modify any existing behaviour in your tenant. It adds a separate sending path that operates independently of your standard mailboxes.

Capability

Standard mailbox

HVE account

Notes

Internal recipient rate limit

10,000/day

No limit (per docs)

Per published HVE guidance — validate current limits in official docs before production

External recipients

Yes

Not supported

Removed June 2025

SMTP endpoint

smtp.office365.com:587

smtp-hve.office365.com:587

Different endpoint — do not use smtp.office365.com

Authentication

OAuth (Basic deprecated)

Basic Auth or OAuth

Basic Auth on HVE until Sep 2028

Has a mailbox

Yes

No

Send-only — cannot receive

Requires a licence

Yes

No licence needed

Do not assign one

Max accounts per tenant

—

See note

Microsoft documentation is currently inconsistent on the preview limit — verify the current tenant limit in the official docs before rollout

Max recipients per message

500

50

Use distribution groups for larger audiences

Affected by mail flow rules

Yes

Yes

HVE traffic passes through EOP — existing transport rules apply

Billing

Included in licence

Pay-as-you-go (date TBC)

Verify current billing status in official docs

💡

The 50-recipient-per-message limit matters. If your LOB application or notification system sends to distribution groups, the 50-recipient limit applies to the SMTP envelope recipients — not the members of the group. Sending to one DL that expands to 5,000 members counts as 1 envelope recipient. This is the correct approach for large internal audiences.

---

Step 1 — Create the HVE account

HVE accounts cannot be converted from existing user accounts or synced from Active Directory. They must be created as new objects. If you need to reuse an existing email address, you must first remove it from the current account before assigning it to the new HVE account.

Option A — Exchange Admin Center (recommended for initial setup)

1

Navigate to Mail flow → High Volume Email

Open admin.exchange.microsoft.com → Mail flow → High Volume Email. If the menu item is not visible, the feature may not yet have rolled out to your tenant — check Message Center for rollout communications.

2

Select Add an HVE account

Provide a display name (this will appear as the sender name in email headers — choose something meaningful like HR Notifications or IT Alerts), a primary SMTP address in one of your accepted domains, and a password. Aliases are optional.

3

Review and create

The account appears in the HVE accounts list. Note the primary SMTP address — this is the username for SMTP authentication. The endpoint is smtp-hve.office365.com on port 587 with TLS.

Option B — PowerShell

⚠️

Validate cmdlet syntax before running. The New-MailUser -HVEAccount cmdlet may behave differently depending on your Exchange Online PowerShell module version. If you get a "positional parameter" error, ensure you are using named parameters without line-continuation backticks, and that you are connected with Connect-ExchangeOnline and not with legacy MSOL/EXO v1 modules. Verify the current parameter set in the official HVE documentation.

Create an HVE account via Exchange Online PowerShell PowerShell

# Connect to Exchange Online PowerShell
Connect-ExchangeOnline

# Create the HVE account - prompts for a password securely
$pwd = Read-Host "Enter HVE account password" -AsSecureString

New-MailUser -HVEAccount -Name "HVE-HRNotifications" -DisplayName "HR Notifications" -PrimarySmtpAddress "hr-notify@contoso.com" -Password $pwd

# Verify the account was created
Get-MailUser -HVEAccount | Select-Object DisplayName, PrimarySmtpAddress, RecipientType

# Update the display name if needed (this is what recipients see as sender)
Set-User "HVE-HRNotifications" -DisplayName "HR Notifications - Contoso"

⚠️

Do not assign a licence to the HVE account. HVE accounts are MailUser objects — not user mailboxes. Assigning an Exchange Online licence is unnecessary and may cause unexpected behaviour. If you accidentally assign one, remove it immediately.

---

Step 2 — Configure authentication

This is the step where most HVE deployments fail. Exchange Online has tenant-level and policy-level controls that block Basic Auth SMTP, and HVE's Basic Auth goes through a different endpoint but still requires an explicit policy allowance. OAuth is supported and recommended for new implementations — it avoids these issues entirely.

Option A — Basic Auth (for legacy devices and LOB apps)

Even though SmtpClientAuthenticationDisabled is set to True at the tenant level, HVE accounts can still use Basic Auth because they use the smtp-hve.office365.com endpoint, not the standard client submission endpoint. However, you still need to ensure the Authentication Policy assigned to the HVE account allows Basic Auth SMTP.

Create and assign a Basic Auth policy for HVE PowerShell

Connect-ExchangeOnline

# Check current authentication policies in your org
Get-AuthenticationPolicy | Format-List Name, AllowBasicAuthSmtp

# Check the org-wide default policy
Get-OrganizationConfig | Select-Object DefaultAuthenticationPolicy

# Check if the default policy blocks SMTP Basic Auth
Get-AuthenticationPolicy -Identity "Default Authentication Policy" |
    Select-Object AllowBasicAuthSmtp

# If AllowBasicAuthSmtp is False on the default policy,
# create a new policy that allows it and assign it to the HVE account
New-AuthenticationPolicy -Name "Allow Basic Auth SMTP - HVE" -AllowBasicAuthSmtp

# Assign the policy to the HVE account
Set-User "hr-notify@contoso.com" -AuthenticationPolicy "Allow Basic Auth SMTP - HVE" -STSRefreshTokensValidFrom (Get-Date)

# The -STSRefreshTokensValidFrom forces immediate token invalidation
# Without it, the new policy can take up to 24 hours to apply

# Verify the policy is assigned
Get-User "hr-notify@contoso.com" | Select-Object AuthenticationPolicy

Option B — OAuth (recommended for new implementations)

OAuth avoids the Basic Auth policy issues entirely and is the right choice for any new integration where the sending application supports it. The configuration uses an Entra ID app registration with the Mail.Send permission — the Exchange Online permission used by HVE for both delegated and application OAuth flows. See the OAuth for HVE documentation for the full configuration.

Register an Entra ID app for HVE OAuth PowerShell

# Connect to Microsoft Graph (requires Application.ReadWrite.All)
Connect-MgGraph -Scopes "Application.ReadWrite.All"

# Create the app registration
$app = New-MgApplication -DisplayName "HVE-HRNotifications-App"

# Add Mail.Send permission for Exchange Online
# Do NOT hardcode permission GUIDs from this article.
# Confirm the correct ResourceAppId and Mail.Send scope ID in your tenant:
#   Entra admin center > App registrations > [app] > API permissions
#   > Add a permission > APIs my organization uses > Office 365 Exchange Online
#   > Delegated permissions > Mail.Send  (or Application permissions for daemon flows)
# Full guide: learn.microsoft.com/en-us/exchange/mail-flow-best-practices/oauth-high-volume-mails-m365

Write-Host "App ID: $($app.AppId)"
Write-Host "Tenant admin must grant consent at:"
Write-Host "https://login.microsoftonline.com/<tenantId>/adminconsent?client_id=$($app.AppId)"

# Full OAuth configuration guide:
# https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/oauth-high-volume-mails-m365

💡

For the complete OAuth configuration including token acquisition and SMTP connection with OAuth credentials, see OAuth authentication for high volume emails for Microsoft 365 on Microsoft Learn. The app registration above is the Entra ID side — the SMTP client side depends on your sending application or library.

---

Step 3 — Conditional Access exemption

This is the second most common failure point. If your tenant has Conditional Access policies that block legacy authentication — including the Microsoft-managed Block legacy authentication policy that is automatically created in newer tenants — HVE accounts using Basic Auth will fail to authenticate with error AADSTS53003: BlockedByConditionalAccess.

⚠️

Security Defaults block HVE entirely. If Security Defaults are enabled in your tenant, Basic Auth SMTP is blocked and cannot be exempted. You must either disable Security Defaults and move to Conditional Access (requires Entra ID P1) or use OAuth for HVE. Running neither Security Defaults nor Conditional Access is a serious security gap — do not do this.

Create an Entra ID group and exclude it from legacy auth Conditional Access policies PowerShell

Connect-MgGraph -Scopes "Group.ReadWrite.All", "Policy.ReadWrite.ConditionalAccess"

# Create a dedicated security group for all HVE accounts
$group = New-MgGroup `
    -DisplayName     "SG-Exchange-HVEAccounts" `
    -MailEnabled     $false `
    -SecurityEnabled $true `
    -MailNickname    "SG-Exchange-HVEAccounts"

# Add the HVE account to the group
# Note: search by DisplayName, not by email address
$hveUser = Get-MgUser -Filter "displayName eq 'HVE-HRNotifications'"
New-MgGroupMember -GroupId $group.Id -DirectoryObjectId $hveUser.Id

# List all Conditional Access policies to find those blocking legacy auth
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State |
    Where-Object { $_.DisplayName -like "*legacy*" -or $_.DisplayName -like "*block*" }

# For each relevant policy, add the group to the exclusion list
# This must be done in the Entra admin center UI for Microsoft-managed policies:
# Entra ID > Security > Conditional Access > [policy] > Exclude > Groups
# Add: SG-Exchange-HVEAccounts

# Also exclude from any CA policy requiring MFA, compliant devices, or known device platforms
# HVE SMTP sessions do not report a device platform

💡

When adding HVE accounts to the Entra group, you can only search by display name — not by email address or UPN. In the example above, the display name is HVE-HRNotifications (the -Name parameter used during account creation). Plan your naming convention before creating accounts at scale.

---

Step 4 — Test the configuration

Test before updating any production applications. The quickest way is Send-MailKitMessage (recommended — Send-MailMessage is deprecated) or a direct SMTP connection with Telnet or OpenSSL.

Test HVE sending with Send-MailKitMessage PowerShell

# Install Send-MailKitMessage if not already available
Install-Module -Name Send-MailKitMessage -Scope CurrentUser -Force

$credential = Get-Credential # Enter hr-notify@contoso.com and its password

Send-MailKitMessage `
    -SMTPServer  "smtp-hve.office365.com" `
    -Port        587 `
    -Credential  $credential `
    -UseSecureConnectionIfAvailable `
    -From        "hr-notify@contoso.com" `
    -RecipientList "you@contoso.com" `
    -Subject     "HVE Test - please confirm delivery" `
    -TextBody    "This is a test message from the HVE account."

# If this fails, check the error message against the common errors section below.
# Most failures are authentication-related (CA policy or auth policy).
# After a successful test, update your apps/devices to use smtp-hve.office365.com

⚠️

Use smtp-hve.office365.com — not smtp.office365.com. This is the single most common configuration error. The HVE endpoint is different from the standard client submission endpoint. Sending to smtp.office365.com with HVE credentials will fail authentication.

---

Step 5 — Monitor usage

HVE includes a dedicated usage report in the Exchange Admin Center. Monitoring volume per account matters both for governance and to understand future cost exposure when billing starts.

1

Exchange Admin Center → Reports → Mail flow → High Volume Email

Shows message volume per HVE account over time. Select an account and use Request report to get a detailed breakdown by recipient, with date range filtering.

2

Set per-account volume limits

At GA, admins can set custom volume thresholds per HVE account. Use this to cap spend for accounts that should only be sending a few thousand messages per day, and to detect if a compromised account starts sending anomalously.

3

Message Trace in Exchange Admin Center

HVE messages are traceable in the standard Reports → Mail flow → Message trace. Filter by the HVE account's sender address to diagnose delivery issues or confirm messages are reaching recipients.

---

Common errors and what they mean

Error

Cause

Fix

535 5.7.139 Authentication unsuccessful, basic auth is blocked

Authentication policy blocks Basic Auth SMTP

Create a policy with -AllowBasicAuthSmtp and assign it to the HVE account with Set-User -AuthenticationPolicy

AADSTS53003: Access has been blocked by Conditional Access policies

CA policy blocking legacy auth applies to the HVE account

Add the HVE account (or its group) to the exclusion list of all CA policies that block legacy auth, require MFA, or require compliant devices

535 5.7.139 Authentication unsuccessful, the organization configuration does not allow this

Security Defaults enabled in the tenant

Disable Security Defaults in Entra ID → Properties and implement Conditional Access instead (requires Entra ID P1). Or use OAuth.

Client not authenticated to send mail. Error: 535 5.7.57

Wrong SMTP endpoint — connecting to smtp.office365.com instead of the HVE endpoint

Change the SMTP server to smtp-hve.office365.com port 587

550 5.5.105 External sending is not supported for High Volume Email accounts

Message addressed to an external recipient

Remove external recipients. HVE is internal-only. Use Azure Communication Services for external high-volume email.

No valid OAuth 2.0 authentication session exists

Running Connect-SPOService or Exchange cmdlets without a valid session, or token expired

Re-run Connect-ExchangeOnline. For HVE SMTP, ensure the authentication policy change has propagated — use -STSRefreshTokensValidFrom (Get-Date) to force immediate effect

Authentication policy change takes up to 24 hours

Token cache still using old policy

Use Set-User -STSRefreshTokensValidFrom (Get-Date) immediately after assigning the new auth policy to force instant propagation

---

Configuration checklist

• Create the HVE account with a meaningful display nameThe display name is what recipients see in the From field. Use something recognisable: HR Notifications, IT Alerts - Contoso. Avoid generic names like HVE01.
• Do not assign a licence to the HVE accountHVE accounts are MailUser objects. A licence is unnecessary and may cause unexpected behaviour.
• Check and configure the Authentication PolicyRun Get-AuthenticationPolicy | FL Name, AllowBasicAuthSmtp. If the default policy blocks SMTP, create a dedicated policy with -AllowBasicAuthSmtp and assign it to the HVE account.
• Use -STSRefreshTokensValidFrom to force immediate policy propagationWithout this, the new authentication policy can take up to 24 hours to apply. Include it in the Set-User command immediately after assigning the policy.
• Create a dedicated Entra ID group for HVE accountsName it clearly: SG-Exchange-HVEAccounts. Add all HVE accounts to it. Use this group as the exclusion target in Conditional Access policies.
• Exclude the HVE group from all relevant Conditional Access policiesThis includes: policies that block legacy auth, policies requiring MFA, policies requiring compliant devices, and policies filtering by device platform. HVE SMTP sessions do not report a device platform.
• Test with smtp-hve.office365.com on port 587 before updating production appsUse Send-MailKitMessage for testing. Confirm the message is received by an internal recipient before pointing any production system at the new endpoint.
• Use distribution groups for audiences larger than 50The per-message recipient limit is 50 envelope addresses. Send to a DL that contains your target audience — the DL counts as one recipient regardless of how many members it has.
• Monitor usage in the HVE reportEstablish a baseline of message volume so you can model future costs when billing starts. Verify the current billing status and pricing model in the official HVE documentation.
• Plan migration to OAuth if your sending application supports itBasic Auth on the HVE endpoint is supported until September 2028. Start planning the OAuth migration now for any application that can support it — it removes the Authentication Policy and most Conditional Access complications.

---

Get in touch

Need help configuring HVE?

Get in touch if you want help with HVE configuration, Conditional Access policy design, or planning a migration from Basic Auth SMTP.

Official references

Sources

• Microsoft Learn — Manage high volume email for Microsoft 365
• Microsoft Learn — OAuth authentication for HVE
• Microsoft Learn — Troubleshoot HVE issues
• Exchange Team Blog — Basic Auth support until September 2028
• Exchange Team Blog — HVE public preview announcement