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. This creates a situation where user email works correctly but device-based email sending continues to fail silently.

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. This issue is particularly common because scanners and multifunction devices are configured once and rarely updated, making them easy to overlook during email migrations.

The problem frequently appears after organizations migrate from on-premises email servers to cloud providers like Microsoft 365 or Google Workspace, change email hosting providers, or consolidate SMTP relay services. Scanners typically use dedicated SMTP configurations separate from user mail clients, and these device-level settings are not included in standard mailbox migration processes.

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 address, or old certificate name in settings
  • Users can send mail from computers and phones, 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
  • Scan-to-email shows "sent" on device but recipients never receive the message
  • Device logs show SMTP connection failures or authentication rejections
  • Only certain scan destinations or address book entries fail
  • Certificate validation errors appear when the device tries to connect

Common Causes

  • The scanner still stores the old SMTP server hostname or IP address in its network settings
  • The device uses saved credentials (username/password) that only worked on the previous relay
  • The new mail platform requires different ports (587 vs 25), TLS settings, or authentication methods
  • The configured sender address (from 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
  • The device does not support modern authentication (OAuth, app passwords) required by the new provider
  • IP-based relay authentication changed and the device IP is no longer whitelisted
  • TLS certificate requirements differ between old and new providers

Step-by-Step Fix

  1. 1.Open the scanner or multifunction device mail settings (usually via web interface at the device IP) 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. 2.Compare those settings with the intended post-migration SMTP submission details from your new provider, because many devices keep talking to the old relay until every stored mail parameter is updated manually. Note any differences in hostname, port, or authentication.
  3. 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. 4.Verify that the new mail platform accepts the sender identity the device is using, because scanners often send as a no-reply, scanner, or copier address that may no longer be authorized after the migration. Check sender address restrictions.
  5. 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 (STARTTLS), app passwords, or authenticated submission on a different port.
  6. 6.Update the real active SMTP settings on the device and save them only after confirming the new host, credentials, and sender policy are correct, because repeated retries against the wrong relay can hide the actual cutover problem.
  7. 7.Send a controlled test scan and confirm which SMTP server handled it by checking message headers (Received headers), relay logs, or provider traces, because a successful delivery alone does not prove the old server is no longer in use.
  8. 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. 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.

Verification

Confirm the fix is complete:

  1. 1.Send a test scan and verify the recipient receives it
  2. 2.Check message headers to confirm the message went through the new SMTP server
  3. 3.Verify the device shows successful send status without errors
  4. 4.Test multiple scan destinations (email addresses) if configured
  5. 5.Check device logs for successful SMTP connection to the new server

Prevention

To avoid this issue in future mail migrations:

  • Create an inventory of all devices that send email (scanners, copiers, applications) before migration
  • Include device SMTP configuration in the migration checklist
  • Update device settings proactively as part of migration planning, not post-migration cleanup
  • Use centralized relay services that devices can authenticate to consistently
  • Document device-specific authentication requirements before choosing a new email provider
  • Test scan-to-email functionality explicitly after migration, not just user mailbox access
  • [Technical troubleshooting: Fix Bounce Handling Verp Envelope Return Path Conf](bounce-handling-verp-envelope-return-path-configuration)
  • [Fix Email Attachment Rejected Size Exceeding Provider Limit 25mb Issue in Email](email-attachment-rejected-size-exceeding-provider-limit-25mb)
  • [Fix Email Bounce 550 Permanent Failure Recipient Address Rejected Issue in Email](email-bounce-550-permanent-failure-recipient-address-rejected)
  • [Fix Email Dkim Signature Verification Failing After Key Rotation Issue in Email](email-dkim-signature-verification-failing-after-key-rotation)
  • [Fix Email Dmarc Policy Quarantine Message In Spam Folder Issue in Email](email-dmarc-policy-quarantine-message-in-spam-folder)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "How to Fix a Scanner Still Using the Old SMTP Server After Mail Migration", "description": "Resolve a scanner or multifunction device still sending through the old SMTP server after mail migration by checking saved relay settings, authentication, and device mail profiles.", "url": "https://www.fixwikihub.com/fix-scanner-still-using-old-smtp-after-mail-migration", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2025-10-31T05:04:24.052Z", "dateModified": "2025-10-31T05:04:24.052Z" } </script>