How do you set up scan to email and app SMTP with Microsoft 365?

Printers, scanners and business apps create email but aren't mail servers, so they need a route out. Microsoft 365 gives you three main routes, each with different rules about sign-in, recipients and limits. Picking the wrong one is why scan to email works for a week, then fails with a bounce nobody understands.

This guide compares the options, walks through each setup and explains what Microsoft's Basic auth retirement means for your devices.

What are the ways to send email from a device through Microsoft 365?

Microsoft documents three methods for devices and applications, plus a fourth for high volume internal mail (Microsoft Learn):

Your MX endpoint is the value your domain's MX record points to, in the form contoso-com.mail.protection.outlook.com. You'll find it in the Microsoft 365 admin center under Settings > Domains, on the domain's DNS records tab. An MX Lookup shows the same value, unless your MX points to a filtering gateway.

The fourth method, High Volume Email (HVE), sends large volumes to internal recipients only, uses pay-as-you-go billing, and is covered briefly below.

Which option should you choose?

Use this order of preference:

1. SMTP AUTH client submission if the device supports TLS 1.2 and, ideally, OAuth. It's the simplest and reaches anyone.
2. SMTP relay through a connector if the device can't sign in, or you don't want a licensed mailbox for it, and you have a static public IP that only your organization uses.
3. Direct Send only if the device must reach internal staff and can't do either of the above. Microsoft says most customers don't need it, and recommends it "only for advanced customers willing to take on the responsibilities of email server admins."

One exception: Microsoft says you can't use SMTP relay to send from a third-party hosted service, such as an app running in Azure. Cloud-hosted apps should use client submission instead.

How do you set up SMTP AUTH client submission?

Client submission signs in as a real mailbox, so the mailbox's address becomes the sender.

1. Pick or create a licensed mailbox for the device, for example scanner@yourdomain. Microsoft requires "a licensed Microsoft 365 or Office 365 mailbox that the device uses to send email from."
2. Enable SMTP AUTH on that mailbox. Microsoft disables SMTP AUTH for organizations created after January 2020, and recommends keeping it off for the organization and enabling it only for the accounts that need it (Microsoft Learn). In the Microsoft 365 admin center, go to Users > Active users, select the user, select Mail > Manage email apps, check Authenticated SMTP and select Save changes. Or use Exchange Online PowerShell:

