Microsoft 365 SMTP Relay Options: SMTP AUTH, Direct Send, Connector Relay and HVE

Microsoft 365 SMTP Relay Options: SMTP AUTH, Direct Send, Connector Relay and HVE

Originally published 10 October 2020 · Reviewed 5 November 2026

Printers, scanners, monitoring tools and line-of-business applications all need to send email, but none of them is a mail server. Microsoft 365 gives you several ways to let them send, each with different security, limits and requirements. This article compares the options Microsoft documents today. One warning first: the authentication rules for Exchange Online have been changing for years, so confirm the current retirement dates on Microsoft's pages before you build anything new.

The four methods

Microsoft's guidance lists these options:

• Client SMTP submission (SMTP AUTH). The device signs in as a licensed mailbox and sends through smtp.office365.com.
• SMTP relay. The device sends to your tenant's MX endpoint, and an inbound connector recognises it.
• Direct Send. The device sends unauthenticated mail directly to your tenant's MX endpoint, as if it were an outside server.
• High Volume Email (HVE). A purpose-built account type for large volumes of mail to internal recipients.

Client SMTP submission

This is the familiar option. The device uses port 587, which is recommended, or 25, with TLS 1.2 or 1.3, and the credentials of a mailbox. Messages appear to come from that mailbox and are saved to its Sent Items. It can send to internal and external recipients and works from any location, including third-party hosting.

Key limits are 10,000 recipients per day and 30 messages per minute per mailbox, so it is unsuitable for bulk mail. Devices that default to port 465 do not meet the required TLS versions. If the device must send as a different address, the signed-in account needs Send As permission, otherwise you will see a 5.7.60 error.

The important warning is about authentication. Microsoft states that client SMTP submission using Basic authentication in Exchange Online is scheduled for deprecation, and recommends OAuth where the device supports it. Basic authentication also does not work with security defaults, and SMTP AUTH is disabled by default for organisations created after January 2020, so it must be enabled per mailbox. If your device cannot use OAuth, plan an alternative now, not when the retirement date arrives.

SMTP relay with a connector

With SMTP relay, the device connects to the MX endpoint for your domain, such as contoso-com.mail.protection.outlook.com, on port 25. An inbound connector tells Microsoft 365 to trust mail from your device, authenticated either by a TLS certificate whose subject names an accepted domain, which Microsoft recommends, or by a static public IP address that is not shared.

Advantages are that no licensed mailbox is required, the device can send as any address in an accepted domain, and limits are higher than for SMTP AUTH. Disadvantages are that a dynamic or shared IP address is not allowed, mail can be disrupted if the IP lands on a blocklist, the service applies "reasonable" limits and suspicious bulk mail can be filtered, and you cannot use it from a third-party hosted service such as Azure. Add the IP address or sending service to your SPF record so the messages are not treated as spoofed.

Direct Send

Direct Send needs no Microsoft 365 configuration. The device sends mail to your MX endpoint on port 25, and Microsoft 365 treats it like anonymous mail from the internet. It can only deliver to recipients inside your tenant, because mail to outside recipients is rejected. All scanning and protection apply, so mail might be filtered, and it is easy to misconfigure.

Microsoft says most customers do not need Direct Send and is working on an option to disable it by default. Use it only when your device supports none of the other methods, and if you do, publish SPF and configure DKIM and DMARC correctly. Treat an allowed Direct Send path as a spoofing risk to assess, and check your DMARC policy accordingly.

High Volume Email

HVE is designed for applications that send large volumes of mail, such as notifications and receipts, to internal recipients only. It uses a dedicated account, authenticated by Basic authentication or OAuth, on port 587, with no recipient or message rate limits under Microsoft's published description. It does not relay to the internet, so it solves a different problem from the other methods.

Sending to external recipients at volume

Microsoft 365 is not built to send bulk or marketing mail to the outside world. For applications that must send to external recipients, Microsoft points to Azure Communication Services Email, which offers an SMTP interface. Third-party transactional email providers are another option. In either case, add the provider to your SPF record, enable DKIM signing for your domain, and keep DMARC aligned.

Choosing

1. Can the application use OAuth or a modern mail API? Prefer that.
2. Does it only send internally and in large volumes? Consider HVE.
3. Does it send externally, at volume? Use a service built for it, such as Azure Communication Services Email.
4. Is it a legacy device that cannot do OAuth? Use SMTP relay with a certificate or a static IP address, or relay through an on-premises mail server that you control.
5. Nothing else works? Direct Send, for internal recipients only, with SPF, DKIM and DMARC in place.

Checks that prevent most problems

• Document every device and application that sends mail and what it uses.
• Remove old connectors and mailboxes that nothing uses.
• Restrict connectors to the specific IP addresses or certificates that need them.
• Check your SPF record for the 10-lookup limit after adding senders.
• Test from the real device, not from a desktop mail client.
• Watch the message trace for rejections after changes.

Microsoft references

• How to set up a multifunction device or application to send email using Microsoft 365, reviewed 5 November 2026.
• Set up SPF to identify valid email sources for your Microsoft 365 domain, reviewed 5 November 2026.

This article was first published on 10 October 2020. It was rewritten on 5 November 2026 to follow Microsoft's current guidance, including the Basic authentication retirement warning. Microsoft's live documentation takes precedence if it has changed.