My Issues With High Volume Email


A few months ago (July 2025) I wrote an article on how to set up the new, but still in preview High Volume Email (HVE) service in Microsoft 365/Exchange Online.

I’ve been using it for a while now, so here are the issues I have found. Hopefully these get resolved before the product goes into general release, as all these issues are not issues with the generic SMTP endpoint in Office 365 that HVE is designed to replace.

1. Ciphers

The HVE endpoint is smtp-hve.office365.com and is completely separate infrastructure than the legacy auth based smtp.office365.com endpoint. Microsoft list online the ciphers that TLS supports in Office 365, and I have found that HVE does not support the same list. Therefore you can have a scan or print to email device that can connect to smtp.office365.com but not to smtp-hve.office365.com.

The High Volume Email service supports the following ciphers (all these are Elliptical Curve ciphers):

  • TLS 1.3:
    • TLS_AES_256_GCM_SHA384
    • TLS_AES_128_GCM_SHA256
  • TLS 1.2:
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

HVE also only supports TLS 1.2 and TLS 1.3, so if you are using the legacy TLS endpoint (which is opt in, and which supports TLS 1.0 and TLS 1.1) and is part of M365, reachable via smtp-legacy.office365.com, then you will have devices which will not work with HVE as presumably you are using the legacy opt-in endpoint because the standard endpoint also is not working for you.

2. Timeouts

The HVE endpoint TCP connection times out at one minute. The legacy endpoint times out at five minutes. This means that any action that takes longer than 60 seconds to complete on the HVE endpoint will result in a disconnection. I have an example where I can scan a single page to email but not multiple pages! This worked on the legacy smtp.office365.com endpoint.

Of course this is likely an issue with my hardware, in that it probably opens a connection and then scans the document page(s) and then send the scan as an email to HVE. If the scanning takes more than one minute the connection closes. Ideally the device should scan, open the connection and send, but it does not and this means that this legacy printer only works (currently) with the legacy endpoint and not HVE. The legacy endpoint is being turned off in nine months, so there is work to be done by Microsoft on this.

3. Email Size

This is covered in step 4, as this is where I discovered it, but it’s important enough to have its own entry on this list. HVE allows a max email size of 10MB but the legacy endpoint allows for 150MB.

Sure, the recipient mailbox might have a lower size limit and the email not arrive, but it should not be configured that the service itself is not able to do at least the default email size of Office 365 which is 35MB.

4. SMTP Commands

Connecting to the legacy endpoint and starting an Enhanced SMTP session (EHLO devicename) returns a number of supported SMTP features. Doing the same on the HVE endpoint returns considerably less.

I have covered message SIZE in the above item as it was worth calling out on its own, but here are the other SMTP protocol commands supported (or not):

smtp.office365.com

220 servername.outlook.office365.com Microsoft ESMTP MAIL Service ready at Tue, 2 Sep 2025 11:37:09 +0000 []
EHLO testdevice
250-servername.outlook.office365.com Hello [w.x.y.z]
250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8

smtp-hve.office365.com

220 ic3-transport-smtp-lob-deployment-id-id Microsoft ESMTP MAIL Service ready at Tue, 2 Sep 2025 11:39:28 +0000 ()
EHLO testhvedevice
250-ic3-transport-smtp-lob-deployment-id-id Hello [w.x.y.z]
250-SIZE 10485760
250-STARTTLS
250 CHUNKING

So, what can we work out from this? Firstly, any errors are not going to include enhanced status codes. This might not be an issue, but an email getting returned with “550” is not as good as getting “550 5.1.10”. 550 means “server error”, but 550 5.1.10 means “server error – recipient was not found”.

Next, the lack of support for SMTPUTF8 means the messages only support ASCII characters and not unicode. Specifically this is Email Address Internationalization (EAI) support as defined in RFC 6531, 6532 and 6533. So anything the printer adds to the message in unicode is possibly unreadable.

