Introduction

A mail migration can move inbound and outbound mail successfully while Gmail Send As still tries to send through the previous SMTP server. Users may receive mail correctly in the new system, but replies or alias-based sending from Gmail keep failing because Gmail is still holding an older outbound relay target, credential set, or app password. This creates a confusing situation where email appears to work normally, but sending from custom addresses fails silently or generates errors.

Treat this as a saved outbound relay problem instead of a general mailbox outage. Start by checking the exact SMTP server Gmail uses for the affected alias, because Gmail Send As settings often survive a provider change long after the mailbox itself has moved. This issue is particularly common after migrations from on-premises Exchange to cloud email providers, or when moving between different hosted email services.

The problem typically emerges after email provider migrations, SMTP relay changes, or when organizations consolidate email services. Gmail users who have configured "Send mail as" aliases with custom SMTP settings often find that these settings persist after the main email infrastructure changes, causing outbound mail failures that are easily mistaken for general delivery problems.

Symptoms

  • Gmail can receive mail, but sending from a custom address fails or stalls with connection errors
  • Sent messages from Gmail still try to use the previous SMTP hostname and generate bounce notifications
  • Gmail shows authentication or connection errors when using Send As, often with messages like "Could not connect to SMTP server"
  • One alias fails while another address in the same account works normally
  • Test messages sent from Gmail headers or logs point to the old provider in Received headers
  • The problem started after a mail migration, provider switch, or SMTP credential change
  • Outbound mail shows as coming from the old domain or provider in message headers
  • Reply-to addresses or sender domains appear incorrect to recipients
  • Gmail shows a yellow warning banner about the custom SMTP server being unavailable

Common Causes

  • The Send As alias in Gmail still stores the old SMTP hostname, port, or encryption mode (SSL vs TLS)
  • Gmail is using an older password or app password that only worked on the previous provider
  • The mailbox moved, but the Gmail alias configuration was never updated with new SMTP details
  • A provider-specific outbound relay or submission hostname changed during migration (e.g., from smtp.oldprovider.com to smtp.newprovider.com)
  • The old SMTP server still partially accepts connections, hiding the stale configuration until a later failure
  • Users tested incoming mail only and missed the separate outbound path used by Gmail Send As
  • SMTP authentication method changed (e.g., from password to app password) and Gmail was not updated
  • Port or encryption requirements differ between old and new providers (port 25 vs 587 vs 465)

Step-by-Step Fix

  1. 1.Send a test message from the affected Gmail alias and record the exact error message, because you need to confirm whether the failure is tied to SMTP connection details, authentication, or alias verification. Note the specific error code or message Gmail displays.
  2. 2.Open the Gmail Send As settings for the affected address (Settings > Accounts and Import > Send mail as) and compare the saved SMTP hostname, port, username, and security mode with the intended post-migration mail platform, because Gmail can keep an older outbound server long after the mailbox cutover is complete.
  3. 3.Verify that the new provider actually supports SMTP submission for that alias and username format, because some migrations change the required login address (full email vs username only), authenticated mailbox, or app-password requirement. Check the new provider's SMTP documentation.
  4. 4.Check whether the saved password or app password in Gmail belongs to the old provider, because Gmail Send As failures often continue after migration when only the mailbox password changed but the alias relay credential did not. Generate a new app password if required.
  5. 5.Update or recreate the Send As alias only after confirming the correct new SMTP settings, because partial edits can leave one stale field behind and make the fix look unsuccessful. Delete the old alias and re-add it with fresh credentials if editing fails.
  6. 6.Test the same mailbox directly against the intended SMTP server outside Gmail using telnet or an email client if needed, because that separates a bad Gmail alias configuration from a wider outbound mail problem on the new platform. Use: telnet smtp.newprovider.com 587.
  7. 7.Send another test from Gmail and inspect the message headers or provider logs to confirm the message now leaves through the expected SMTP service, because a successful send is only useful if it uses the correct new relay. Check the "Received" headers in the sent message.
  8. 8.Remove any unused legacy SMTP credentials or old provider-specific app passwords after the cutover, because leaving the old relay path active makes future troubleshooting confusing and increases security exposure.
  9. 9.Document the final Send As configuration for each alias that must send through Gmail, because shared mailbox and alias migrations often fail later when outbound settings are assumed to match inbound mail automatically.

Verification

Confirm the fix is working:

  1. 1.Send a test email from the Gmail alias and verify the recipient receives it
  2. 2.Check the message headers to confirm the message went through the new SMTP server
  3. 3.Test sending to multiple recipients including external addresses
  4. 4.Verify no authentication or connection errors appear in Gmail when sending
  5. 5.Monitor for 24 hours to ensure outbound mail continues working reliably

Prevention

To avoid this issue in future email migrations:

  • Document all Gmail Send As configurations before beginning an email migration
  • Update Gmail alias SMTP settings as part of the migration checklist, not as a post-migration cleanup
  • Test both incoming and outgoing mail for each Gmail alias after cutover
  • Use consistent SMTP settings documentation that can be referenced during migrations
  • Notify Gmail users to check their Send As settings when email provider changes occur
  • Schedule a review of Gmail configurations one week after migration to catch missed aliases
  • [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 Gmail Send As Still Using the Old SMTP Server After Mail Migration", "description": "Resolve Gmail Send As still using an old SMTP server after mail migration by updating alias settings, authentication, and outbound relay details.", "url": "https://www.fixwikihub.com/fix-gmail-send-as-old-smtp-after-migration", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2025-10-31T12:36:01.775Z", "dateModified": "2025-10-31T12:36:01.775Z" } </script>