🧭 Autodiscover / Autoconfig Checker

How this Autodiscover and Autoconfig checker works

A user types their email address into Outlook, Apple Mail, Thunderbird, or eM Client. The inbox just works. The thing doing the work is either Microsoft's Autodiscover, Mozilla's Autoconfig, or one of the standards-based SRV fallbacks. None of them are mandatory. All of them decide whether your users finish setup in two taps or open a ticket about IMAP server names.

This checker probes every client-config pathway in parallel and reports what each one returned.

What gets probed on the Outlook side?

Four pathways, in the order Outlook tries them:

autodiscover.<domain>                              ← CNAME / A
_autodiscover._tcp.<domain>                         ← SRV
https://autodiscover.<domain>/Autodiscover/Autodiscover.xml   ← legacy XML
https://autodiscover.<domain>/autodiscover/autodiscover.json/v1.0/<email>  ← V2 JSON

Each probe reports HTTP status, TLS validity, and whether the response parses. A Microsoft 365 tenant is recognised when any of the four resolves to autodiscover.outlook.com. That's the cloud-hosted Exchange answer Microsoft itself recommends.

What about Thunderbird and everything else?

Thunderbird and most non-Microsoft clients walk a different ladder:

https://autoconfig.<domain>/mail/config-v1.1.xml
https://<domain>/.well-known/autoconfig/mail/config-v1.1.xml
https://<domain>/.well-known/mail-v1.xml
RFC 6186 SRV: _imaps._tcp, _imap._tcp, _submission._tcp, _submissions._tcp, _pop3s._tcp, _pop3._tcp
Mozilla ISPDB at autoconfig.thunderbird.net

The checker hits each layer and reports which one answered. That tells you whether your domain publishes its own config, leans on a provider hardcoded into clients, or falls back to the Mozilla community database. Where an autoconfig XML responds, the checker parses it and lists the actual incoming and outgoing server hostnames, ports, socket type, and auth method.

What about calendars, contacts, and iOS?

RFC 6764 defines SRV records for CalDAV and CardDAV at _caldavs._tcp and _carddavs._tcp. Apple Mail, Outlook, and Thunderbird use them to attach calendar and contact accounts at the same time as the mailbox. Apple Mail on iOS and macOS also looks at https://mail.<domain>/.well-known/mailconfig for a configuration profile. The checker probes both so a full client-setup audit shows up in one report.

When the MX or SPF identifies a known mail provider (Microsoft 365, Google Workspace, Apple iCloud, Fastmail, Zoho), the verdict factors in the built-in fallback those clients ship for that provider. That's why a Google Workspace domain with zero autoconfig records still grades as "configured".

Why this matters after a migration

Our take: the most common reason Outlook breaks after a provider migration is the autodiscover CNAME still pointing at the previous host, even though the MX has been moved. Existing profiles keep working off cached settings. New users on the same domain land on a tenant that no longer accepts their password, and the error message is unhelpful.

What to do: after every migration, check the autodiscover CNAME on the same change ticket as the MX. If you publish your own autoconfig XML, update the hostnames in it at the same time — the checker's XML / live-MX cross-check banner flags this exact mismatch.

Where to go next

Autodiscover is one of several records a hosted tenant needs right. For the full Microsoft set, run the Microsoft 365 DNS checker; the Google equivalent is the Google Workspace DNS checker. Because autodiscover is usually a CNAME, the other CNAMEs on the domain are worth a sweep with the CNAME record checker. Dangling CNAMEs are a separate failure mode and they look identical from the user's side.