Unable to Setup your Office 365 Mailbox with Outlook

We get this question all the time. People are trying to setup mailboxes from their Office 365 Account, but it’s just not working. There are a number of reasons for the problems, but most of the time it boils down to the three listed below.

Here is the most common screen shot error. This is usually an issue with DNS

Here is the second most common screen shot error. This one is clearly password.



Check to make sure that your user (with the issues) has an active Exchange License assigned to their account. This is done through the Microsoft Online Portal

As you can see this user has a license properly assigned.

Check to make sure that the user is filling out the Outlook prompt correctly. The first two are pretty straight forward, but the password can throw some people off.

Your Name: Keep it neat and enter the display name on the account

E-mail Address: Your Office 365 email address

Password: Your Office 365 password. Most of the time when an account is setup, the users will forget (or don’t know) to login to the portal and change their password. Until that password is changed from the default one, Outlook will not setup correctly.

Since we know that Outlook relies on an Autodiscover DNS record lets verify that we can ping. If setup correctly when you ping autodiscover (from the internal network) or autodiscover.domainname.com (from the internet), you should get name resolution to autodiscover.outlook.com. We have verified that the DNS entries are correct in our public DNS, yet when we ping autodiscover or autodiscover.domainname.com, it tells me Ping request could not find a host.

The cause of the issue is a result of running split brain DNS. The resolution to this issue is to add the autodiscover CNAME record to your internal DNS server. Since your workstation is connected to the internal DNS server and it has a zone that matches your internet zone, you will never reach the public DNS server. For this reason, the CNAME record for Autodiscover needs to be added to the internal DNS server.

Once the CNAME record is added to the internal DNS server, the workstation can now resolve the name correctly.

Once Name resolution is cleared up, Outlook will now setup your account correctly.



Thanks for visiting and reading my posts. I am always looking for more ideas. Please comment or email me with what you would like to see.

Kelsey Epps

Office 365 MVP

Email Me Follow me on Twitter Connect with me on LinkedIN Facebook Me

25 thoughts on “Unable to Setup your Office 365 Mailbox with Outlook

  1. Melvin Colinares

    Kelsey, whoever you are, I just wanted to thank you for this, I can’t say enough. I’ve searched and read and applied whatever solutions I could find out there and nothings seems to work only to find out that this step right here should be part of the whole troubleshooting process… Hmmm I wonder why a lot of MS Support haven’t known about this… but really, thanks! You just save my day mate…

  2. Gilles

    Melvin you are a God saved me a ton of time. I looked everywhere after deploying a local domain controller, I could not connect to Office 365 exchange on any machine this saved me a ton of time !!!!!!!!!!

  3. Huss

    Hi Kelsey,

    Thanks a lot for the great Blog, in my case i’m migrating from Exchange On-Permise to O365, the Client has already a CNAME DNS record pointing to his internal autodiscover service.

    How I can work around this scenario and reach the O365 Autodiscover for the migrated users?


  4. kaps

    Hi Kelsey,

    we have EX2007 and using EX2013 as hybrid moving users to office365.
    we have to use internal access for outlook and OWA(not from external network)
    can you please suggest how we can cutover cas pointing from 2007 to EX2013 or do we have to create any external record(autodiscover) and cname recover on internal poiting to office365.


    1. Kelsey EppsKelsey Epps Post author

      If you have a hybrid server setup, then external access is required for that process. When the hybrid server is in play, then the option for cutover migration is removed from the portal.

  5. Pingback: Problems With Outlook Office 365 - ORG.org

  6. Paul C

    Hi Kelsey,

    Thanks for this post, it’s clarified some of the issues in my mind. My problem is I have the same issue as one of the guys above. We don’t have split brain DNS at my company, we have externally hosted public DNS but use a forward lookup zone internally to route autodiscover. Is split-brain DNS a pre-req for a cutover migration or is there a way around it (without destroying autodiscover and whatever else). We’re running Exchange 2007. Any advice you can give would be really appreciated.

    1. Kelsey EppsKelsey Epps Post author

      No, it’s not a requirement. As long as you have access to both DNS spaces you will be able to create the records that are needed.

  7. Ron

    Thank you so much for the clear and easy to understand explaination especially with the internal CNAME. I have searched and posted on Microsoft community board until I am blue in the face and everyone including MS states that I only need the external DNS CNAME yet when I state that autodiscover does not work w/o an internal CNAME they still stick to their guns and state even when internal, the client will look for the public record CNAME. Again, thanks so much for also stating why in this case (Split DNS) an internal CNAME is required. I will now read up a little more on split DNS so I fully understand it but again, thank you a hundred times!!


Leave a Reply