Guide
Microsoft documents four ways to send email from an application or device through Microsoft 365. Each has a different hostname, port and authentication model, and each has a limit that decides whether it will work for you. All four are compared below, along with what to do when none of them fits.
Last reviewed July 2026
The phrase covers two different jobs, and the setup differs completely depending on which one you have.
Sending from an application or device. An application, printer, scanner or line-of-business system needs to send email, all your mailboxes are in Microsoft 365, and you want that system to hand its mail to Microsoft. Most of this guide covers this case.
Routing Microsoft 365 mail onward. You already send through Microsoft 365 and want outbound mail to pass through a third-party service for deliverability, logging or compliance. That is an outbound connector in Exchange, covered at the end.
For the first job Microsoft documents four methods. They are not tiers of one service: each has its own hostname, port, authentication model and limits on who you may send to.
Microsoft calls only one of the four "SMTP relay", and it is not the one most people mean. What most administrators set up when they say "Office 365 SMTP relay" is client SMTP submission, also called authenticated SMTP submission or SMTP AUTH: hostname smtp.office365.com, port 587, mailbox username and password. Microsoft's own "SMTP relay" is a connector-based method authenticated by static IP address or TLS certificate, and it points at your tenant's MX endpoint rather than at smtp.office365.com.
The four methods
Values are from Microsoft's documentation for setting up a multifunction device or application. Two of the four methods cannot send to external recipients at all, which rules them out for customer-facing mail.
| Client SMTP submission | SMTP relay (connector) | Direct Send | High Volume Email | |
|---|---|---|---|---|
| Server / smart host | smtp.office365.com | Your tenant MX endpoint | Your tenant MX endpoint | HVE endpoint |
| TCP port | 587 (recommended) or 25 | 25 | 25 | 587 |
| TLS | Required (TLS 1.2 or 1.3) | Optional | Optional | Required |
| Authentication | Mailbox username and password, or OAuth | Static public IP or TLS certificate | None | HVE account or OAuth |
| Can send to external recipients | Yes | Yes | No - internal only | No - internal only |
| Needs a licensed mailbox | Yes | No | No | HVE account required |
| Works from third-party hosting (Azure, AWS) | Yes | No | Yes | Yes |
| Documented throughput limit | 10,000 recipients per day; 30 messages per minute | "Reasonable limits" - routed via the high-risk delivery pool | Standard anonymous-inbound throttling | No recipient or message rate limit |
| Saves to Sent Items | Yes | No | No | No |
Source: Microsoft Learn, "How to set up a multifunction device or application to send email using Microsoft 365 or Office 365", article dated 4 March 2025. Microsoft revises these limits, so check the current article before relying on one.
Microsoft's documentation carries an explicit note that client SMTP submission using Basic authentication in Exchange Online is scheduled for deprecation, and recommends alternatives instead. This matters because Basic auth - a username and password in the SMTP conversation - is exactly what a printer, a scanner or a decade-old line-of-business application is capable of. The recommended replacement is OAuth, which most such devices cannot do.
Related, and easy to miss: SMTP AUTH is disabled by default for Microsoft 365 organizations created after January 2020. It can be enabled per mailbox, but if a new tenant reports authentication failures on a configuration that works elsewhere, this is usually why.
Microsoft states directly that if a device or application recommends or defaults to TCP port 465, it does not support the TLS versions required for client SMTP submission. Plenty of appliances and older libraries default to 465 with implicit TLS. Use port 587 with STARTTLS.
Direct Send and High Volume Email deliver only to recipients in your own Microsoft 365 organization. Mail addressed outside it is rejected. High Volume Email is attractive on paper because it carries no recipient or message rate limit, but that ceiling exists precisely because the mail never leaves the tenant. If your application sends password resets, receipts or order confirmations to customers, neither method is available to you, regardless of volume.
That leaves client SMTP submission, capped at 10,000 recipients per day and 30 messages per minute, and connector-based SMTP relay, which needs a static unshared public IP address or a TLS certificate and which Microsoft documents as not usable from third-party hosted services such as Azure.
Setup
This is the method most people mean by "Office 365 SMTP relay". Use it when the sending system can authenticate with a mailbox and your volume sits inside 10,000 recipients per day and 30 messages per minute.
In the Microsoft 365 admin center, check the designated mailbox has authenticated SMTP enabled. It is off by default for tenants created after January 2020, and this is the most common cause of an authentication failure on an otherwise correct configuration.
Client SMTP submission needs a licensed mailbox, and the mailbox address becomes the message sender. Create one for the application rather than reusing a person's mailbox - it keeps the Sent Items trail separate and means a password change on someone's account does not stop your application sending.
Use the DNS name, not an IP address. Enable TLS or STARTTLS - TLS 1.2 or 1.3 is required. If the application offers port 465, do not use it: Microsoft documents that a device defaulting to 465 does not support the required TLS versions.
If the application needs a From address other than the authenticating mailbox, that mailbox needs Send As permission on the address. Without it the message is returned as "5.7.60 SMTP; Client does not have permissions to send as this sender."
A test send proves the credentials work. It does not prove your volume fits. If the application can emit a burst - a nightly batch, a queue draining after an outage - test that shape too, because 30 messages per minute is the throttle you will hit first, well before the daily recipient ceiling.
Microsoft 365 is a mailbox service. Sending application email through it works, and for a scanner that emails ten documents a day it is the obvious answer - do not add a vendor for that.
It stops being the right answer at a specific set of thresholds, each of them documented by Microsoft:
There is also shared reputation to consider. When application mail goes through the same tenant as your staff's correspondence, an application-side accident - a loop, a bad recipient list, a misconfigured retry - lands on the reputation your employees depend on to email customers at all.
The alternative
If one of the thresholds above applies, the change on the application side is the same shape as the Microsoft configuration - a hostname, a port and a credential. Nothing in the sending code changes.
Omnivery vets every sending domain before it can send, typically one to three working days. Vetting is what keeps the shared sending pool clean, and it means a relay cannot be stood up mid-incident. Set it up before you need it.
Credentials are created under the SMTP users tab in the Credentials menu. The username is in email-address format; it does not need to be a functional mailbox, and a domain you control is recommended.
Host smtp.omnivery.net, port 587, STARTTLS, and the new credential. No SDK, no library change, no code deployment. The MAIL FROM and From addresses must belong to your configured sending domain.
Standard authentication setup, and the same work any relay requires. These are separate DNS records from the ones Microsoft 365 uses for your mailboxes, which is what decouples application sending reputation from staff email.
Full API parity is available over SMTP through X-OV-* headers: X-OV-Tag for categorizing traffic, X-OV-Require-TLS to refuse delivery to a receiver that will not encrypt, X-OV-Callback-URL for webhooks, plus templating and tracking controls. All optional - a plain RFC5322 message with no custom headers sends fine.
Human mailboxes stay in Microsoft 365. Only the application traffic moves. Most senders run both permanently rather than migrating away from one.
At a glance
Questions
For client SMTP submission, which is what most administrators mean: server smtp.office365.com, TCP port 587 (port 25 also works), TLS or STARTTLS enabled with TLS 1.2 or 1.3, and the username and password of a licensed Microsoft 365 mailbox. Do not use port 465 - Microsoft documents that a device defaulting to 465 does not support the required TLS versions. Microsoft's own "SMTP relay" method is different: it points at your tenant MX endpoint (for example contoso-com.mail.protection.outlook.com) on port 25 and authenticates by static IP address or TLS certificate rather than by password.
Client SMTP submission is limited to 10,000 recipients per day and 30 messages per minute. Connector-based SMTP relay has no published number - Microsoft describes "reasonable limits" and routes this traffic through its high-risk delivery pool. High Volume Email carries no recipient or message rate limit but can only deliver to recipients inside your own organization. In practice the 30-messages-per-minute rate limit is what most senders hit first, before the daily ceiling.
The most common cause is that SMTP AUTH is disabled on the mailbox. Microsoft disables authenticated client SMTP submission by default for organizations created after January 2020, and it has to be enabled per mailbox. Two other frequent causes: the device is using port 465, which is not supported; or the From address differs from the authenticating mailbox without Send As permission, which returns "5.7.60 SMTP; Client does not have permissions to send as this sender."
Microsoft's documentation states that client SMTP submission using Basic authentication in Exchange Online is scheduled for deprecation and recommends alternatives. Basic authentication means the username and password exchange that printers, scanners and older line-of-business applications use. The recommended replacement is OAuth, which many such devices cannot perform, so affected senders need either an intermediate on-premises mail server or a dedicated relay. Check Microsoft's current timeline before planning around a specific date.
Client SMTP submission works from any location including third-party cloud hosting. Connector-based SMTP relay does not - Microsoft documents that it cannot be used to send email from a third-party hosted service, and connector authentication requires a static unshared public IP address in any case. So an application on cloud hosting is restricted to the throttled client-submission path, at 10,000 recipients per day and 30 messages per minute.
It can, through client SMTP submission or a connector, within those limits. Whether it should is a different question. A mailbox service gives you message trace but not per-recipient bounce classification, engagement data with automated scanner activity separated out, or webhooks your application can act on. It also has no concept of transactional mail bypassing marketing suppression. And application email shares reputation with your staff's correspondence, so an application-side accident affects whether your employees can email anyone at all.
For application email, point the application at smtp.omnivery.net on port 587 with STARTTLS and an Omnivery SMTP credential - three configuration values, no code change. For routing mail that originates in Exchange Online onward through Omnivery, create an outbound connector in the Exchange admin center with Omnivery as the smart host. Either way the sending domain must be vetted first, which typically takes one to three working days. Human mailboxes normally stay in Microsoft 365; only the application traffic moves.
If Microsoft 365 has become the wrong place for your application email, moving it is a configuration change rather than a migration. The SMTP relay page covers feature parity, and the documentation covers every header.