Introduction

A mail migration can move user mailboxes successfully while office scanners, copiers, and multifunction devices keep sending through the old SMTP server. Scan-to-email may work intermittently, fail with authentication or certificate errors, or appear to send while messages never leave the retired relay because the device still stores legacy server details locally.

Treat this as a device-profile problem instead of a general mail outage. Start by checking the exact SMTP host, port, username, and sender address configured on the scanner, because these devices often keep old relay settings long after user mail and DNS have already moved.

Symptoms

  • Scan-to-email works on some devices, but older scanners still fail after the migration
  • The device still shows the old SMTP hostname, old IP, or old certificate name
  • Users can send mail from computers, but scans sent by the printer or copier do not arrive
  • Authentication errors start right after moving mail to a new provider or server
  • Some scans leave the device queue only when the old relay is still reachable
  • The issue started after mail cutover, provider migration, or SMTP relay replacement

Common Causes

  • The scanner still stores the old SMTP server hostname or IP address
  • The device uses saved credentials that only worked on the previous relay
  • The new mail platform requires different ports, TLS settings, or authentication methods
  • The configured sender address is no longer allowed on the new relay
  • A local address book or scan profile still references the retired mail path
  • Migration validation focused on user mailboxes and missed device-based mail sending

Step-by-Step Fix

  1. Open the scanner or multifunction device mail settings and record the exact SMTP host, port, encryption mode, username, and sender address, because you need the live device configuration rather than what the migration plan expected it to use.
  2. Compare those settings with the intended post-migration SMTP submission details, because many devices keep talking to the old relay until every stored mail parameter is updated manually.
  3. Check whether the device uses a dedicated scan-to-email profile, address book entry, or per-user preset instead of one global SMTP setting, because one forgotten profile can keep only certain workflows pinned to the legacy mail server.
  4. Verify that the new mail platform accepts the sender identity the device is using, because scanners often send as a no-reply or copier address that may no longer be authorized after the migration.
  5. Review the device TLS and authentication options against the new service requirements, because older scanners commonly fail when the migrated SMTP service expects modern encryption, app passwords, or authenticated submission on a different port.
  6. Update the real active SMTP settings on the device and save them only after confirming the new host, credentials, and sender policy, because repeated retries against the wrong relay can hide the actual cutover problem.
  7. Send a controlled test scan and confirm which SMTP server handled it by checking message headers, relay logs, or provider traces, because a successful delivery alone does not prove the old server is no longer in use.
  8. Repeat the check for every similar scanner, copier, or site profile if the organization has multiple devices, because mail migrations often fix one device while another branch office or older model still uses the retired relay.
  9. Document the final SMTP profile for device-based mail sending and include it in future mail cutover plans, because scanners are one of the most common systems left behind after email migration.