Blog Post

Microsoft 365 Blog

3 MIN READ

High Volume Email Is Now Available in Exchange Online

Microsoft

Mar 31, 2026

Reliable email remains one of the most critical ways organizations communicate with employees at scale especially for operational, time‑sensitive messages like payroll notifications, security advisories, and IT service alerts. Yet for many organizations, delivering these messages has meant living with tradeoffs: maintaining on‑premises Exchange servers, relying on third‑party SMTP relay services, or repurposing user mailboxes in ways they were never designed to support.

Today, that changes. High Volume Email (HVE) is now generally available in Exchange Online, delivering a purpose‑built, tenant‑native way for applications and devices to send large volumes of internal email reliably, securely, and at scale without impacting user mailboxes or Exchange Online service health.

Why High Volume Email (HVE)

Exchange Online is optimized for person‑to‑person communication. Its built‑in limits and protections are intentional. They help preserve reliability, trust, and service health for human workflows. But those same protections can make automated, high‑volume scenarios for internal emails difficult to support cleanly.

High Volume Email was designed specifically to meet this need.

HVE is a native Exchange Online capability built for application‑to‑person messaging. It uses dedicated HVE accounts rather than user or shared mailboxes, helping to ensure automated traffic is clearly separated from human communication. For Exchange Online mail flows, messages remain entirely within Microsoft infrastructure and inherit Exchange Online’s existing security, compliance, and policy boundaries.

For customers modernizing their environments, this means high‑volume system email no longer requires legacy infrastructure or unsupported workarounds. Critical application workflows can move fully into Microsoft 365 without sacrificing reliability or governance.

Common Scenarios

High Volume Email is designed specifically for transactional and operational messaging, not marketing campaigns. It does not include campaign tooling, templates, or engagement tracking. Instead, it supports the high‑trust, high‑reliability use cases that organizations depend on every day.

Common scenarios include:

Payroll and HR system notifications
IT monitoring and service alerts
Business and line‑of‑business application messaging
Device‑driven workflows, such as printers and scanners
Security and compliance notifications

By providing a dedicated service for these scenarios, High Volume Email allows organizations to send large volumes of internal email without hitting recipient rate limits or risking service health issues associated with user mailboxes.

General Availability and Pricing

High Volume Email is now generally available in Exchange Online for sending email to internal recipients. Usage will be metered starting June 1, 2026 based on the number of expanded email recipients, with pricing set at $42 per one million recipients through Microsoft commerce (equivalent to $0.000042 per one recipient).

This pricing model is intentional and aligns usage with service protection, helping maintain fairness and reliability for high‑volume automated email scenarios.

How to Get Started

Getting started with High Volume Email is straightforward. Administrators can explore and configure the service directly in the Exchange admin center, where High Volume Email is available under Mail flow. Learn more here.

Because HVE is tenant‑native and built into Exchange Online, organizations can deploy it without introducing new infrastructure or third‑party dependencies making it easier to modernize application architectures and retire legacy email systems.

Move Critical Email Workflows Fully into Microsoft 365

High Volume Email brings a long‑needed capability to Exchange Online: a scalable, secure, and governed way to send high‑volume system email designed specifically for how modern organizations operate.

By separating automated messaging from human communication, High Volume Email protects service health, strengthens governance, and simplifies infrastructure while keeping critical communications entirely within Microsoft 365.

If you’re looking to retire legacy SMTP relay, help reduce reliance on third‑party services, or modernize how your applications communicate with employees, explore High Volume Email in the Exchange admin center today.

Updated Mar 31, 2026

Version 1.0

exchange

JeremyCarlson

Microsoft

Joined October 04, 2024

View Profile

Microsoft 365 Blog

and learn about best practices directly from the product teams.

10 Comments

Rolf Tröndle
Copper Contributor
Apr 09, 2026
with pricing set at $42 per one million recipients through Microsoft commerce ... please specify that this is a PAYG configuration using billing policies in M365 Admincenter. I couldn't find anything about that in the documentation or blog posts.
https://admin.cloud.microsoft/?#/paygplatform/paygservices
- Simone_Liebal
  Microsoft
  Apr 14, 2026
  Rolf Tröndle We will share more information about the billing configuration for HVE very soon!
  We will release the PowerShell cmdlets and Exchange Admin Center UI components (as well as documentation about the process) in the coming weeks, which will allow you to set up your configuration ahead of time, before the metered billing starts on June 1st.
