The use of Office 365 services depends on proper DNS name resolution, especially when running a hybrid configuration. Without a non-functional DNS name resolution, the end user will not be able to connect to Office 365 service from within the company network or from the Internet.
Locating of Office 365 services is based on the user's logon name. This logon name (users principal name) is identical to the primary email address. The reasons for keeping the primary email address and the user logon name the same has been covered in detail in a blog post by Joe Palichario.
In my example, I use a logon name following the scheme firstname.lastname@example.org. The Federation Server (ADFS) uses the host name adfs.sedna-ltd.com.
A so-called Split-DNS setup describes a way of DNS operation where a DNS zone is maintained in an internal and an external configuration. The internal DNS server runs on internal computer systems accessible from within the company network only. The external DNS server runs either on an internal computer system accessible from the Internet or is provided by an Internet DNS Provider responsible for hosting the external DNS zone.
Client computers querying the internal DNS server from internal networks will receive internal IP-addresses whereas client computers querying the external DNS server from the Internet will receive external or public IP-addresses for the same target hosts. A hybrid setup with Office 365 requires such a Split-DNS setup. When using Office 365 in a cloud-only setup, you only rely on an external DNS zone and do not require a Split-DNS setup.
The client computer connected to the company network queries the internal DNS server to resolve the IP address for the host name sedna-ltd.com and receives the ADFS server’s internal IP address. An internal client trying to access Office 365 resources needs to be authenticated by ADFS and is redirected to the federation host adfs.sedna-ltd.com.
The client connects to the internal IP address of the ADFS server, is authenticated and, if authorized, redirected to the targeted Office 365 service.
An external client trying to access Office 365 resources needs to be authenticated by ADFS as well but is redirected to the ADFS proxy server located in the perimeter network. The internal ADFS server is supposed never to be accessible from the Internet directly.
The client computer connected to the Internet queries the external DNS server to resolve the IP address for the host name sedna-ltd.com and receives the ADFS proxy server’s external IP address.
The external client connects to the public IP address of the ADFS proxy server which proxies the authentication request to the internal ADFS server. The external client is authenticated and, if authorized, redirected to the targeted Office 365 service.
Besides custom IP addresses both DNS servers must be able to resolve all Office 365 service addresses that are domain specific. Such service addresses include Exchange, Skype for Business, and client management related addresses. These addresses must be configured as additional DNS records on the internal and external DNS server. The required DNS resource records types and target addresses are provided in the Office 365 Administrative Center for each registered custom domain.
The following screenshot shows an example of the required DNS resource records for sedna-ltd.com domain.
Each custom domain registered with Office 365 that it used for user authentication and mail flow must have the appropriate DNS records added to its DNS zone configuration.
Even though that, from a technical standpoint, it is possible to configure different names, you must keep in mind that you do not control any back-end processes depending on those names. Office 365 is a Software-as-a-Service offering where you should follow the recommendations to keep troubleshooting to a minimum. Additionally, the end user experience can be pretty distracting, as some logon page labels ask for a logon name while others ask for an email address. End users do not know that both pages ask for the same information. Having such a custom configuration for logon names in place does not provide any additional security. If you want to gain a higher level of security, you should implement Multi-Factor Authentication and Conditional Access.