en-US/about_Office365DnsChecker.Help.txt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
TOPIC
    about_Office365DnsChecker
     
SHORT DESCRIPTION
    Office365DnsChecker will validate that a domain's Office 365 DNS records
    are all complete and correct.
     
LONG DESCRIPTION
    Office365DnsChecker will check one or more domains, to make sure that their
    current DNS records are set up correctly for Office 365.
 
    You can check all applicable Office 365 DNS records at once with the cmdlet
    Test-Office365DnsRecords.
 
    The above cmdlet works by calling these three cmdlets, which can be used to
    test Office 365's three major services independently:
        1. Test-AzureADRecords
        2. Test-ExchangeOnlineRecords
        3. Test-TeamsRecords
         
    Finally, the above three cmdlets themselves call the following cmdlets. To
    test a single DNS record on its own, use one of these:
        1. To test Azure Active Directory's client configuration record:
            Cmdlet = Test-AzureADClientConfigurationRecord
            Name = msoid
            Type = CNAME
            Target = clientconfig.microsoftonline-p.net.
             
        2. Azure Active Directory's enterprise enrollment record:
            Cmdlet = Test-AzureADEnterpriseEnrollmentRecord
            Name = enterpriseenrollment
            Type = CNAME
            Target = enterpriseenrollment.manage.microsoft.com.
             
        3. Azure Active Directory's enterprise registration record:
            Cmdlet = Test-AzureADEnterpriseRegistrationRecord
            Name = enterpriseregistration
            Type = CNAME
            Target = enterpriseregistration.windows.net.
         
        4. Exchange Online's Autodiscover CNAME record:
            Cmdlet = Test-ExchangeOnlineAutodiscoverRecord
            Name = autodiscover
            Type = CNAME
            Target = autodiscover.outlook.com.
         
        5. The absence of any Autodiscover service records. This type of DNS
           record is not compatible with Exchange Online.
            Cmdlet = Test-ExchangeOnlineAutodiscoverRecord
            Name = _autodiscover._tcp
            Type = SRV
         
        6. Exchange Online's two DKIM records:
            Cmdlet = Test-ExchangeOnlineDkimRecords
            Names = selector1._domainkey and selector2._domainkey
            Types = CNAME
            Targets = (may vary, see below)
             
            The target names will vary depending on whether or not the domain
            name has any hyphens or special characters, and depending on the
            CSP name assigned by whomever originally provisioned this tenant.
            To get your exact value, consult the Exchange Admin Center's DKIM
            page, or use the *-DkimSigningConfig cmdlets in Exchange Online.
             
            For illustrative purposes, the two CNAME records' targets for the
            domain contoso.com would probably be:
                1. selector1-contoso-com._domainkey.contoso.onmicrosoft.com
                2. selector2-contoso-com._domainkey.contoso.onmicrosoft.com
             
            As this value can be somewhat unpredictable, this check will only
            verify that the CNAMEs' targets begin with "selector1._domainkey"
            or "selector2._domainkey", and they end with ".onmicrosoft.com".
             
        7. Exchange Online's mail exchanger record.
            Cmdlet = Test-ExchangeOnlineMxRecord
            Name = (none)
            Type = MX
             
            The target's name will vary, depending on whether or not the domain
            name has any hyphens or special characters in it. To find out your
            exact value, consult the Microsoft 365 Admin Center's Domains page.
             
            For illustrative purposes, the MX record for the domain contoso.com
            would probably be "contoso-com.mail.protection.outlook.com."
             
            As this value can be somewhat unpredictable, this check will only
            verify that there is exactly one MX record, and that is ends with
            ".mail.protection.outlook.com."
             
            If there are no MX records present, or if there are additional ones
            in addition to the correct MX record, then that will cause an error
            to be printed. However, if every MX record is incorrect, then this
            will only show a warning: some organizations prefer to use a third-
            party spam filtering service in front of Exchange Online, so the MX
            records would intentionally be incorrect and should not be changed.
             
        8. Exchange Online's Sender ID record, if present.
            Cmdlet = Test-ExchangeOnlineSenderIdRecord
            Name = @
            Type = TXT
            Value = Anything that starts with "spf2.0" and contains the token
                     "include:spf.protection.outlook.com". Additionally, that
                     token MUST NOT be preceded by -, ~, or ?.
 
                     A redirect modifier may be used in the Sender ID record,
                     but it will not be evaluated by this cmdlet.
             
            Sender ID never really got off the ground and is considered to be
            obsolete. A missing Sender ID record will not generate an error,
            but a malformed one will.
 
        9. Exchange Online's SPF record.
            Cmdlet = Test-ExchangeOnlineSpfRecord
            Name = @
            Type = TXT (not SPF!)
            Value = Anything that starts with "v=spf1" and contains the token
                     "include:spf.protection.outlook.com". Additionally, that
                     token MUST NOT be preceded by -, ~, or ?.
 
                     A redirect modifier may be used in the SPF record, but it
                     will not be evaluated by this cmdlet.
         
        The remaining checks say they are for Microsoft Teams, but they apply
        equally to Skype for Business Online. Please note that some of these
        records may intentionally be incorrect if the organization is using a
        Lync Server or Skype for Business Server deployment on-premises.
 
        10. Microsoft Teams' autodiscover record.
            Cmdlet = Test-TeamsAutodiscoverRecord
            Name = lyncdiscover
            Type = CNAME
            Target = webdir.online.lync.com.
             
        11. Microsoft Teams' SIP record.
            Cmdlet = Test-TeamsSipCnameRecord
            Name = sip
            Type = CNAME
            Target = sipdir.online.lync.com.
             
        12. Microsoft Teams' SIP-over-TLS service record.
            Cmdlet = Test-TeamsSipSrvRecord
            Name = _sip._tls
            Type = SRV
            Target = sipdir.online.lync.com.
            Port = 443
             
            The priority and weight may be any value, provided this SRV record
            is always ranked first.
             
        13. Microsoft Teams' SIP federation service record.
            Cmdlet = Test-TeamsSipFederationSrvRecord
            Name = _sipfederationtls._tcp
            Type = SRV
            Target = sipfed.online.lync.com.
            Port = 5061
             
            The priority and weight may be any value, provided this SRV record
            is always ranked first.
     
