Introduction

Outlook Autodiscover failures often appear right after a DNS move, a mail migration, or a cleanup of old records. Mailboxes still exist, but Outlook cannot locate the correct Microsoft 365 settings automatically, so profile setup stalls or keeps asking for manual server details. The fastest fix is to verify the live Autodiscover record in the authoritative DNS zone, remove anything left from the previous mail provider, and confirm the domain is now publishing the Microsoft 365 values you actually intend to use.

Symptoms

  • Outlook setup keeps prompting for credentials or server settings instead of finishing automatically
  • A new Outlook profile fails after a DNS change even though webmail still works
  • Users are redirected to an old mail provider during account setup
  • Different devices see different setup results during the same migration window
  • Autodiscover tests fail after changing nameservers, MX records, or mail hosting

Common Causes

  • The autodiscover host was not recreated after moving DNS to a new provider
  • The Autodiscover record still points to a retired mail platform instead of Microsoft 365
  • A conflicting A, CNAME, or duplicate DNS entry exists for the same autodiscover hostname
  • Changes were made in the wrong DNS panel after a nameserver move
  • Cached DNS answers are still returning the old mail configuration during cutover

Step-by-Step Fix

  1. Check the live authoritative DNS for the autodiscover hostname instead of trusting the record shown in a control panel that may no longer be authoritative.
  2. Confirm the domain is meant to use Microsoft 365 for mailbox discovery, then verify the autodiscover record matches the provider’s expected target for Outlook client setup.
  3. Remove any conflicting record types for autodiscover, because an old A record or duplicate entry can break client discovery even when the intended CNAME was added.
  4. Review the full zone for leftover references to the previous mail provider, especially old Autodiscover, Exchange, or hosted email records that can still attract client configuration.
  5. If nameservers were changed recently, verify the edits were made in the active DNS host and not in the old provider’s inactive zone.
  6. Re-test from multiple public resolvers if results differ, because cached DNS can make some devices keep following the previous Autodiscover path for a while.
  7. Create a fresh Outlook profile or rerun Microsoft’s remote connectivity checks after the corrected record is live so you can confirm discovery works with current DNS, not cached local settings.
  8. If mailbox discovery still fails, confirm the domain remains healthy in Microsoft 365 and that the mail migration did not leave users on a hybrid or retired endpoint.
  9. Keep Autodiscover, MX, SPF, and related mail records in one documented migration checklist so the next DNS change does not break Outlook setup while mail itself appears partly functional.