Autodiscover DNS Records: Fix Email Auto-Setup Failures

A customer emailed us last week annoyed that Outlook kept popping up a settings dialog every time they added their mailbox on a new laptop. Webmail worked fine. Manual IMAP setup worked fine. But every "auto setup" button in Outlook, the Mail app on iPhone, or the built-in wizard in Thunderbird just sat there spinning before giving up and asking for the mail server hostname by hand. That's almost always a missing or wrong autodiscover/autoconfig DNS record — not a broken mailbox.

Symptom

You'll usually see one or more of these:

• Outlook's "Add Account" wizard hangs, then falls back to asking for IMAP/SMTP hostnames manually
• Apple Mail on iPhone/Mac won't auto-fill server settings from just the email address and password
• Thunderbird's account wizard can't find configuration and drops you into manual setup
• Outlook repeatedly re-prompts for a password even though the password is correct, because it's stuck trying (and failing) to resolve autodiscover

None of this breaks mail delivery. Your MX, SPF, and DKIM can be perfect and you'll still hit this, because autodiscover is a completely separate lookup that mail clients use purely for convenience setup, not for delivering mail.

Cause

Microsoft clients (Outlook, and to a lesser extent the Windows/iOS Mail apps) look for account settings using the Autodiscover protocol. Thunderbird and some Apple clients use a similar mechanism called Autoconfig. Both work by guessing a URL based on your email domain and fetching an XML file that tells the client which IMAP/SMTP/EWS server to use.

The client tries, roughly in this order:

1. https://autodiscover.yourdomain.com/autodiscover/autodiscover.xml
2. An SRV record lookup for _autodiscover._tcp.yourdomain.com
3. https://autoconfig.yourdomain.com/mail/config-v1.1.xml (Thunderbird/Apple style)
4. A hardcoded ISPDB lookup at Mozilla's servers, which almost never matches a custom hosting domain

If autodiscover.yourdomain.com or autoconfig.yourdomain.com doesn't resolve at all, most clients time out slowly before falling back — which is exactly the "hangs, then asks for manual settings" behaviour customers report. cPanel/Exim hosting can actually serve a basic autodiscover XML on the same server as your mail, but only if the DNS record points there. If it points nowhere, or worse, points at a different provider's server (very common after a partial migration to Google Workspace or Microsoft 365), the client either fails or picks up someone else's configuration.

Fix

Log in to cPanel and open Domains » Zone Editor (or WHM's DNS Zone Manager if you manage this at the reseller/root level). Add the records below for the domain in question. Replace mail.yourdomain.com with wherever your actual mail service lives — usually your cPanel server's hostname if you're using cPanel's built-in email, or the mail provider's endpoint if you've moved mail elsewhere.

A few things that trip people up:

• If mail is hosted on cPanel, point these at your mail server's actual hostname (check Email Accounts » Connect Devices in cPanel to see the exact hostname it's already telling you to use for IMAP/SMTP). cPanel/Exim will serve a working autodiscover.xml from that hostname automatically — you don't need to build the XML file yourself.
• If you're on Google Workspace or Microsoft 365 but still host the website on SkyServer, do not point autodiscover at your cPanel server. Use each provider's documented value instead: Google Workspace generally doesn't require an autodiscover record for Gmail-based mail clients, but Microsoft 365 needs autodiscover.yourdomain.com as a CNAME to autodiscover.outlook.com. Mixing these up is the single most common cause of this problem after a mail migration — the website DNS gets updated but the autodiscover record still points at the old host.
• Check for a stale record first. Run dig autodiscover.yourdomain.com CNAME and dig autoconfig.yourdomain.com CNAME before adding anything. If something's already there pointing at an old server, edit it rather than adding a duplicate — duplicate CNAMEs for the same name are invalid DNS and will cause unpredictable resolution.
• SSL matters. Whatever hostname autodiscover/autoconfig resolves to needs a valid SSL certificate covering that name, or Outlook will refuse the connection outright. If you're pointing at your own cPanel server, an AutoSSL wildcard or a certificate that covers autodiscover.yourdomain.com specifically will handle this.

After adding the records, give DNS a few minutes to propagate, then test with:

dig autodiscover.yourdomain.com CNAME
dig autoconfig.yourdomain.com CNAME
dig SRV _autodiscover._tcp.yourdomain.com

For a more thorough check specifically for Outlook, Microsoft's Remote Connectivity Analyzer will walk through every step Outlook itself takes and tell you exactly where it fails. On the client side, holding Ctrl and right-clicking the Outlook tray icon gives you a "Test E-mail AutoConfiguration" option that shows the same diagnostic without leaving your desktop.

Prevention

Add autodiscover/autoconfig to your standard DNS checklist right alongside MX, SPF, DKIM, and DMARC — it's easy to forget precisely because email keeps working without it. A couple of habits that save support tickets down the line:

• Whenever you migrate mail to or from a provider (cPanel to Google Workspace, Workspace to 365, etc.), update autodiscover in the same change window as MX. Treat them as one unit, not two separate tasks.
• Document which service each of these records is supposed to point to, right in your DNS zone notes or a shared runbook. Six months later nobody remembers why autodiscover points where it does.
• If you manage several domains under one WHM reseller account, consider a DNS template that includes these records by default for any domain using cPanel-hosted email, so new accounts don't miss them.

Frequently Asked Questions

Do I need this record if webmail and manual IMAP setup already work fine?

Not strictly — mail will keep flowing either way. But every user who tries the "auto setup" option in Outlook, Apple Mail, or Thunderbird will hit a delay or a failed setup without it, which usually turns into a support ticket. It's a small DNS change that removes a recurring annoyance.

What's the actual difference between autodiscover and autoconfig?

Autodiscover is Microsoft's protocol, used by Outlook and Exchange-aware clients. Autoconfig is the equivalent used by Thunderbird and picked up by some Apple Mail versions. They serve the same purpose — handing a client your IMAP/SMTP/server settings automatically — but use different hostnames and slightly different XML formats, which is why you generally want both records in place.

I use Microsoft 365 for email but SkyServer for hosting — where should autodiscover point?

Point autodiscover.yourdomain.com as a CNAME to autodiscover.outlook.com, not to your cPanel server. Your website's A record can still point to SkyServer; autodiscover is independent of where the site lives and only cares about where mail lives.

Why does Outlook keep re-prompting for my password even though it's correct?

This is often a symptom of the same root cause. Outlook is silently retrying autodiscover in the background, failing, and surfacing that failure as a generic credential prompt. Fixing the DNS record and clearing Outlook's cached autodiscover data (Control Panel > Mail > the Autodiscover XML cache, or simply recreating the Outlook profile) usually resolves it.

How long after adding the record until clients pick it up?

DNS propagation for a new CNAME or SRV record is typically fast — often under an hour given a reasonable TTL — but Outlook and other clients cache autodiscover results locally for much longer. If the record looks correct in dig but the client still fails, restart the mail client or recreate the account profile rather than waiting longer on DNS.