DNS geolocation for Office 365, connecting you to your nearest Datacenter for the fastest connectivity

One of the main things we need to get right to ensure the most efficient and speedy connectivity to O365 is where in the world your DNS call is being completed. You'd think this wouldn't matter, you do a DNS lookup for your O365 tenant, get the address then connect right? Well, normally yes, but with O365, especially with Outlook, we do some pretty clever stuff to utilise our worldwide array of datacenters to ensure you get connected to your data as efficiently as possible.

Your Outlook connection will do a DNS lookup and we use the location of that lookup to connect you to your nearest Microsoft Datacenter. With Outlook we'll connect to a CAS server there and use our fast Datacenter to datacenter backbone network to connect you to the datacenter where your exchange servers (and data) are located. This generally works much quicker than a direct connection to the datacenter where your tenant is located due to the speed of the interconnecting networks we have.

http://technet.microsoft.com/en-us/library/dn741250.aspx outlines this in more detail but a diagram nicked from this post shows how this works for Outlook/Exchange connectivity when the Exchange mailbox is located in a NA datacenter but the user is physically located in EMEA. Therefore the DNS lookup is performed in EMEA, we connect to the nearest EMEA datacenter, which then routes the connection through to your mailbox over our backbone network, all in the background and your Outlook client knows nothing about this magic going on behind the scenes.


If your environment is making its DNS calls in a location on a different continent to where the user is physically located then you are going to get really bad performance with O365. Take an example where the user and Mailbox is located in EMEA. Your company uses DNS servers located in the USA for all calls, or the user is incorrectly set to use a proxy server in the USA, thus we're given the IP address of a USA based datacenter as that's where we think your user is located. The client will then connect to the USA based datacenter which will route the traffic to the EMEA datacenter which will then send the response back to the USA based datacenter which will then respond to the client back in EMEA. So with this scenario we've got several unnecessary trips across the pond with our data.

It is therefore vitally important to get the DNS lookup right for when you move to Outlook on Office 365.

So how do you check this? Well it could be a bit tricky as although we release a list of IP addresses used for O365, we don't tell you which ones map to where, for many reasons including the fact they change regularly. Thankfully one of my Microsoft colleagues has shown me an easy way to check you're connecting to a local datacenter.

All you need to do is open a command prompt on the client and ping outlook.office365.com and the response will tell you where the datacenter is you'll connect to. So sat here in the UK at home, I get EMEAWEST


If I connect to our Singapore VPN endpoint and turn off split tunnelling and force the DNS call down the VPN link (our Internal IT do a great job of making these things configurable for us techies) then I get directed to apacsouth.

And if I connect via VPN to the mothership in Seattle, my DNS call is completed there and thus I get directed to namnorthwest.

So it's a quick and easy check, just make sure the datacenter returned is in the same region as you're physically located in.

SharePoint is currently directed to the datacenter where your tenant is located so it doesn't matter so much where the call is made for this (although it should still preferably be local to the user for the portal connection). Lync is slightly different and is outlined in this article in more detail.

It's also worth ensuring all your clients are using a proxy in the same region as where they are located, as if not, they could hit the problem outlined above and thus be getting unnecessarily poor O365 performance.

