🔄 Overview
If Mailbird tells you that Exchange autodiscover is missing or not configured correctly, or you see errors mentioning "autodiscover is not set up", "autodiscover not working", XML parsing errors, or "Login Timeout 440", the autodiscover service on your Exchange server either isn't reachable or is returning an invalid response.
⚠️ Note: This article covers on-premise Exchange servers. If you use Microsoft 365, Mailbird handles configuration automatically via OAuth 2.0 — you shouldn't see this error. If you do, see Microsoft Office 365 OAuth 2.0.
🔍 What's happening
Autodiscover is the service Exchange uses to automatically tell email clients where your mailbox lives. When it's misconfigured, Mailbird can reach the autodiscover endpoint but the response is malformed — unlike the "cannot be located" error which means the endpoint can't be reached at all.
Common causes include:
- The autodiscover endpoint returns an HTML login page (often "Login Timeout 440") instead of the expected XML response.
- The SSL certificate on the autodiscover virtual directory is misconfigured.
- Authentication settings on the autodiscover virtual directory are incorrect.
- A reverse proxy or load balancer is intercepting autodiscover requests.
🛠️ What you can do
If this is a work or school account
Contact your IT administrator and share the exact error message. They'll need to check the Exchange server configuration — this isn't something you can fix from the client side. The sections below are for administrators.
For administrators: validate autodiscover
1. Test autodiscover from a browser
Visit https://autodiscover.yourdomain.com/autodiscover/autodiscover.xml in a browser. You should be prompted for credentials and then see an XML response. If you see:
- An HTML login page — authentication is misconfigured on the virtual directory.
- A certificate warning — the SSL certificate needs to be replaced or include the autodiscover hostname as a SAN.
- A 404 or timeout — the autodiscover virtual directory isn't published, or DNS/firewall is blocking the endpoint.
2. Run Test-OutlookWebServices
On your Exchange server:
Test-OutlookWebServices -Identity: user@example.com -MailboxCredential (Get-Credential)All results should show Success. Any failure points to a specific misconfigured service.
3. Check the autodiscover virtual directory
Get-AutodiscoverVirtualDirectory | Format-List Identity, InternalUrl, ExternalUrl, *Authentication*Verify the URL is reachable and that at least one authentication method matches what your clients use (typically Basic or Windows Integrated).
4. Check your SSL certificate
The certificate bound to IIS must include autodiscover.yourdomain.com as a Subject Alternative Name (SAN). If it doesn't, browsers and clients will reject the response.
5. Check DNS
Your public DNS should resolve autodiscover.yourdomain.com to your Exchange server, OR have an SRV record:
- Type: SRV
-
Name:
_autodiscover._tcp.yourdomain.com -
Value:
0 0 443 mail.yourdomain.com
🛠️ Workaround: Manual EWS configuration
If autodiscover can't be fixed quickly, you can configure Mailbird manually using your Exchange Web Services (EWS) URL:
- Add your account in Mailbird as usual.
- When you reach the settings screen, click Edit server settings.
- Enter the EWS URL — typically
https://mail.yourdomain.com/EWS/Exchange.asmx.
⚠️ URLs ending in /Microsoft-Server-ActiveSync, /OWA, or /EAS are not supported.
💬 Need more help?
If you're still having trouble, contact our Customer Happiness Team. Include:
- The exact error message from Mailbird
- Whether this is on-premise Exchange or hosted Exchange
- Your Exchange server version, if known