Exchange Online has spent several years removing the ways that devices without modern authentication could send mail. Each step was sensible for security. Each step also broke something in an office somewhere. Here is the sequence, what still works, and how to choose.
| Method | How it worked | Status |
|---|---|---|
SMTP AUTH client submissionsmtp.office365.com:587 with a username and password | The device logged in as a mailbox and sent as that mailbox to anyone. | Basic authentication retired. The endpoint still exists but only accepts OAuth2 tokens, which printers and embedded devices cannot obtain. Error: 535 5.7.139 SmtpClientAuthentication is disabled. |
| Direct Send Device sends to your tenant's MX host, e.g. contoso-com.mail.protection.outlook.com:25, no login | Delivered to internal recipients only. No authentication meant anyone who knew your MX record could spoof internal mail. | Being locked down. Tenants can now reject unauthenticated Direct Send, and Microsoft's security guidance recommends it. Error when rejected: 550 5.7.68 Direct Send not allowed. |
| SMTP relay connector An inbound connector in Exchange Online tied to your public IP or a certificate | Devices send unauthenticated to the MX host; the connector attributes the mail to your tenant by IP, allowing external recipients. | Still supported but needs a static public IP, an Exchange admin, and it means unauthenticated mail leaving your office. Many small sites cannot meet the IP requirement. |
Modern authentication means obtaining an OAuth2 token from Microsoft Entra, which involves an app registration, a client secret or certificate, a token endpoint and TLS 1.2. Some current printer models have gained this, tied to one mailbox. Most of the installed base, and almost every UPS, server management controller, NAS, PBX and alarm panel, never will. A device bought in 2019 has years of service left and will only ever send plain SMTP.
| Option | Good | Bad | Best for |
|---|---|---|---|
| Relay on your network with an app identity (SMTP-365) | Devices unchanged except the server address; proper OAuth2 app permissions; scans can go straight to SharePoint; documents stay in your tenant; one box serves every device | A small VM or box to run | Any site with more than one device, or any site that values keeping mail inside the tenant |
| Exchange Online relay connector | Free; Microsoft-supported | Static public IP; connector admin; unauthenticated outbound; no SharePoint | Sites that already have a static IP and an Exchange administrator |
| Cloud SMTP service (SMTP2GO, Brevo, SES and similar) | Quick; works from anywhere | Monthly fee; mail leaves the tenant through a third party; SPF and DKIM changes; no SharePoint | Devices outside the office with no LAN relay available |
| Replace the devices | Newest MFPs can do OAuth2 for one mailbox | Cost; does nothing for UPS, NAS, iLO, PBX; ties the printer to one mailbox | When the printer was due for replacement anyway |
An application identity in your tenant with at most three narrow permissions: Mail.Send, Sites.Selected and Mail.ReadWrite (used only to email attachments over 3 MB, and granted only if you tick that option). No mailbox password anywhere. The mail permissions are tenant-wide as Microsoft grants them, so apply the Exchange scope the setup page gives you: it restricts them to your scanner mailbox, and until it is applied they cover every mailbox in the tenant. The appliance can then check that the scope is in force. Devices restricted to your LAN subnets. Everything else stays inside your tenant. That is how SMTP-365 is built, and it is why the setup wizard creates the application for you rather than asking for credentials.
See also: the errors and what they mean · SMTP-365 compared with a relay connector and Direct Send · compared with cloud SMTP services.
Updated 2026-10-10. Menu names and screens vary between models and firmware versions; if yours differs, look for the same fields under the device's email, SMTP or notification settings. Corrections welcome at helpdesk@smtp-365.com.