IDENTIFYING PROBLEMS
    When you run one of this module's commands, the corresponding DNS records
    are retrieved and evaluated. In case of an incorrect record, a warning or
    an error may be printed to the screen, telling you which records are wrong
    or missing.
     
    If an error is printed, you can retrieve the error object through the $error
    automatic variable, just like PowerShell supports normally:
     
    PS C:\> $error[0]
     
HOW TO RESOLVE PROBLEMS
    In addition, basic steps to resolving the error may be available through the
    information pipeline. You can make this information visible by regular means
    such as adding -InformationAction Continue, setting $InformationPreference,
    or redirecting the information pipeline (six).
     
    PS C:\> Test-Office365DnsRecords contoso.com -InformationAction Continue
     
    PS C:\> Test-Office365DnsRecords contoso.com 6> howtofixcontoso.txt
     
    While these one- or two-sentence tips may be useful for giving Office 365
    administrators some idea on how to fix any DNS problems, you should still
    consult the Microsoft 365 Admin Center's domain page, which will tell you
    exactly how to fix your DNS records for common scenarios.
     
    In some cases, DNS records may intentionally be incorrect -- for example,
    if you have a third-party spam filter sitting in front of Exchange Online
    that requires custom MX records; or, if you have an on-premises Skype for
    Business Server that requires your Teams-/Skype-related DNS CNAME records
    to be incorrect intentionally. Please consult your IT department or your
    local MCSE to make sure that following this module's generic advice won't
    interrupt your company's operations.
     
PREREQUISITES FOR NON-WINDOWS SYSTEMS
    The code examples used in this module's documentation show a Windows C:\>
    prompt. However, this module works equally well on all operating systems
    supported by PowerShell 5.1, PowerShell Core 6, and PowerShell 7.
     
    On Windows, this module relies on the DnsClient module to perform lookups,
    even on Core editions of PowerShell.
     
    However, this module is only available on Windows systems. On macOS and
    Linux, the external command dig (i.e., the domain information groper) is
    used to perform DNS lookups. While this is included in macOS as of late,
    Linux users will need to ensure that it is installed either manually, or
    from your distribution's package manager.
 
OTHER NOTES
    It is recommended to sign your zone with DNSSEC, if only so DKIM validators
    see that your public key is secure instead of unprotected. However, DNSSEC
    validation is beyond the scope of this tool.
     
EXAMPLES
    PS C:\> Test-Office365DnsRecords "contoso.com"
     
    PS C:\> Get-AcceptedDomain | Test-Office365DnsRecords
     
KEYWORDS
    Some keywords that you might use to search for this module include:
     
        Office 365, DNS, CNAME, SRV, service, TXT, text, RR;
        Azure AD, AAD, join, hybrid join, registered, client configuration,
        msoid, enterprise enrollment, enterprise registration;
        Exchange Online, SPF, Sender ID, DKIM, DomainKeys, Autodiscover,
        Outlook, Anywhere, ActiveSync, EAS, EWS, MX record, mail exchanger;
        Microsoft Teams, Teams, Skype for Business, Skype for Business Online,
        Lync, Lync Online, SIP, federation, SIPFederationTLS, TCP, TLS,
        LyncDiscover.
     
SEE ALSO
    Test-Office365DnsRecords