Comments (24)

  1. Anonymous says:

    Hi Jouko,
    Both apaccentral & Apacnorth are APAC datacentres (Singapore & Hong Kong) neither are USA based. As long as you hit one in region you’re working effectively.



  2. Jouko says:


    Good article!

    I found that if checking ‘outlook.office365.com’ from China mainland it gave IP from US ‘outlook-apaccentral.office365.com (’ but ‘autodiscover.outlook.com’ gave "correct" continent autodiscover-apacsouth.outlook.com (

    Have this changed since the post have been wrote?

  3. Mark Wilson says:

    Interesting post Paul – does this work the same way for other workloads too (e.g. Skype for Business Online and SharePoint Online)?

  4. Hi Mark. SharePoint Online goes direct, so no geo-work is done on this. Skype for business tries to connect you to the nearest pool server but in the region where your tenant resides.

    https://support.office.com/en-gb/article/Client-connectivity-4232abcf-4ae5-43aa-bfa1-9a078a99c78b?ui=en-US&rs=en-GB&ad=GB covers this in more detail but in essence only Outlook/Exchange really works heavily with this.


  5. Anonymous says:

    I have been getting a lot of questions recently about OneDrive for Business from the field. Therefore

  6. Olof says:

    Is there a plan to change this for Onedrive for Business so that it works through datacenter connections over different regions?


  7. jamie says:

    Great article Paul. What’s the options if you have a parent company based in Singapore already on O365 and want the child company in NA to join them on O365. The experience for the NA company was horrendous latency, so NA is still on-premise. Noone from
    MCS could make it work.

  8. Latency from the USA to Singapore should allow Office 365 services to work perfectly well. Ensure DNS in the USA returns namxyz.office365.com with the important bit being NAM. Look also at tracert from the network egress with dns resolution enabled (tracert
    outlook.office365.com). You should be on the Microsoft global network relatively quickly which should have a router name msn.net. If your ISP is taking a long time to hit this network then it might be worth talking to them about peering with Microsoft in a
    suitable place which should bring the latency down. You should see latency of around 150-200ms from the USA to Singapore depending on where your start point is. If you have a Premier account, speak to your TAM About a support case or an Office 365 network
    performance assessment.

  9. rudi says:

    Hi Paul, great and interesting post I agree. I noticed our DNS forwarders are pointing to That has been corrected now. I’m based in the EU. We are experience extremely poor performance with Outlook Cached or Online. What I notice is that our Outlook
    clients are still connecting to the Exchange CAS servers in the US. Is this normal or am I missing something here? Eventhough it is pointing to an EMEA datacenter, Outlook-emeacenter2.office365.com [] for example, but the IP is based in the
    US . Should the IP not be Geo Located in EU? I read on the MS site there are EU based DataCenters in Dublin, Amsterdam enz so I would expect the session to connect to an IP address based in the EU. Also a traceroute shows different routes constantly changes
    from 10 hops to 16. From low to high latencies changes in minutes. Was wondering if this is normal or should the IP be based in EU datacenter. If normal, is there a possibility to just have the OL clients connect directly to DataCenters in EU, avoid the connection
    to the US servers. Thanks

  10. rudi says:

    On my homebased connection if I ping outlook.office365.com it points me to outlook-emeacenter2.office365.com as well but that IP seems to be an entrypoint in the US. Isn’t there something wrong wrong with this? This article describes my situation as well

  11. rudi says:

    OK. Seems that all below office365 entrypoints are physically located in the US :-).

    Let’s see if the DNS changes fix the poort Outlook performance.


  12. Hi Rudy, How are you ascertaining that the EMEAxyz.office365.com DNS locations are in the USA? If you’re using an online IP locator it will show almost all of Microsoft’s IPs in the USA but that’s not the case.

    Best bet is to tracert to the IP. The last hop which resolves will be a router in the datacenter you’re connecting to and should have a code in the middle of it in the following format db3=Dublin ams=Amsterdam hel=Helsinki vie=Vienna. The names may change slightly
    eg am3 for Amsterdam but you’ll get the idea.
    From my home if i trace to outlook.office365.com it resolves to EMEAWEST. However, this is just a container for IP addresses for all datacenters in Europe. We’ll connect first to the top of the list. In my case it is in Dublin which can be seen by db3 in the
    Router name last resolved in the tracert.

    13 34 ms 33 ms 31 ms ae12-0.db3-96c-2a.ntwk.msn.net []

    Latency is also another clue. It takes at least 70ms to cross the Atlantic so if you latency is 50ms then you can be sure it’s not going outside of EMEA.Above im in Dublin within 31ms and this is the last resolved router name so there is no way this has crossed
    the Atlantic.

    As for why the latency changes, EMEACenter for example will contain 10-16 IP addresses which map to all of the datacenter locations in Europe, hence you’ll hit different ones with each IP and as such the latency will fluctuate slightly.

    In short, as long as your clients are resolving outlook.office365.com to and EMEAxyz name, they will hit a CAS node in one of the four EMEA datacenters which have Exchange capacity.

  13. rudi says:

    Thanks for the prompt response. I understand now that an Online IP Locator wil not show the correct location of the Office 365 Datacenter entry points. The reason why I looked in to this is because the Microsoft Office 365 Client Performance Analyzer stated
    my DNS servers are in a different region causing the OL clients to connect to the wrong DC’s. This has been corrected now but the tool still states my DNS servers are in a wrong location. Looks like we are connecting to the correct EMEA Center DC anyway.

    At certain moments the latencies are very high. See below. It looks like this is happening when our Firewall/Internet connection is too busy.

    When working in Outlook cached-mode the performance in general is good when there is not a lot of latency but when selecting certain Calendar items Outlook stops responding for minutes.

    I suspect there are mailboxes that have corrupt Free/Busy information or Calendar Items.

    So even when the latency is not high Outlook stops responding for minutes when selecting certain Calendar Items, for example Accepted Appointment Items/Emails.

    I hope Microsoft support can inform me how to detect Calendar/Free Busy corruption in all User Mailboxes instead of just one.

    Trace 1
    5 108 ms 112 ms 99 ms
    6 70 ms 75 ms 79 ms ae6-0.br04sara.versatel.net []
    7 92 ms 106 ms 86 ms microsoft.globalswitch.nl-ix.net [
    8 135 ms 157 ms 175 ms
    9 95 ms 113 ms 115 ms
    10 71 ms 65 ms 57 ms
    11 * * * Request timed out.
    12 92 ms 64 ms 83 ms
    13 102 ms 95 ms 106 ms
    14 101 ms 169 ms 193 ms
    15 126 ms 108 ms 107 ms
    16 104 ms 86 ms 81 ms
    17 130 ms 135 ms 135 ms
    Trace 2
    5 32 ms 9 ms 6 ms
    6 109 ms 60 ms 35 ms ae6-0.br04sara.versatel.net []
    7 47 ms 31 ms 42 ms microsoft.globalswitch.nl-ix.net [
    8 6 ms 6 ms 6 ms
    9 10 ms 8 ms 9 ms mail.consumentenbond.nl []
    10 7 ms 18 ms 35 ms
    11 85 ms 69 ms 39 ms

  14. In trace 1 there you’re already at around 90ms until you’ve hit the Microsoft global network (the 104. addresses are ours) so the latency seems to be on your managed, or ISP link. From the UK (on a home ISP) i can hit that endpoint ( in 56ms
    total. Have a look at the tracert and see where the latency is coming in and engage the appropriate party to investigate. We have peering points in the Netherlands (Amsterdam) so if that’s where the start point is, you should be on our network very quickly.

    As for the hangs, set the reg key in
    http://blogs.technet.com/b/onthewire/archive/2014/03/04/network-perimeter-tcp-idle-session-settings-for-office-365.aspx and see if it helps. Other than that support will be able to help you bottom out the cause.

  15. Tyler says:

    Thanks Paul. This post was very helpful for one of my clients who have a branch in China. Are you aware of webmail access or (portal.office365.com) makes use of the same geolocation technique?

  16. Marek Czarzbon says:

    Part of the SharePoint files are coming from CDN, therefore the DNS resolved country is very important to get nice performance. You will see it if you run the Office 365 Client Performance Analyzer:


  17. Paul Raps says:

    Hi Paul Collinge, the text is very clarifying, thanks!
    Our company has on each site a dual Internet link. Which DNS forwarder do you suggest?
    Or should I ask: Where can I find info about public accessible Microsoft DNS servers?

  18. Hi Paul, we recommend using your ISPs DNS servers which should be local to your egress. Test by pinging outlook.office365.com and ensuring the region returned is the same as the one you’re located in.

  19. John says:

    We use OpenDNS for resolving EMEA datacentres but have found that intermittently it resolves to NA datacentres. Is the fix to use ISP DNS servers only?

  20. Hi John, best bet is to use your ISPs DNS server or ensure you’re using a localised one provided by OpenDns or similar. Most ISPs resolve in the country you’re in which should work well for the above. Another option in your case is to use a conditional
    forwarder to a known local DNS server.

  21. SanT says:

    Has this behavior changed for SPO recently ? My tenant is in US and if i tracert tenantname.sharepoint.com from Singapore, I can see that it hits ae14-0.sg2-96cbe-1b.ntwk.msn.net [] first , which seems to be MS Singapore Datacenter IP.

    1. Yes, we’re moving to an Anycast model for Sharepoint which should improve performance. I’ll update the blog post with the detail when I get chance

  22. Enver says:

    When i do an tracert i will get from America to Dublin and the data is located in Amsterdam. How can i improve this?

    Tracing route to prodnet448-479selectora0003.sharepointonline.com.akadns.net []
    over a maximum of 30 hops:

    1 6 ms 3 ms 4 ms
    2 5 ms 2 ms 4 ms
    3 3 ms 4 ms 3 ms 194-151-190-33.ip.domusmedica.nl []
    4 9 ms 8 ms 8 ms
    5 * * * Request timed out.
    6 15 ms 15 ms 12 ms nl-rt-dc2-ice-ir01.kpn.net []
    7 * * * Request timed out.
    8 33 ms 30 ms 33 ms be-62-0.ibr01.ams.ntwk.msn.net []
    9 34 ms 34 ms 34 ms be-7-0.ibr01.amb.ntwk.msn.net []
    10 35 ms 31 ms 33 ms be-5-0.ibr01.lts.ntwk.msn.net []
    11 40 ms 32 ms 34 ms be-1-0.ibr02.lts.ntwk.msn.net []
    12 30 ms 33 ms 33 ms be-3-0.ibr02.dub30.ntwk.msn.net []
    13 32 ms 32 ms 31 ms ae11-0.db5-96cbe-1b.ntwk.msn.net []
    14 * * * Request timed out.
    15 32 ms 32 ms 32 ms

    Trace complete.

    1. This trace shows peering in Amsterdam and traversal through London to Dublin. The start point cannot be in the USA given the latency, it looks like the Netherlands and is optimal from the Netherlands.

Skip to main content