Introduction

An email migration can move visible sending to the new provider while the Return-Path still points to the old one. Messages may appear to send normally, but bounces, SPF evaluation, and provider-specific headers still follow the previous platform because the hidden envelope sender was never updated.

Treat this as an envelope-sender problem instead of a mailbox or MX problem. Start with the full headers from a fresh test message and identify the live Return-Path in production traffic, because changing the visible From address or moving mailboxes does not automatically change the bounce path.

Symptoms

  • Message headers still show a Return-Path from the old email provider after migration
  • SPF or DMARC results fail even though the visible From address looks correct
  • Bounce messages or non-delivery reports still route through the previous provider
  • User-sent mail may look fine while app, form, or transactional mail still uses the old path
  • Recipients see old provider hostnames or envelope sender domains in message headers
  • The issue started after an email-provider migration, phased cutover, or SMTP relay change

Common Causes

  • An application, website, or SMTP relay still authenticates to the old provider
  • A custom bounce domain or Return-Path setting was never updated on the sending service
  • The migration changed branding and mailbox service but not the underlying envelope sender
  • A third-party sender still routes through the previous provider behind the scenes
  • Header checks focused on the visible From domain and missed the actual Return-Path
  • The migration checklist covered MX, SPF, and mailboxes but not bounce handling paths

Step-by-Step Fix

  1. Send a brand-new test message from the affected mail flow and inspect the full headers, because you need the exact live Return-Path before changing any provider settings.
  2. Separate mailbox-sent mail from application, website, and transactional mail if behavior differs, because one sending path may already be correct while another still uses the old provider.
  3. Check the sending platform for custom Return-Path, bounce domain, envelope sender, or MAIL FROM settings, because those controls often stay tied to the previous provider after migration.
  4. Review any SMTP relay, smarthost, API mail service, or plugin configuration that still sends through the old provider, because the wrong outbound route will keep producing the old Return-Path.
  5. Compare SPF alignment against the actual Return-Path domain in the headers, because SPF is evaluated against the envelope sender rather than the visible From address.
  6. Update the wrong bounce-domain or relay setting at the service that is generating the bad headers, because editing DNS or mailbox branding alone will not change the underlying envelope sender.
  7. Send fresh tests from every important mail source after the change and confirm the Return-Path now reflects the intended provider, because partial cutovers often leave one sender behind.
  8. Monitor bounces, SPF results, and DMARC reporting after the fix, because cached connections or overlooked services can keep producing the old path for part of your mail.
  9. Document which provider owns the Return-Path for each sending system in the environment, because envelope-sender settings are easy to miss during future email migrations.