DNS Errors and Warnings in the Office 365 Portal
The Office 365 portal often offers information regarding the status and health of your services.
The DNS checks are not performed on each administrator logon to the portal. The checks are performed by our Azure DNS infrastructure determining the Source of Authority (SOA) records for the registered domains. This will return the list of name servers responsible for hosting the domain. You can utilize NSLookup to determine the same for your domain.
C:\>nslookup
Default Server: internalDNSServer.internal.contoso.com
Address: 10.10.1.10
> set type=soa
> contoso.com
Server: internalDNSServer.internal.contoso.com
Address: 10.10.1.10
Non-authoritative answer:
contoso.com
primary name server = ns29.domaincontrol.com
responsible mail addr = dns.jomax.net
serial = 2017100901
refresh = 28800 (8 hours)
retry = 7200 (2 hours)
expire = 604800 (7 days)
default TTL = 600 (10 mins)
ns29.domaincontrol.com internet address = 216.69.185.15
ns29.domaincontrol.com AAAA IPv6 address = 2607:f208:206::f
In this example only a single SOA server is returned – ns29.domaincontrol.com. When the list of SOA servers has been determined we will begin a DNS query against each of those servers. The DNS library utilized for this operation allows for a 12 second timeout before the next server in the list is attempted. If all servers fail and timeout – the DNS error will be reported in the portal.
Once a responding SOA server has been determined – the DNS query issued against the server is based off of the domain capabilities of the domain in Office 365. With previous revisions of our management portal administrators could add a domain and select the capabilities. For example, the domain contoso.org will only serve email – therefore that would be the only capability in the portal. With the current portal when a domain is registered it is automatically registered for all services. We do not provide a method to only enable or disable selected services at this time. You can utilize the get-msolDomain command to view the capabilities associated with a given domain.
PS C:\> Get-MsolDomain -DomainName contoso.org| fl
ExtensionData : System.Runtime.Serialization.ExtensionDataObject
Authentication : Managed
Capabilities : Email, OfficeCommunicationsOnline, OrgIdAuthentication, Intune
IsDefault : True
IsInitial : False
Name : contoso.org
RootDomain :
Status : Verified
VerificationMethod : DnsRecord
In this example we will query the SOA server for all records associated with all of the services provided. If the capabilities were just EMAIL for example, we would only query for the email records necessary for the service. Mobile device management and Skype for Business would not be queried even though the records are provided through the portal.
You can observe this health reporting by accessing setup –> Domains.
Your domains will be listed and domains that are currently flagged for issues display a warning symbol and are flagged for possible service issues.
To review the individual issues identified the domain can selected in the previous screen. The next screen displays the individual DNS associated with the domain selected.
With the DNS records displayed we can select DNS Errors detected, click here to view.
With this option selected we will see the individual DNS errors that were detected for the domain selected. Here is a sample for the MX records.
In this example our health logic has queried DNS and determined that the MX record provisioned for your domain is not the MX record found in the DNS registrations.
There are situations where this is perfectly acceptable. The DNS health checking mechanism does not know the specifics of your installation and any customizations that may be present. For example, it is not uncommon in a hybrid configuration to have your autodiscover record pointing to an on premises Exchange environment. This would trigger a health check failure on the CNAME records as autodiscover does not point to the Office 365 service. It is also not uncommon to have inbound mail flow for your MX record point to a solution other than Office 365 – for example a third party gateway device <or> an on premises email environment. This would produce a DNS health check failure on the MX record similar to the errors seen above.
When the health check has found an error it is important that the records be manually reviewed and an understanding of any discrepancies explained. If they are due to customizations the errors can be safely ignored. If they are due to legitimate DNS errors it would be recommended to fix the discrepancies as soon as possible to prevent any forms of service outage.
If you analysis has determined that the DNS errors are benign you can discontinue warning about them by selecting the ignore incorrect dns button. This is found on the same page where the individual DNS record errors are displayed.
If the administrator has selected the ignore incorrect dns option the domain will no longer appear with a warning symbol on the domains page and the status will show setup complete verses possible service issues.
It is important to note that the ignore function is only good for the current administrator session. DNS is evaluated on every administrator logon – therefore the DNS errors may appear on the next logon even if ignored. This is a departure from previous versions of the portal where the ignore function would ignore DNS errors for up to 7 days before the status was reset and tested again.
If at a later time you decide you want to have DNS re-evaluated for any reason you can select the specific domain and utilize the CHECK DNS button to initiate a DNS health check. This will issue an immediate re-evaluation of the DNS records associated with the domain.
With an understanding of your DNS implementation and a review of the service issues identified administrators and make an accurate determination if the errors are safe to ignore or if actionable steps need to be taken.
What happens when I keep getting recurring errors but everything is established to my satisfaction? Unfortunately the only remedy is to ignore the errors in the portal once an understanding of why the domain has been flagged has been established.