Scan to email with microsoft 365 — prepare for SMTP auth retirement

scan to email with microsoft 365 is changing fast as Basic authentication for SMTP client submission is being retired. Use our scan to email with microsoft 365 guide to move from legacy username/password to modern, resilient options—so your MFPs and apps keep sending scans without interruptions.

What’s actually changing and why it matters

Microsoft is removing Basic authentication from client SMTP submission. That kills the old “SMTP user + password” method many printers still use. The good news: you’ve got secure, supported paths that work today and survive the cutover—if you configure them correctly.

Your three supported ways to keep scan-to-email working

1) SMTP client submission with OAuth 2.0 (recommended when your device supports modern auth)

• When to use: Your MFP/app supports OAuth for SMTP.

• Server/port: smtp.office365.com on 587 with STARTTLS.

• Mailbox: A licensed mailbox to send from (shared mailbox works).

• Enable SMTP AUTH: Turn it on for the sender mailbox.

• OAuth choices:

  • Delegated flow (interactive): The device shows a code or sign-in page once; you log in, and it stores a refresh token to send as that user.

  • App-only flow (non-interactive): Register an Entra ID application, grant SMTP application permission, consent it, then scope it in Exchange so the app can send as a specific mailbox. Your device or relay fetches tokens using tenant ID, client ID, and secret/certificate.

• Tip: In either flow, set the device to From the same mailbox (or grant Send As where needed) to avoid 5.7.60 permission errors.

2) SMTP relay with an inbound connector (for high volume or service relays)

• When to use: Your environment sends many messages, needs flexible “From” addresses, or you’re relaying from an on-premises service.

• Auth method: A connector authenticates your traffic by certificate or static public IP.

• Server/port: Your MX endpoint (e.g., yourdomain-com.mail.protection.outlook.com) on 25 with TLS.

• Pros: No mailbox license required; higher throughput; can send to internal and external recipients when properly configured.

• Gotchas: Requires a fixed IP/cert, correct SPF/DKIM/DMARC, and healthy reputation.

3) Direct Send (simple, internal-only)

• When to use: The device only emails your own users (no external recipients).

• Server/port: Your MX endpoint on 25.

• Auth: None; relies on accepted domains and your connector policies.

• Limit: Internal recipients only; external mail is not delivered via this method.

Quick migration plan that works

1. Inventory devices: Which MFPs/apps send mail? Which support OAuth today (via firmware/app updates)?

2. Pick a path per device:

   • Modern MFPs → SMTP with OAuth (587).

   • Legacy/high-volume relays → SMTP relay with connector (25).

   • Internal-only alerts → Direct Send (25).

3. Create or choose a sender mailbox: Shared mailbox is great (no interactive user sign-ins for alerts).

4. For OAuth devices:

   • Enable SMTP AUTH on the mailbox.

   • Delegated: perform the one-time sign-in on the panel/prompt.

   • App-only: register an app, grant SMTP application permission, admin consent, register the service principal in Exchange, and grant Send As to the target mailbox.

5. For relay/direct send:

   • Configure connector (certificate or static IP).

   • Point the device to the MX endpoint on 25; test TLS and sender domain alignment.

6. Test: Send to internal and (if applicable) external recipients. Confirm the message source in headers.

7. Document and label: Record tenant/app IDs, mailbox name, connector settings, and place a small label on each MFP with its method.

Device-side settings that avoid surprises

• Use STARTTLS only; ignore port 465.

• Keep time/date accurate (token and TLS validation rely on clock skew).

• Extend sleep timers so printers answer SMTP quickly after idle.

• Disable auto-firmware updates during migration testing, then update on a schedule.

Security and compliance tips

• Prefer app-only OAuth for appliances/services (no stored user passwords).

• Scope app permissions to a single mailbox (or a small set) rather than the whole org.

• Rotate client secrets or use cert-based credentials; monitor token usage.

• For relays, align SPF/DKIM/DMARC so external mail isn’t flagged.

Troubleshooting by symptom

• “Authentication unsuccessful” immediately: Wrong token flow, missing SMTP permission, or SMTP AUTH disabled on the mailbox—fix those first.

• Can send internally but not externally: You’re likely on Direct Send; switch to SMTP relay or SMTP with OAuth.

• 5.7.60 ‘Client doesn’t have permissions to send as this sender’: Grant Send As to the app/service or match the From address to the authenticating mailbox.

• Device “supports OAuth” but no token prompt: Update firmware; many vendors added modern-auth in 2025 releases.

• Works by USB scan-to-PC, fails by email: Network firewalls blocking 587/25 or STARTTLS inspection breaking TLS.

Cutover checklist (print this)

• Chosen method per device (OAuth / Relay / Direct Send)

• Sender mailbox created and SMTP AUTH enabled (if using client submission)

• App registration completed (ID/secret or certificate), admin consent granted

• Exchange scoping: service principal registered, Send As granted

• Connector built (if relay/direct) and MX endpoint confirmed

• Test to internal + external addresses, review message headers

• Document settings and keep a fallback mailbox ready

Conclusion

Moving scan to email with microsoft 365 off Basic authentication is straightforward when you choose the right path per device. Modern devices thrive with OAuth on 587; legacy or high-volume paths work with a connector on 25; internal-only alerts can use Direct Send. Lock it in now, test thoroughly, and your scanners will keep mailing for years to come.