How to troubleshoot scan-to-email when SMTP keeps failing
Scan-to-email failures usually fall into one of seven recognisable SMTP error categories. This guide identifies each category, the error code that signals it, and the fix that resolves the underlying cause.
Scan-to-email failures account for the largest single category of MFP support tickets in most offices. The failure mode is consistent: the device scans correctly, the file size looks reasonable, the recipient address is correctly typed, and the send fails for reasons that are usually obscure from the device's perspective. The vast majority of these failures map to a small set of underlying SMTP configuration issues that each carry a recognisable SMTP error code. Reading the code and applying the corresponding fix resolves the failure in 90 percent of cases within 5 to 15 minutes.
The other 10 percent involve more substantial issues — Microsoft 365 modern-authentication migrations breaking SMTP basic auth, mail-server SPF policies rejecting the MFP's IP, attachment size limits silently dropping large scans. These cases need IT-team coordination but follow the same diagnostic pattern: locate the error code, identify the underlying cause, apply the correct fix.
Seven SMTP error codes and their fixes
Service not available · server too busy or unreachable
The mail server is unavailable or refused the connection. Common cause: mail-server outage, DNS resolution failure, or wrong SMTP server hostname in MFP configuration.
Authentication failed · credentials rejected
SMTP server rejected the username or password. Common cause: wrong credentials, expired password, or basic-auth disabled (common after M365 modern-authentication migration). Microsoft 365 requires app-specific passwords for SMTP since basic auth was deprecated.
Recipient address rejected · mailbox unavailable
The destination address was rejected. Common cause: typo in the recipient address, deleted user mailbox, or external recipient blocked by sender policy.
Message size exceeds limit · attachment too large
Scanned attachment exceeds the mail server's size limit (typically 25 MB on M365 / Gmail, 10 MB on some on-premises servers). Common cause: high-resolution scan of a multi-page document.
Sender address rejected · not authorised to send
The mail server refused the From: address. Common cause: the MFP's configured From address does not exist as a real mailbox, SPF policy rejects the device's IP, or shared mailbox lacks Send-As permission for the authenticated account.
Transaction failed · policy rejection
Catch-all for policy-based rejections. Common cause: spam-filter triggered by the scan (uncommon for typical office content), connection from blocked IP, or recipient's mail server applied a content policy.
TLS handshake failure · certificate or protocol mismatch
MFP could not establish a secure TLS connection to the mail server. Common cause: MFP firmware too old to support TLS 1.2 (required by modern mail servers), expired certificate on the mail server, or wrong port (TLS uses 587 with STARTTLS or 465 with implicit TLS).
The five-step diagnostic ladder
- Read the error code in the device's send log. Every MFP records SMTP send errors in its admin log. Locate the most recent failure and note the SMTP code returned by the mail server.
- Verify SMTP server hostname and port. Common settings:
smtp.office365.com:587for M365,smtp.gmail.com:587for Google Workspace,[mailserver]:25for on-premises Exchange. - Test SMTP authentication from a desktop tool. Use Telnet, swaks, or PowerShell's Send-MailMessage to verify the same credentials work outside the MFP. If desktop fails too, the credentials or server are the issue, not the MFP.
- Check the From address has Send-As permission. A common late-stage issue: the configured From address is a shared mailbox the authenticated account cannot send on behalf of. Add Send-As permission in the mail-admin console.
- Engage IT for SPF/DKIM/firewall verification. If steps 1–4 do not resolve, the issue is typically at the mail-server policy level or office firewall. Escalate to the office's mail administrator with the specific error code and the steps already tried.
The M365 modern-authentication migration consideration
Microsoft 365 deprecated basic authentication for SMTP in late 2022, breaking scan-to-email on many MFPs that had been configured with username-and-password SMTP authentication. The fix path depends on the MFP's firmware vintage: newer firmware supports OAuth-based SMTP and modern authentication; older firmware requires creating an app-specific password and using SMTP AUTH submission, which Microsoft has indicated may also be retired in future. Long term, offices on M365 should plan to migrate scan-to-email to the M365 Universal Print connector or to scan-to-OneDrive/SharePoint instead, eliminating the SMTP dependency altogether.
For offices on Google Workspace, app-specific passwords remain the simplest authentication path and are not deprecated. Generate the password in the Google Workspace admin console, configure it in the MFP, and the SMTP relay continues to work reliably. Either way, the diagnostic ladder above identifies which fix path applies based on the error code the MFP reports.