There are other features not supported, such as the two MIME options, but these are less likely to be an issue – though if your printer requires them and they work with the legacy endpoint we should expect them to work with the HVE endpoint as well and they will not. 8BITMIME means SMTP supports 8-bits ASCII but HVE only claims to support 7-bit ASCII. BINARYMIME supports a more efficient way to send binary data (i.e. a scan from a printer) to the SMTP server endpoint.

5. Bounces

Any error in HVE for email delivery is likely to be sent back to the sender. But the sender is an account without a mailbox, and so no-one can login and look for errors in email flow. With the legacy endpoint you could assign an Exchange Online licence to the account and create a shared mailbox that would hold any responses from the SMTP endpoint (i.e. the 550 5.1.10 mentioned above). But this is not possible for HVE as you should not licence these accounts and give them a mailbox.

So HVE should have the option to provide a bounce address that any error is copied to in addition to being returned to the sender. Now its possible to create bounces@defaultdomain account and any bounce to a non-existent address ends up here, but this is for everything and not specific to HVE. And of course, the HVE account exists, so the bounces mailbox might ignore these messages!

6. Azure Communication Services

This is not High Volume Email, or is it! It is an option to use when replacing the legacy SMTP endpoint (HVE or ACS), and connecting to the ACS SMTP endpoint shows a number of similarities to HVE and some differences. So for completion for this article, here is what you might get or not get if you use Azure Communication Services for high volume email instead of the HVE endpoint:

220 ic3-transport-smtp-acs-deployment-id-id Microsoft ESMTP MAIL Service ready at Tue, 2 Sep 2025 11:54:55 +0000 ()
EHLO azurecommdevice 250-ic3-transport-smtp-acs-deployment-id-id Hello [w.x.y.z]
250-SIZE 31457280
250-STARTTLS
250 CHUNKING

The HVE endpoint looks very similar to the ACS endpoint from a server name perspective (“acs” instead of “lob” in the name). But the ACS endpoint supports a message size of 30MB. The ciphers are likely to be different from Microsoft 365 as well, as this is an Azure endpoint and not an M365 endpoint.

7. HVE Is Not Really An SMTP Service!

I’m being intentionally obscure here. Of course it is an SMTP service – but only from the viewpoint of the sender, but it is not an SMTP service from the viewpoint of the recipient. HVE can only deliver email to recipients in your tenant, and it does this by writing the message directly into the mailbox of the target recipients using an API. If you look at the received headers of a HVE delivered email you will not see any SMTP protocol in use:

Receive headers for a HVE delivered email – no SMTP to be seen!

This means that you HVE email is not DKIM signed, and does not need to be, as its not delivered by SMTP and for the same reason, the HVE endpoint does not need to be added to your SPF record in DNS. Final comment on this means that DMARC has no say with HVE and other SMTP protections such as DANE and MTA-STS do not need to fall into any consideration of using the service.


by

Tags:

Comments

2 responses to “My Issues With High Volume Email”

  1. Thomas Kijanski avatar
    Thomas Kijanski

    Hi and thanks a lot for your thorough investigation! We’ve also noticed connection issues trying to transition from the “normal” SMTP endpoint to the HVE endpoint especially for older services, including printers and UPS systems, and thought it must be related to higher minimum cipher requirements. Your post was really helpful to confirm that the HVE endpoint acts differently, practically preventing us from migration for now. Here’s hoping that Microsoft will implement changes to increase compatibility.

    1. Brian Reid avatar

      But I do not think they will implement changes. I read that basic auth even on HVE will go by September 2028 so by then any device that only supports SMTP Auth will not be able to connect to the High Volume Email service. The cipher question is a more complex one, as to move to HVE is beginning to be driven by the removal of SMTP Auth in Exchange Online but these devices often also require support for older ciphers, but M365 generally is limiting its support for anything except elliptical curve ciphers (or better when they exist) – this includes HVE.

Leave a Reply to Brian Reid Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.