Outlook.com: Leveraging O365’s Geo-DNS for Outlook Accounts

If you’ve ever used Office 365, then you’ll be aware of how the Geo-DNS feature and protocol proxy can benefit users, when connecting to their mailboxes from different regions than where the tenant resides. I don’t want to rehash what’s already been written, so if you’re not familiar with Geo-DNS, I suggest perusing this blog post for more information on it.

O.k., so, what matters to this story is that my account in Outlook.com was once a [email protected] account that got split when Microsoft merged [email protected] into Office 365. I’ve lost the Office 365 account but the Live account stuck around – and I’m glad that it did because all of my purchases were associated with it.

So, that being said, the account (and, thus, the mailbox) has been around for a hot minute. I don’t know if this will work with new Outlook.com accounts but I can’t fathom any reason why it shouldn’t.

First, the problem.

The issue with Outlook.com is pretty straightforward. A DNS query from any server outside of North America will provide an group of IP addresses, like this:

:~$ dig a outlook.com

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> a outlook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1787
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 65494
;outlook.com.			IN	A

outlook.com.		300	IN	A
outlook.com.		300	IN	A
outlook.com.		300	IN	A
outlook.com.		300	IN	A
outlook.com.		300	IN	A
outlook.com.		300	IN	A
outlook.com.		300	IN	A
outlook.com.		300	IN	A

;; Query time: 218 msec
;; WHEN: Thu Dec 27 18:15:17 CET 2018
;; MSG SIZE  rcvd: 168

If we trace the troute to the first IP address, we can see that we traverse from Stockholm to Amsterdam to London to New York City to Washington to Chicago to… (first two hops removed for privacy):

:~$ traceroute --resolve-hostnames
traceroute to (, 64 hops max
  1 (_gateway)  87,450ms  58,492ms  55,662ms 
  2 (  54,839ms  64,758ms  59,640ms 
  3 (as8075-10g-sk1.sthix.net)  52,795ms  53,058ms  55,475ms 
  4 (ae1-0.sto-96cbe-1b.ntwk.msn.net)  53,841ms  53,710ms  50,792ms 
  5 (be-8-0.ibr01.ams.ntwk.msn.net)  190,862ms  188,583ms  290,228ms 
  6 (be-7-0.ibr01.amb.ntwk.msn.net)  186,894ms  189,178ms  364,440ms 
  7 (be-5-0.ibr01.lts.ntwk.msn.net)  184,531ms  188,188ms  322,957ms 
  8 (be-2-0.ibr01.lon30.ntwk.msn.net)  237,432ms  186,584ms  367,246ms 
  9 (be-11-0.ibr01.nyc30.ntwk.msn.net)  187,837ms  359,796ms  188,780ms 
 10 (be-7-0.ibr01.was02.ntwk.msn.net)  186,431ms  372,950ms  183,982ms 
 11 (be-3-0.ibr01.ch2.ntwk.msn.net)  185,136ms  372,724ms  185,883ms 
 12 (be-6-0.ibr01.cnr02.dsm05.ntwk.msn.net)  188,245ms  187,203ms  186,946ms 
 13 (ae121-0.icr03.dsm05.ntwk.msn.net)  187,622ms  187,722ms  188,690ms

All of these hops are wholly unnecessary. After all, if I look at a message header from a mail I received, I can see that my mailbox is in Helsinki (and, even though it’s an Outlook.com account, serviced in the same forests as Office 365):


This, of course, also meant that I was landing on a Cafe in North America, being protocol proxied from North America to Helsinki, and then the response would traverse back the reverse path to me. As you can tell from the latency, it wasn’t a very fast response.

What was the resolution?

Since I’m using EWS in Evolution on Ubuntu 180.04LTS, I simply changed the server name from “outlook.com” to “outlook.office365.com”. This means that I leverage Geo-DNS and this will land my requests on front-end server within Europe, which would then protocol-proxy the request to my mailbox hosted (currently) in Helsinki.

I can’t promise that this will work for you but it’s definitely worth a shot; especially, to avoid network degredation, by not having your traffic routed through North America.

It’s not much, I’m aware, but it’s a small piece of help that I hope might benefit someone, some day.

Happy Holidays!