Autodiscover 0x80072EE7 and 0x80072EFD: Outlook Cannot Reach the Discovery Endpoint

Fix it now

0x80072EE7 is WinINet 12007, the server name could not be resolved. 0x80072EFD is 12029, the attempt to connect to the server failed. One is DNS, the other is the path; nothing has reached a server that could answer, so your mailbox and credentials are not in question yet.

nslookup autodiscover.contoso.com
Test-NetConnection autodiscover.outlook.com -Port 443
netsh winhttp show proxy
ipconfig /flushdns

1. Read the nslookup answer. For a Microsoft 365 mailbox the published record is a CNAME with the alias Autodiscover pointing at autodiscover.outlook.com.
2. If the name resolves but the port test fails, the fault is a firewall, proxy or filtering appliance rather than DNS.
3. If a proxy is configured, confirm it is not intercepting or authenticating the Microsoft 365 endpoints.
4. Where an internal DNS zone exists for the same domain name, check the record is present there too. Split DNS is why a visibly correct public record still fails inside the office.
5. Retry, and for address book problems specifically use Send/Receive Groups and download the address book.

0x8004010F is the odd one in this family. Microsoft’s own article for it names a corrupted Outlook profile as the cause, not a network fault, and rebuilding the profile as the fix.

If a new profile now configures itself from an email address alone, you are done. The next section covers the lookup order and which step yours is failing at.

Why it happens

Autodiscover is a search order rather than a single lookup. A domain-joined client looks in Active Directory for a service connection point first. It then tries HTTPS at the root of the mail domain, then at the autodiscover host in that domain, then follows a redirect if one is offered, then looks for a DNS service record, and for Microsoft 365 there is a direct endpoint step as well. The client stops at the first answer it can use.

Because the order is fixed, a fault at any step shows up as a delay and then a failure at the end, which is why these codes appear during profile creation far more often than during normal use. 0x80072EE7 means a name in that sequence would not resolve at all. 0x80072EFD means the name resolved but the connection was refused or timed out, which points at a firewall, a proxy that will not forward, or a host that is not listening. 0x80072EE5 is WinINet 12005: the URL is invalid, which in practice means a bad override or a mistyped server entry.

0x8004010F does not belong to the network stack at all. Microsoft publishes it as NotFound – the requested object could not be found at the server – and its dedicated troubleshooting article gives the symptom as an Outlook data file that cannot be accessed, or an operation that failed because an object could not be found, with a corrupted Outlook profile as the cause. The documented fix is to read the default data file’s location from the broken profile, build a new profile, and point it at that file. That is a very different job from fixing DNS, and mixing the two up is how people spend a day on the wrong problem.

Full reference

Reading the evidence

What each code is reporting

The record Microsoft publishes

For a Microsoft 365 mailbox the required record is a CNAME: alias Autodiscover, target autodiscover.outlook.com. Microsoft’s description of what it does is worth quoting to whoever owns your DNS, because it explains why the record cannot simply be dropped: it helps Outlook clients connect to Exchange Online by using the Autodiscover service, which finds the correct host and configures Outlook for users.

Two neighbouring records get confused with it and neither one substitutes. The MX record sends inbound mail to Exchange Online and takes the form of a mail protection host name at a priority lower than any other MX record. The SIP federation service record belongs to Teams. Neither has any part in profile setup.

When DNS and the firewall both check out

• Test from a machine that has never had a profile on it. A machine with a working profile caches enough to hide a broken lookup.
• Check whether the failure is only on first configuration. Autodiscover runs at profile creation and periodically afterwards, so an existing profile can keep working for a long time after the record breaks.
• Check the account itself in a browser. A mailbox that will not open in Outlook on the web is not an Autodiscover problem.
• For an on-premises or hybrid deployment, confirm the published external URLs match the names on the certificate; a name the client cannot validate fails here as well.
• Check whether a security product is intercepting HTTPS on this machine. Interception produces its own family of codes but can present first as a connection that will not complete.

Address book downloads specifically

If mail flows and only the address book fails, work the profile rather than the network. Close Outlook and remove the cached offline address book folder under the user’s local application data, then start Outlook and force a download from the Send/Receive groups. For an on-premises deployment, have the administrator regenerate the offline address book and confirm the distribution point is reachable over HTTPS. Where the same error follows the account to a new profile on a different machine, the fault is on the server side and not on the client.

Every code this article covers

Confirm the fix worked

1. nslookup returns the expected Autodiscover target from the client.
2. The port 443 test to that target succeeds from the same machine.
3. A new Outlook profile configures itself from the email address alone, with no server details typed in.
4. The address book downloads with no error in the send and receive log.
5. The same test works from a second machine on the same network.

Questions people ask about this