How to send a scan when SMTP email setup keeps failing
Scan to email failures account for the largest share of MFP related IT tickets in most offices. The device sees the network, scans the document, but the email never arrives. Five settings on the device side and three on the mail server side account for nearly every failure mode. This guide walks through each in diagnostic order.
Common error messages and what they mean
Mail server rejected the login
Username or password incorrect; account locked; account requires app password rather than user password (common with Gmail and Office 365 since enforcement of multi factor authentication).
Network or firewall blocking the connection
SMTP port closed at the firewall; network segmentation blocking the printer subnet; mail server unreachable from inside the office network.
Encryption mismatch
Device uses old TLS version; mail server requires newer; certificate expired or untrusted; STARTTLS not enabled where the server requires it.
Mail server refuses to send the message
The From address is not in a domain the server is authorised to send for; the recipient is outside the allowed list; the device IP is not in the allowed relay list.
Scan file exceeds mail server limit
Most servers reject attachments above 20 to 25 MB. High resolution scans of long documents easily exceed this. Reduce resolution or split the document.
The eight step diagnostic sequence
Identify which mail server the device is configured to use
Open device admin panel via web browser. Find Scan to Email or SMTP settings. Note the server hostname, port number, authentication method and From address.
Test the SMTP server is reachable from the device subnet
From a PC on the same subnet as the printer, telnet to the SMTP server on the configured port (typically 587 or 465). If the connection succeeds, network connectivity is fine. If it times out, firewall or routing blocks the path.
Confirm SMTP authentication credentials
If using Gmail or Office 365 with multi factor authentication, the user password no longer works for SMTP. Generate an app password (16 character code) in the mail account security settings and use that as the SMTP password.
Match TLS settings to server requirements
Office 365 requires STARTTLS on port 587. Gmail requires STARTTLS on 587 or SSL on 465. The device must match. If unsure, try STARTTLS on 587 first.
Verify the From address belongs to the SMTP account
Mail servers reject messages where the From address does not match the authenticated user. The From address should be the email address of the SMTP account. Sender impersonation triggers rejection.
Test with a known good destination address
Send to your own email address first. If it arrives, the SMTP setup works and the original issue may have been recipient specific. If it does not arrive, check spam folder before declaring failure.
Check device logs for the actual error returned
Device admin panel includes a scan log or send log showing the SMTP server's actual response. The error message there is more specific than the touchscreen display and points directly to the failure mode.
If still failing, escalate with the log to IT
The SMTP log entry contains enough detail for an IT administrator to diagnose mail server side issues. Without the log, IT has to guess. Always include the log when escalating scan to email problems.
The Office 365 / Gmail authentication shift
Cloud mail providers have progressively tightened authentication requirements over the past three years. Both Microsoft and Google now require app passwords or OAuth for SMTP access from devices. The standard user password no longer works for office MFPs.
Generating an app password takes 2 minutes in the mail account security settings. Once generated, it replaces the user password in the device SMTP configuration. The user password keeps working for web mail and email clients; the app password applies only to the device.
Settings reference for common Spanish business mail providers
| Provider | SMTP server | Port | Encryption | Notes |
|---|---|---|---|---|
| Office 365 | smtp.office365.com | 587 | STARTTLS | App password required with MFA |
| Gmail / Google Workspace | smtp.gmail.com | 587 or 465 | STARTTLS or SSL | App password required with 2FA |
| Movistar | smtp.movistar.es | 587 | STARTTLS | User password works |
| Orange | smtp.orange.es | 587 | STARTTLS | User password works |
| Generic ISP | Provider specific | 587 or 25 | STARTTLS | Check ISP documentation |
When to give up on direct device SMTP
Some environments make direct device SMTP impractical. Multi tenant offices where the mail server is managed by another party. Heavily restricted corporate networks where firewall rules block printer subnets. Cloud first organisations where everything routes through specific authentication systems. In these cases, two alternatives work.
Scan to folder with email forwarding
Scan to a shared folder. A Power Automate or similar workflow detects new files and emails them as attachments. Adds a few minutes of delay but bypasses the SMTP issue entirely.
Scan to user's PC then send manually
Scan to the user's own PC (each user has a folder configured). The user opens the file and emails it via their normal mail client. Less automated but works in restrictive environments.
Volume thresholds
Scan to email handles routine office volumes without throttling. Mail servers may rate limit if a single device sends hundreds of emails per hour. For sustained high volume scan to email work (legal discovery, archive digitisation), schedule the runs to spread across hours rather than burst sending.