Autodiscover DNS

Autodiscover DNS

Autodiscover is the protocol that lets Outlook configure itself from nothing but an email address. The user types firstname.lastname@isidoregroup.com, the client walks through a small discovery sequence, and Outlook arrives at the right server, the right authentication endpoint, and the right mailbox without the user knowing anything about IMAP, ActiveSync, or EWS.

The discovery sequence relies on a DNS record. If the record is missing, the sequence falls back to less reliable methods, and users see manual server-settings prompts. That’s the entire reason this check exists.

How Outlook discovers a mailbox

When Outlook starts setup for user@isidoregroup.com, it tries the following in order:

  1. HTTPS to https://isidoregroup.com/autodiscover/autodiscover.xml — the root of the domain. Rarely configured.
  2. HTTPS to https://autodiscover.isidoregroup.com/autodiscover/autodiscover.xml — the autodiscover subdomain. This is the path that actually works in modern setups.
  3. SRV lookup for _autodiscover._tcp.isidoregroup.com — a fallback for legacy on-prem Exchange.
  4. HTTPS redirect from the local intranet — a domain-joined client can pull settings from Active Directory.

For the cloud case (M365), step 2 is the one that matters. The autodiscover endpoint at autodiscover.outlook.com is Microsoft’s, and the DNS record at the client’s domain is a CNAME pointing there:

autodiscover.isidoregroup.com.   3600   IN   CNAME   autodiscover.outlook.com.

When that CNAME exists, Outlook resolves it, hits Microsoft’s discovery endpoint, gets pointed at the right tenant, and silently completes setup. When the CNAME is missing, Outlook still finds the tenant most of the time — Microsoft has fallback mechanisms — but users see warning dialogs, manual prompts, or “we’re having trouble connecting” delays. None of that is technically a failure; it’s friction that should not exist.

What Cathedra checks

AutodiscoverCheck runs three DNS probes at the same names:

  1. dns_get_record("autodiscover.{domain}", DNS_CNAME) — the standard CNAME.
  2. dns_get_record("autodiscover.{domain}", DNS_A) — A record as fallback (legacy on-prem).
  3. dns_get_record("_autodiscover._tcp.{domain}", DNS_SRV) — the SRV fallback (also legacy).

If any of the three return results, Cathedra emits:

status: pass
“Autodiscover DNS present: {details}”

The details string lists what was found. Examples:
– “Autodiscover DNS present: CNAME → autodiscover.outlook.com.”
– “Autodiscover DNS present: A → 192.0.2.10”
– “Autodiscover DNS present: CNAME → autodiscover.outlook.com.; SRV record present”

If none of the three return any records:

status: warning / severity: low
“No autodiscover DNS record found. Outlook may prompt users for manual server settings.”
Recommendation: “If using Microsoft 365, add a CNAME for autodiscover.{domain} pointing to autodiscover.outlook.com.”

The wording matters: “Outlook may prompt users for manual server settings.” That’s a friction warning, not a delivery failure. Mail still flows. New mailbox setup gets bumpy.

The optional HTTP probe

After the DNS check, AutodiscoverCheck makes one more attempt — an HTTPS request to https://autodiscover.{domain}/autodiscover/autodiscover.xml with TLS verification disabled and a 5-second timeout. If the response body contains the strings outlook.com or office365, Cathedra emits an additional info-only line:

status: info / severity: null
“Autodiscover HTTP endpoint responds with Microsoft 365 references.”

This is a soft confirmation that M365 is in the chain. The probe is wrapped in a try/catch — any failure (timeout, DNS error, TLS handshake refused, HTTP error) is swallowed silently. You will not see a finding about the HTTP probe failing. If the indicator doesn’t appear, that’s all you know: the probe didn’t return Microsoft-flavored content. It doesn’t prove M365 isn’t in use.

When the CNAME is missing but mail still works

This is the most common scenario you’ll encounter. A client moved to M365 years ago. Mail works. Outlook setup mostly works. But there’s no autodiscover.{domain} CNAME — somebody never published it during the original migration, and nobody noticed because most discovery still completes via Microsoft’s broader fallbacks.

Cathedra reports the warning. Your job: confirm it’s a low-impact gap and recommend the fix. The fix is one CNAME record:

Host: autodiscover
Type: CNAME
Points to: autodiscover.outlook.com
TTL: 3600

Wait for TTL, re-run Cathedra. The warning becomes a pass.

For Google Workspace clients, the autodiscover CNAME isn’t relevant the same way — Workspace doesn’t use the autodiscover protocol. The check will still warn. Note on the audit report: “Client uses Google Workspace; autodiscover CNAME is not applicable.”

The two legacy patterns

You’ll occasionally encounter the A-record and SRV-record patterns from on-prem Exchange days. They’re valid and Cathedra will report pass on them.

A-record pattern: autodiscover.acme.com. resolves directly to the on-prem Exchange server’s IP. Used when there’s no need for indirection. Cathedra’s detail string: “A → 192.0.2.10”

SRV-record pattern: A _autodiscover._tcp.acme.com SRV record points to a discovery endpoint with a port and weight. Used when the discovery endpoint is on an unusual hostname or port. Cathedra detail string: “SRV record present”

Both patterns are increasingly rare. They show up on legacy hybrid setups (M365 with on-prem Exchange still running for some users) and on a few self-hosted shops. If you see either pattern on a cloud-only M365 client, somebody added the wrong record type — recommend replacing with the standard CNAME.

Cheat sheet

Condition Cathedra status Note
CNAME at autodiscover.{domain} pass Standard M365 pattern
A record at autodiscover.{domain} pass Legacy on-prem pattern
SRV at _autodiscover._tcp.{domain} pass Legacy fallback
None of the above warning / low “Outlook may prompt users for manual server settings.”
HTTP endpoint returns Microsoft strings info (additional) “Autodiscover HTTP endpoint responds with Microsoft 365 references.”

Quick command reference

dig autodiscover.isidoregroup.com CNAME +short
autodiscover.outlook.com.

If the result is empty, also check for an A record or SRV record:

dig autodiscover.isidoregroup.com A +short
dig _autodiscover._tcp.isidoregroup.com SRV +short

What you should remember

  • Outlook uses Autodiscover to configure mailboxes from just an email address. The DNS record at autodiscover.{domain} is the standard discovery anchor.
  • For M365, the correct record is a CNAME pointing to autodiscover.outlook.com.
  • Cathedra checks three patterns at once: CNAME, A record, and SRV. Any one passing returns “Autodiscover DNS present: {detail}.”
  • When all three are missing, Cathedra warns: “No autodiscover DNS record found. Outlook may prompt users for manual server settings.” — warning / low.
  • The HTTP probe is informational only. Failure is silent. A successful match adds “Autodiscover HTTP endpoint responds with Microsoft 365 references.”
  • For Google Workspace clients, the warning is expected — note “not applicable for Workspace” on the audit report.

Next lesson covers the case where MX routes through an inbound security provider before reaching the mailbox host — reading the chain end to end.

Cathedra alignment: AutodiscoverCheck — Autodiscover DNS and M365 Indicator

Previous Topic
Back to Lesson
Next Topic