If your printer still scans but “scan to email” suddenly fails, the scanner may be fine—the outdated email sign-in method is often the real problem. That distinction matters because repeatedly changing passwords, opening firewall ports, or weakening a Microsoft 365 or Google Workspace policy can turn a frustrating outage into a security incident.
This guide gives home users and small businesses a safe order of operations: prove which part is broken, collect the right evidence, choose a supported mail-delivery method, and test without exposing an administrator password. It applies to many multifunction printers and scanners from Canon, Epson, HP, Brother, Ricoh, Xerox, and other vendors, although the exact menu names differ.
The problem in plain English
A multifunction printer does not deliver mail by itself. It creates a PDF or image, then hands that file to an email service. If the printer uses an old username-and-password method, obsolete encryption, the wrong server or port, a changed public IP address, or an account that was disabled, the scan can succeed while email delivery fails.
The costly part: invoices, signed forms, medical paperwork, closing documents, work orders, and customer records may sit unsent while staff assume they were delivered. Repeated retries can also lock an account or trigger security alerts.
Who is affected—and who is not?
Likely affected
- The scanner creates a file, but email shows “authentication,” “SMTP,” “TLS,” “server,” or “send failed.”
- The problem began after a password, email-security, internet-provider, firewall, or Microsoft 365/Google Workspace change.
- One-touch scan buttons still work until the final sending step.
- Every recipient fails, or internal recipients work while outside addresses fail.
Probably a different problem
- The scanner cannot detect paper, produces lines, jams, or cannot make a local copy.
- Only one destination address is wrong or obsolete; clean up the printer/scanner address book.
- The email arrives but its attachment is too large or quarantined.
- Printing fails too, which points toward network, driver, queue, or device trouble rather than mail delivery alone.
Fix scan-to-email in the safest order
1. Preserve evidence before changing settings
- Photograph the exact error and note the date and time.
- Record whether all recipients fail, only outside recipients fail, or only one address fails.
- Write down the printer model, firmware version, sender address, SMTP host, port, and encryption choice. Do not photograph, export, or share a saved password.
- If this is a business system, check the Microsoft 365 message trace, Google Email Log Search, firewall log, or printer job log before repeated tests overwrite useful evidence.
2. Prove the scanner itself works
Make a local copy, scan to USB, or scan to a computer/network folder. If that also fails, stop troubleshooting email and address the scanner, document feeder, storage, network path, or driver. If a local scan succeeds, you have narrowed the fault to the send path.
3. Check the basics that break encrypted mail
- Date, time, and time zone: a badly wrong clock can make a valid TLS certificate look expired or not yet valid.
- DNS and gateway: confirm the printer received the correct DNS servers, default gateway, and VLAN access.
- Firmware: install only the exact model’s current vendor firmware after saving a configuration backup. Older firmware may lack current TLS or OAuth support.
- Server and port: compare the device settings with the current official provider instructions; do not copy a random forum’s server name.
- Attachment size: retry with a one-page black-and-white PDF. A large color scan can fail for a different reason than authentication.
4. Identify who actually hosts the sender’s mailbox
The address printed on the device does not prove which platform sends the message. Check the domain’s mail service and the organization’s admin portal. The right solution is different for Microsoft 365, Google Workspace, consumer Gmail/Outlook accounts, an internet provider, or an on-premises mail server.
Microsoft 365: choose the method by what the device can do
Microsoft documents several supported patterns for multifunction devices. Do not treat them as interchangeable:
Phone readers: swipe the table left to see the full “Limits and cautions” column.
| Method | Good points | Limits and cautions |
|---|---|---|
| OAuth / modern authentication | Best fit when the printer vendor supports Microsoft 365 sign-in without storing a normal password. | Requires compatible firmware and vendor implementation. Follow the device maker’s current instructions. |
| Microsoft 365 SMTP relay | Can send to internal and external recipients; authenticates through an inbound connector. | Normally requires one or more static public IP addresses, connector setup, port 25 reachability, and correct SPF planning. This is an administrator job. |
| Direct Send | No mailbox password; useful for messages sent only to recipients in your Microsoft 365 organization. | Does not relay to outside internet recipients. It is not the answer if customers or personal addresses must receive scans. |
| Client SMTP submission / SMTP AUTH | Historically simple and can save to Sent Items. | Legacy username/password implementations are the fragile path. Microsoft says Basic Authentication for SMTP AUTH is scheduled for deprecation and strongly recommends alternatives. Do not re-enable it organization-wide just to rescue one old scanner. |
A common diagnostic clue: if scans reach coworkers but never reach customers, the device may be using Direct Send, which Microsoft says is limited to recipients in your Microsoft 365 domains. If nothing sends after an ISP change, an SMTP relay connector may still trust the old public IP.
Google Workspace: relay is the recommended business option
Google’s administrator guidance lists three options and recommends the Google Workspace SMTP relay service. Google describes relay as the most secure option and supports IP-based authentication, with smtp-relay.gmail.com on ports 25, 465, or 587 depending on the configuration.
Google also warns that, starting May 1, 2025, Workspace accounts no longer support devices that sign in with the normal Google username and password as “less secure apps”; OAuth is required for that access pattern. Some devices can use an app password when 2-Step Verification is enabled, but app passwords are not available under every account or administrator policy and should not be mistaken for a permanent modernization plan. Our older Gmail app-password walkthrough explains that narrow option; today, Workspace administrators should evaluate relay or OAuth first.
What not to do
- Do not store a Global Administrator or Super Admin password in a printer. Use a dedicated, least-privileged identity or supported relay design.
- Do not disable MFA or broad security defaults. Repair the sending method instead of weakening every user.
- Do not expose the printer’s web-management page to the internet. Administer it only from a trusted local network or approved management path.
- Do not open port 25 inbound to the printer. A provider’s outbound SMTP requirement is not permission to publish the device.
- Do not guess at certificates. Bypassing certificate validation can hide interception or configuration errors.
- Do not keep retrying with confidential documents. Use a one-page non-sensitive test file until delivery and recipient behavior are verified.
A practical decision tree
- Local scan fails? Fix the scanner or file destination first.
- Local scan works, all email fails? Check clock, DNS, gateway, TLS, firmware, SMTP host, port, and authentication.
- Internal mail works, external mail fails? Review Direct Send/restricted-relay limitations and connector scope.
- Failure began after an ISP change? Verify the public IP used by an IP-authenticated relay and update it transactionally.
- Failure began after password/MFA/security changes? Do not roll security back. Move to OAuth or an administrator-managed relay.
- Device cannot support a safe method? Scan to a protected folder or workstation and send from a supported mail client while planning replacement. That extra step is safer than reviving weak authentication.
Example: the copier that “worked yesterday”
A small office changes internet providers on Friday. Printing and local scanning work Monday, but scan-to-email returns a generic server error. Staff reset the mailbox password twice with no improvement. The real clue is that the Microsoft 365 relay connector trusted the old static public IP. The safe fix is to verify the new public IP, update the connector and SPF design as appropriate, test with a harmless one-page PDF to an internal recipient, then test an authorized external recipient. The wrong fix is placing an administrator password in the copier or broadly re-enabling legacy SMTP authentication.
After it works: verify delivery, not just the green check
- Send a one-page test to one internal and—if the design permits—one authorized external recipient.
- Open the attachment and confirm every page is readable and correctly oriented.
- Check the sender, subject, timestamp, and message trace/log entry.
- Document the supported method, device IP, firmware, owner, and next review date without recording secrets.
- Review saved destinations and remove stale contacts using our printer and scanner address-book checklist.
- If your domain sends business mail, verify SPF, DKIM, and DMARC after a relay change.
Frequently asked questions
Why does printing work when scan-to-email does not?
Printing usually travels from your computer to the local device. Scan-to-email travels from the device through DNS, a gateway, TLS, and an outside mail platform. They share hardware but use different paths.
Should I just create an app password?
Only when the provider, account policy, and printer vendor explicitly support it. App passwords are not available for every account and still leave a reusable secret stored on the device. For a business, OAuth or a properly scoped relay is usually a better long-term design.
Can I use my personal Gmail or Microsoft account?
Possibly, if the device supports the provider’s current authentication method, but a personal account is a poor owner for a shared business workflow. Staff turnover, MFA prompts, password changes, storage limits, and lack of centralized logs make it brittle.
Why do internal recipients work but customers do not?
The configured method may intentionally prohibit external relay. Microsoft Direct Send and Google’s restricted SMTP option are examples of designs with recipient limits. Check the official method, not just the server name.
Is an old scanner unsafe if it still sends mail?
Not automatically, but unsupported firmware, weak TLS, stored shared credentials, and an exposed admin page are warning signs. If it cannot use a currently supported method, isolate it appropriately and use scan-to-folder or plan a replacement.
Your next step
Run one harmless local scan and record the exact email error before changing anything. If the workflow handles customer or regulated documents—or if relay, OAuth, connectors, DNS, or SPF are unfamiliar—stop before weakening security. The IT Guys can help homes and small businesses in Port Saint Lucie, Jensen Beach, Fort Pierce, and Vero Beach identify the mail path, preserve the current configuration, and move the device to a supported setup.