Generic printer / scanner / device (no vendor guide, or no OAuth)

First, what Microsoft says [V]

Source: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365

Four methods exist: client SMTP submission (SMTP AUTH), SMTP relay, Direct Send, High Volume Email.
Client SMTP submission: server smtp.office365.com, port 587 (recommended) or 25, TLS 1.3 or 1.2 required. Microsoft recommends OAuth. Needs a licensed mailbox with SMTP AUTH enabled. "If your device or application recommends or defaults to TCP port 465, it doesn't support the required versions of TLS for client SMTP submission."
If the device sends "from" an address other than the signed-in mailbox, the signed-in account needs Send As on that mailbox, otherwise you get 5.7.60 SMTP; Client doesn't have permissions to send as this sender.
Microsoft's note on client submission with Basic auth: "scheduled for deprecation... We strongly recommend using one of the following alternative methods instead", and lists HVE (internal recipients), Azure Communication Services Email (internal and external), or an on-premises mail server.

Decision table (same logic as the analyzer page)

Situation	Path	Why
Model/firmware supports OAuth 2.0 for Exchange Online	OAuth on smtp.office365.com:587	Microsoft's recommended method [V]
No OAuth, all recipients inside your tenant	High Volume Email	HVE is internal-only; cannot send externally [V]
No OAuth, external recipients, device can use port 25 and you have a static public IP or a certificate	SMTP relay with an inbound connector	Works for internal and external; no mailbox or licence needed [V]
No OAuth, no static IP/certificate	Third-party sending service, or your own mail server as a relay	Relay connector is not available without IP/cert [V for the requirement; vendor choice is yours]
Device only does TLS 1.0/1.1	Relay (TLS optional per Microsoft) or your own mail server; else replace/retire	Client submission and HVE require TLS [V]
Scan destinations that are not email (SMB/FTP)	Use them	Removes the dependency (Konica Minolta lists this as its own workaround [A])

Azure Communication Services Email is not a good new choice. Microsoft announced on Sep 23 2026 that standalone ACS (including Email) retires Sep 30 2028 and limits onboarding from Oct 23 2026 [V: https://learn.microsoft.com/en-us/azure/communication-services/acs-retirement-and-breaking-changes-guide]. The device page above still recommends it.

Direct Send: anonymous, to your own tenant's mailboxes only, port 25; Microsoft says most customers don't need it and it is "working on an option to disable Direct Send by default" [V]. Don't build a new dependency on it.

HVE steps [V] (https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/high-volume-mails-m365)

Exchange admin center (https://admin.exchange.microsoft.com/) > Mail flow > High Volume Email > Add an HVE account. Use an address in an accepted domain; set a password if you will use Basic auth.
Pay-as-you-go billing: each HVE account needs a billing policy linked to an Azure subscription before it can send. Microsoft's listed price: $0.000042 per recipient ($42 per million). This is a cost and an Azure subscription the customer may not have.
Device: server smtp.hve.mx.microsoft (recommended; smtp-hve.office365.com "will be deprecated in the future"), port 587, TLS on, HVE credentials or OAuth token.
Limits: 50 recipients/message, 10 MB, internal recipients only, up to 100 HVE accounts, Worldwide cloud only (not GCC/sovereign). No mailbox, so no replies: set a Reply-To.
Microsoft says HVE accounts can authenticate even when SmtpClientAuthenticationDisabled is True in TransportConfig, and that with Security Defaults on, HVE needs OAuth.

SMTP relay with connector steps [V]

Device: server = your MX endpoint (yourdomain-com.mail.protection.outlook.com), port 25, TLS 1.2+ on, any From address in an accepted domain (no mailbox needed).
Exchange admin center > Mail flow > Connectors > Add a connector: Connection from "Your organization's email server", to "Office 365"; name it; turn it on; on "Authenticating sent email" choose certificate subject match (recommended) or the device's public IP (static, not shared, not dynamic).
Add the source to your domain's SPF record (Microsoft says so; otherwise mail may land in Junk).
Send a test. Limitations: no Sent Items copy, not usable from third-party hosted services such as Azure, "reasonable limits" apply, IP blocklisting can disrupt mail.

What we could not verify

Whether your particular device handles any of this. Test on one device first.
Third-party sending services: not evaluated, no prices collected.