Set-CASMailbox -Identity scanner@yourdomain.com `
  -SmtpClientAuthenticationDisabled $false

3. Leave the organization setting off. The mailbox setting overrides the organization one, so you can keep SMTP AUTH disabled tenant-wide. Check both:

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Get-CASMailbox -Identity scanner@yourdomain.com |
  Format-List SmtpClientAuthenticationDisabled

True at the organization level is what you want. On the mailbox, False means enabled and blank means it follows the organization setting.

4. Configure the device: server smtp.office365.com (never an IP address), port 587, TLS or STARTTLS on, and the mailbox's username and password, or OAuth if the device supports it.
5. Send a test to an internal and an external address.

What goes wrong with client submission?

• Security defaults. If security defaults are on in Microsoft Entra ID, Microsoft says "SMTP AUTH is already disabled in Exchange Online." An authentication policy that blocks Basic auth for SMTP has the same effect.
• No TLS. A device that can't negotiate TLS 1.2 or later can't use this method. Microsoft adds that a device that recommends or defaults to port 465 "doesn't support the required versions of TLS." Older firmware is the usual cause; see our guide to STARTTLS and encryption in transit.
• Sending as another address. If the device sends from an address other than the sign-in mailbox, that mailbox needs Send As permission, or you'll get 5.7.60 SMTP; Client doesn't have permissions to send as this sender.

The common bounces map to specific causes. 550 5.7.57 means the device didn't authenticate, 535 5.7.8 means the credentials were rejected, and 530 5.7.0 means the device tried to send before signing in or starting TLS.

What happens when Basic auth for SMTP AUTH is retired?

Microsoft announced in April 2024 that it would remove Basic auth (username and password) from client submission. It has moved the date several times. The current plan, from the Exchange Team's update of January 27, 2026 (Microsoft Tech Community), is:

Once Basic auth is permanently off, Microsoft says clients will get 550 5.7.30 Basic authentication is not supported for Client Submission (Microsoft Tech Community). The change applies to client submission only. Relay connectors and Direct Send don't sign in, so they aren't affected.

To find out what's at risk, open the Exchange admin center and go to Reports > Mail flow > SMTP AUTH clients. It lists each sender, whether it used Basic Auth or Modern Auth, and its TLS versions, for up to 90 days (Microsoft Learn). For each Basic auth sender, either switch it to OAuth, move it to a relay connector, or replace the device. Microsoft's own alternatives are High Volume Email for internal mail, Azure Communication Services Email for internal and external mail, or an on-premises mail server you relay through.

How do you set up an SMTP relay connector?

A relay connector lets the device send as any address in your accepted domains, with no mailbox and higher limits than client submission. Microsoft authenticates the connection by certificate (recommended) or by public IP.

1. Confirm the source. Get the public IP the device's traffic leaves from. Microsoft says dynamic IP addresses "aren't supported or allowed," and the IP must not be shared with another organization. For a certificate, its Subject or SAN must contain one of your accepted domains.
2. Create the connector. In the Exchange admin center, go to Mail flow > Connectors (https://admin.cloud.microsoft/exchange#/connectors) and select Add a connector.
3. Under Connection from, select Your organization's email server. Connection to is set to Office 365.
4. Name it, keep Turn it on selected and leave Retain internal Exchange email headers unselected.
5. On Authenticating sent email, choose the certificate option and enter your domain, or choose the IP option and enter the device's public IP.
6. Review and select Create connector.
7. Configure the device: server is your MX endpoint, port 25, TLS on, sender address in your accepted domain.
8. Update SPF. Microsoft says to add the IP to your domain's SPF record so messages aren't marked as spam. Our Microsoft 365 SPF page shows the include, and the SPF Checker confirms you stay under 10 lookups.

If you already have a hybrid connector from on-premises Exchange, you probably don't need a separate one.

When is Direct Send acceptable, and how do you lock it down?

Direct Send needs no settings in Microsoft 365. The device connects to your MX endpoint on port 25 and sends as an address in your domain. That's also its weakness: Microsoft treats the messages "just like anonymous email from the internet," they can't reach external recipients, and the same path can be used to spoof your domain to your own staff.

If you use it, add the sending IP to SPF and make sure DKIM and DMARC are set up for the domain, as Microsoft advises. If nothing of yours uses Direct Send, block it:

Set-OrganizationConfig -RejectDirectSend $true

Microsoft says the change propagates within 30 minutes. It then rejects anonymous messages whose envelope sender uses one of your accepted domains, with 550 5.7.68 TenantInboundAttribution. Any legitimate sender that hits it needs a partner connector matching its certificate or IP (Microsoft Tech Community). Our guide to blocking Direct Send and filter bypass covers how to find existing direct senders first.

Does High Volume Email replace scan to email?

For internal-only devices, it can. HVE accounts aren't mailboxes and need no license. They sign in to smtp.hve.mx.microsoft on port 587 with TLS, using a password or OAuth, and work even when SMTP AUTH is disabled tenant-wide. Microsoft lists limits of 50 recipients per message, 10 MB per message and up to 100 HVE accounts per tenant, and bills per delivered recipient through pay-as-you-go billing (Microsoft Learn). HVE accounts can't send to external recipients, and Microsoft notes that with security defaults on, HVE can authenticate only with OAuth.

Does a filtering gateway change any of this?

Client submission doesn't change: devices still sign in to smtp.office365.com. Direct Send and relay connectors do, because once your MX points to a filtering gateway, the MX lookup no longer returns your Microsoft 365 endpoint. Find it in the admin center instead. And if you restrict your tenant to accept mail only from the gateway, as you should, anonymous Direct Send from a device stops working, so move those devices to client submission or a relay connector first. Check a test message in the Email Header Analyzer to see which route it actually took.

Next steps

1. Open the SMTP AUTH clients report and list every device that still signs in with Basic auth.
2. Move each one to OAuth, a relay connector or HVE before the end of December 2026.
3. Keep SMTP AUTH disabled for the organization and enabled only on the mailboxes that need it.
4. Add any relay or Direct Send IPs to SPF, then run Set-OrganizationConfig -RejectDirectSend $true if nothing still uses Direct Send.
5. Look up any bounce in the SMTP Error Code Lookup, and review mail flow rules for security while you're in the Exchange admin center.

Browse more setup guides.