- Larry Heier
  Copper Contributor
  Apr 13, 2026
  We are switching to HPV but have a suggestion/question.
  Has there been thought to create an SMTP relay service/application for on-premise to replace Exchange SMTP.? I have environments where port 25/587 is locked down save emailing to M365 and having one or two (HA) trusted SMTP applications would help with a smoother migration to the new HPV service. I know of one of my customers that has well over 100 SMTP Relays to now update. It is a good amount of work to switch over every SMTP relay to HPV or Azure and some of the older scanners/applications may not support authenticated SMTP relay.
  thanks in advance,
  Larry Heier
  - JeremyCarlson
    Microsoft
    Apr 17, 2026
    Thanks for raising this — it’s a very real migration challenge, especially in environments with a long tail of on‑premises devices and applications.
    
    High Volume Email (HVE) was designed to solve high‑scale, authenticated, application‑generated email for Microsoft 365, but it is not intended to be a drop‑in replacement for Exchange’s on‑premises SMTP relay role. In particular:
    
    HVE requires authentication (OAuth or account credentials)
    
    It does not support anonymous relay
    
    It is scoped to internal recipients only
    
    Older devices that only support unauthenticated SMTP are out of scope by design
    
    For customers with on‑premises environments that still rely on:
    
    Anonymous or IP‑based relay
    
    Large numbers of existing SMTP relay endpoints
    
    The supported migration paths today remain:
    
    SMTP relay using Microsoft 365 (via tenant MX with IP allow‑listing), or
    
    An intermediary relay layer (for example, a small number of highly‑available SMTP relay servers or services) that legacy devices point to, which then handles authenticated delivery to Microsoft 365 or HVE.
    
    The feedback around easing migration — especially for customers with many legacy relays or devices that can’t support authenticated SMTP — is absolutely valid and has been heard.
Grzegor
Copper Contributor
Apr 09, 2026
Biggest problem with this service is that it only allows mails to Internals.
- JeremyCarlson
  Microsoft
  Apr 17, 2026
  You’re correct that with the GA release today, High Volume Email (HVE) supports delivery to internal recipients within the tenant only, and external email delivery is not currently supported yet.
  
  With the currently GA’d product, HVE was introduced to address high‑scale, automated application‑generated messaging (such as monitoring alerts, HR notifications, or line‑of‑business application messages) in a way that helps keep this traffic isolated from user mailboxes and protect overall tenant mail flow health.
  
  We recognize that many customers are evaluating whether HVE could support broader outbound bulk email scenarios. Support for additional delivery scenarios is part of how we’re thinking about the continued evolution of HVE.
  
  In the meantime, scenarios that require sending to external recipients should continue to use SMTP relay, SMTP client submission, or purpose‑built email delivery solutions depending on volume and architecture needs.
DaithiG
Steel Contributor
Apr 02, 2026
As a small company would need some of these accounts for SMTP, this would just push us to a 3rd party. I know it's for High Volume but it really is a SMTP replacement and a pity there's no daily allowance before charges
- JeremyCarlson
  Microsoft
  Apr 17, 2026
  High Volume Email (HVE) is not intended to be a general‑purpose SMTP replacement, even though it uses SMTP as the transport. It was designed specifically to address a different problem: enabling very high‑scale, automated, internal messaging without impacting user mailboxes, service limits, or tenant mail flow health.
  
  For smaller environments, existing options like SMTP client submission or SMTP relay often continue to be the best fit, particularly when:
  
  Volumes are moderate
  
  External delivery is required
  
  A small number of application or device senders are involved
alexandruliviunita
Brass Contributor
Apr 01, 2026
I am currently evaluating adoption for this feature but have a few concerns:

1. It is unclear how we will be billed for this service.
Based on MC1243552 it is still free and will start being metered on June 1st.
Will it appears as an M365 pay as you go service that can be linked to an Azure Subscription, if so, when?

2. Will there be any change to the Service Limits published in : https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/high-volume-mails-m365#service-limits now that GA is announced?

3. OAuth guidance from : https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/oauth-high-volume-mails-m365 is vague about scoping the Entra ID App.
It advises we apply 'Office 365 Exchange Online' Mail.Send API Permissions to Entra ID App Registration, but provides no guidance on how Application Type permissions could be scoped to only be used for HVE Accounts.
Allowed Applications explains how the HVE Account can restrict which apps can use it, but how does this leave all the other mailboxes in our tenant?
We could restrict app scope via Application Access Policies, but this is a legacy feature and it does not scale well with HVE Accounts which cannot be added to MailEnabled Groups leading to 1:1 Application -> HVEAccount pairing and many Entra ID Apps and application access policies created.
- Simone_Liebal
  Microsoft
  Apr 14, 2026
  alexandruliviunita thank you for the detailed questions! I'll respond to them one by one.
  
  HVE will be billed through Microsoft 365 pay‑as‑you‑go and will require billing policies to be set up and linked to an Azure subscription. These billing policies can then be associated with the HVE service and assigned to individual HVE accounts. We will release the ability to configure billing policies for HVE in the coming weeks, so billing setup can be completed the ahead of time. Even if billing policies are configured for HVE prior to June 1st, usage will only start being metered from June 1st onward.
  
  The documentation reflects the up to date GA limits for High Volume Email. If those limits change in the future, updates will be reflected directly in the official documentation.
  
  The Mail.Send application permission does not grant the ability to send email from all Exchange mail users. Following the described configuration from this page, only HVE Account type mail users will be able to send email, unless the application is explicitly authorized for other mail users through Exchange application access controls. We're in process of updating the documentation to reflect this more clearly - the update will be live soon. Thank you for your feedback regarding the documentation on OAuth for HVE!