Outlook Autodiscover Not Working? Fix Email Auto-Setup in cPanel

You hand a client their new you@yourdomain.com address, they open Outlook, and instead of the usual "account added" moment it just sits there spinning on "Searching for your mail server settings." Eventually it gives up and asks them to type in IMAP and SMTP hostnames by hand. That's autodiscover failing -- and it's one of the most common tickets we see after a domain moves to a new host.

What Autodiscover Is Actually Doing

When you type an email address and password into Outlook, Apple Mail, or a phone's mail app, the client doesn't ask you for server names anymore -- it goes looking for them itself. There are two competing mechanisms doing this behind the scenes, and cPanel supports both:

• Autoconfig (Mozilla/Thunderbird style) -- the client requests http://autoconfig.yourdomain.com/mail/config-v1.1.xml, and cPanel's mail server answers with an XML file describing the IMAP/SMTP hosts, ports, and encryption to use.
• Autodiscover (Microsoft/Outlook style) -- Outlook tries a sequence of URLs, most importantly https://autodiscover.yourdomain.com/autodiscover/autodiscover.xml, and falls back to an SRV DNS lookup (_autodiscover._tcp.yourdomain.com) if the URL fails.

cPanel's mail server (Exim/Dovecot stack) actually serves both of these automatically for any domain hosted on the account -- if the DNS and SSL pieces around it are set up correctly. Most failures aren't a cPanel bug at all; they're a missing DNS record or an SSL certificate that doesn't cover the right hostname.

Symptom → Likely Cause

Fix 1: Confirm the DNS Records Actually Exist

Run this from a terminal (or use dig on any Linux/Mac machine, or nslookup on Windows):

dig autoconfig.yourdomain.com +short
dig autodiscover.yourdomain.com +short
dig SRV _autodiscover._tcp.yourdomain.com +short

If your domain uses cPanel's own DNS zone (nameservers pointed at Getwebup), these records get created automatically when the domain is added -- but only if the zone hasn't been overridden by a manually edited zone file or a partial migration. If the domain's nameservers point somewhere else (Cloudflare, GoDaddy DNS, a registrar's default DNS), you have to add these records yourself, because that external DNS provider knows nothing about your cPanel server.

Add these two records at minimum, pointing at your server's IP or hostname:

autoconfig.yourdomain.com   A      YOUR.SERVER.IP.HERE
autodiscover.yourdomain.com A      YOUR.SERVER.IP.HERE

If you're on Microsoft 365 for some domains and cPanel mail for others, double-check there isn't a leftover autodiscover CNAME from a previous Office 365 setup pointing at autodiscover.outlook.com. That record will win over cPanel's and send Outlook looking in the wrong place entirely.

Fix 2: Match the SSL Certificate to the Hostname

Autodiscover and autoconfig both run over HTTPS, and if the certificate presented doesn't cover the hostname being requested, most clients refuse to proceed rather than silently ignore the warning. cPanel's AutoSSL normally issues a certificate that covers mail.yourdomain.com, but it doesn't automatically add autodiscover.yourdomain.com or autoconfig.yourdomain.com as separate SANs unless those subdomains exist as real vhosts.

In practice this usually isn't a problem for cPanel-hosted mail, because the autodiscover/autoconfig responses are served off the shared mail service's own certificate (mail.yourdomain.com) rather than one tied to the exact subdomain name -- Outlook and Thunderbird accept that since the request still lands on the same server. Where it actually breaks is when a proxy or CDN (commonly Cloudflare, in "proxied" orange-cloud mode) sits in front of the autoconfig/autodiscover subdomain and terminates SSL with its own certificate that doesn't match. If you're using Cloudflare:

• Set the autoconfig and autodiscover DNS records to DNS only (grey cloud), not proxied.
• Leave your main www/root domain proxied if you want Cloudflare's CDN and firewall on the actual website -- only the mail-discovery subdomains need to bypass the proxy.

Fix 3: Check What's Actually Being Returned

You can query the autoconfig endpoint directly to see whether the server is responding at all, without touching Outlook:

curl -v http://autoconfig.yourdomain.com/mail/config-v1.1.xml

A working response returns an XML document listing incomingServer and outgoingServer blocks with mail.yourdomain.com, port 993 (IMAP) and 465 (SMTP), type SSL. If you get a connection timeout, it's DNS or a firewall. If you get a 404 or a generic Apache/Nginx page instead of XML, the request is landing on the wrong vhost -- usually because the domain is pointed at a different server (a reverse proxy or a page-builder host) that has no idea it's supposed to forward mail-config requests to the actual cPanel box.

Fix 4: Clear the Client's Cached (Bad) Config

Outlook and Thunderbird both cache a failed or wrong autodiscover result more aggressively than you'd expect, so fixing the DNS/SSL side won't always show up immediately in the client:

• Outlook (Windows): close Outlook completely, then delete the account profile and re-add it, or clear the cached data under %LOCALAPPDATA%\Microsoft\Outlook (folder name varies by Outlook version).
• Outlook (Mac): hold Option while clicking the Outlook Dock icon to reset, or remove and re-add the account -- Mac Outlook doesn't expose a manual cache-clear option.
• Thunderbird: config isn't cached client-side the same way, but a failed attempt is remembered for the session -- restart Thunderbird and retry the account setup wizard.

When to Just Skip Autodiscover

If you're on a tight deadline and the underlying DNS issue needs a propagation window to fix, don't make the client wait -- add the account manually with IMAP host mail.yourdomain.com (port 993, SSL) and SMTP host mail.yourdomain.com (port 465, SSL), full email address as the username. It works identically once it's in, and you can let autodiscover sort itself out for the next device without holding anyone up.

Prevention

• When you move a domain's nameservers away from cPanel's DNS to Cloudflare or another provider, copy over the autoconfig and autodiscover A records as part of the migration checklist -- they're easy to forget since they're invisible until someone tries to add an email account.
• Keep autoconfig and autodiscover subdomains DNS-only (unproxied) in Cloudflare permanently, even if you proxy everything else.
• If a domain ever ran Google Workspace or Microsoft 365 before switching to cPanel mail, audit the DNS zone for leftover autodiscover CNAMEs or MX records from the old provider -- they're a common source of "it worked yesterday" tickets.