This chapter covers the DNS records required to integrate custom domains with Microsoft 365 services, including Exchange Online, Teams, and SharePoint. Proper DNS configuration is essential for email routing, client autodiscovery, and service verification, and it is a core topic in the MS-102 exam under objective 1.1 (Tenant Management). Expect 5-10% of exam questions to involve DNS records, including identification of record types, TTL values, and troubleshooting misconfigurations.
Jump to a section
Think of DNS as the global phonebook for the internet. When you want to call a company, you look up their main number in a phonebook. Similarly, when a client tries to reach a Microsoft 365 service like Exchange Online or Teams, it queries DNS to find the correct server IP address. But it's not just about finding a phone number—it's about knowing which department to contact. In a large company, you might dial a main number and then an extension, or you might have a direct line for billing vs. support. Microsoft 365 uses specific DNS records to route traffic to the right service: MX records for email, SRV records for Teams and Autodiscover, CNAME records for client configuration, and TXT records for domain ownership verification and email security (SPF, DKIM, DMARC). If you misconfigure the phonebook, callers get a busy signal, reach the wrong department, or get disconnected—just as misconfigured DNS records cause email delivery failures, Teams connectivity issues, or domain verification errors. Every DNS record type serves a distinct purpose, and the MS-102 exam expects you to know exactly which record type is needed for each service.
What Are DNS Records and Why Does Microsoft 365 Need Them?
DNS (Domain Name System) translates human-readable domain names (like contoso.com) into IP addresses and other service locators. When you add a custom domain to Microsoft 365, you must prove ownership and configure DNS records so that Microsoft's services can be reached by your users and external systems. Without correct DNS records, email may not flow, clients cannot find Exchange or Teams, and domain ownership verification fails.
Types of DNS Records Used in Microsoft 365
Microsoft 365 uses several record types:
TXT (Text) Records: Used for domain ownership verification and email authentication (SPF, DKIM, DMARC). TXT records store arbitrary text. For verification, Microsoft provides a unique token you add as a TXT record. For SPF, you publish a list of IP addresses allowed to send email for your domain.
MX (Mail Exchange) Records: Direct email to Microsoft 365. The MX record for your domain must point to <tenant>.mail.protection.outlook.com with a priority of 0 (or lower than any other MX record).
CNAME (Canonical Name) Records: Alias one domain name to another. Used for Autodiscover (autodiscover.yourdomain.com -> autodiscover.outlook.com), Skype for Business/Teams (sip.yourdomain.com -> sipdir.online.lync.com), and other client configuration records.
SRV (Service) Records: Specify the host and port for specific services. Used for Teams/Skype for Business Federation (sipfederationtls._tcp.yourdomain.com) and for additional Autodiscover fallback.
A (Address) Records: Map a domain name to an IPv4 address. Rarely used directly for Microsoft 365 services, but may be needed for custom SharePoint or Exchange endpoints if not using CNAMEs.
DNS Record Configuration Steps
Add Custom Domain in Microsoft 365 Admin Center: Navigate to Settings > Domains > Add domain. Enter your domain name (e.g., contoso.com).
Verify Ownership: Microsoft provides a TXT record value (e.g., MS=ms12345678). Add this to your DNS zone. Verification typically takes a few minutes (up to 72 hours depending on DNS propagation).
Configure Service Records: After verification, Microsoft provides a list of required DNS records based on the services you intend to use (Exchange Online, Teams, SharePoint). Add these records to your DNS zone.
Test Configuration: Use Microsoft's online tools or command-line tools like nslookup to verify records are correct.
Exchange Online DNS Records
For Exchange Online, the required records are:
MX Record: Points to <tenant>.mail.protection.outlook.com. Priority is typically 0. Example: contoso.com MX 0 contoso.mail.protection.outlook.com
CNAME for Autodiscover: autodiscover.contoso.com CNAME autodiscover.outlook.com
TXT for SPF: Include all Microsoft 365 IP ranges. The minimal SPF record is: v=spf1 include:spf.protection.outlook.com -all
TXT for DKIM: Microsoft automatically manages DKIM signing, but you may need to publish CNAME records for DKIM key rotation if you enable custom DKIM. Typically two CNAME records: selector1._domainkey.contoso.com CNAME selector1-contoso._domainkey.contoso.onmicrosoft.com and similarly for selector2.
TXT for DMARC: Optional but recommended: v=DMARC1; p=quarantine; rua=mailto:dmarc@contoso.com
Teams and Skype for Business DNS Records
For Teams (which replaces Skype for Business Online), the required records are:
- SRV Record: _sipfederationtls._tcp.contoso.com SRV 100 1 443 sipfed.online.lync.com (for federation)
- CNAME Records:
- sip.contoso.com CNAME sipdir.online.lync.com
- lyncdiscover.contoso.com CNAME webdir.online.lync.com
- Additional CNAME for Teams mobile: meet.contoso.com CNAME meet.lync.com (optional)
SharePoint Online and OneDrive for Business DNS Records
SharePoint and OneDrive typically do not require custom DNS records beyond verification. However, if you configure custom vanity URLs (e.g., sharepoint.contoso.com), you may need CNAME or A records. By default, SharePoint uses https://<tenant>.sharepoint.com.
DNS Record Values and Defaults
TTL (Time to Live): Default is 3600 seconds (1 hour) for most records. Lower TTLs (e.g., 300 seconds) are recommended during migration to allow quick rollback. Microsoft recommends TTL of 1 hour for MX records.
MX Priority: Lower number means higher priority. For Microsoft 365, use priority 0.
SRV Priority and Weight: For Teams federation, priority 100 and weight 1 are standard.
SPF include: Must include spf.protection.outlook.com. Do not exceed 10 DNS lookups (SPF limit).
Verification and Troubleshooting Commands
nslookup: nslookup -type=mx contoso.com checks MX record. nslookup -type=txt contoso.com checks TXT records.
Resolve-DnsName (PowerShell): Resolve-DnsName -Name contoso.com -Type MX
Microsoft Remote Connectivity Analyzer: Web tool to test Autodiscover, MX, and other records.
Exchange Online PowerShell: Get-AcceptedDomain shows verified domains.
How DNS Records Interact with Microsoft 365 Services
When an external sender sends email to user@contoso.com, the sending mail server queries DNS for MX records of contoso.com. The MX record points to the Microsoft 365 inbound connector. The receiving server checks SPF, DKIM, and DMARC using TXT records. For client configuration, Outlook queries autodiscover.contoso.com CNAME to find the Autodiscover endpoint. Teams clients query SRV and CNAME records to locate the SIP and conferencing servers. If any record is missing or incorrect, the corresponding service fails.
Exam-Relevant Details
The MS-102 exam tests your ability to identify which DNS record type is needed for a given scenario. For example, email routing requires an MX record; domain verification requires a TXT record; Autodiscover requires a CNAME; Teams federation requires an SRV record.
Know the exact hostnames: autodiscover.outlook.com, sipdir.online.lync.com, <tenant>.mail.protection.outlook.com.
Understand that SPF records must include include:spf.protection.outlook.com and that -all (hard fail) is recommended.
Be aware that DKIM CNAME records are optional but required if you want Microsoft to sign emails with your custom domain.
Remember that DMARC is optional but recommended for anti-phishing.
TTL values: default 1 hour; lower during migrations.
MX priority: 0 is standard for Microsoft 365.
SRV format: _service._protocol.domain.com TTL class SRV priority weight port target.
Common Pitfalls
Using a CNAME for the root domain (naked domain) is not allowed per DNS standards. Use an A record or a redirect service.
Exceeding the SPF 10-lookup limit can cause email rejection.
Forgetting to update DNS after migrating from on-premises Exchange can cause mail flow issues.
Using the wrong priority for MX records (e.g., 10 instead of 0) might cause email to route elsewhere.
Not waiting for DNS propagation (up to 48-72 hours) before testing.
Summary
DNS records are the foundation of Microsoft 365 service connectivity. The MS-102 exam expects you to know the exact record types, values, and purposes for Exchange Online, Teams, and verification. Master the commands to verify and troubleshoot, and be prepared to identify misconfigurations in scenario-based questions.
Add Custom Domain in Admin Center
Navigate to Microsoft 365 Admin Center > Settings > Domains > Add domain. Enter your custom domain (e.g., contoso.com). Click 'Use this domain'. The system checks if the domain is already in use. If not, you proceed to verification. This step initiates the domain ownership verification process.
Verify Domain Ownership with TXT Record
Microsoft provides a unique TXT record value (e.g., MS=ms12345678). You must add this as a TXT record in your public DNS zone. The record name is typically @ (the root domain) or sometimes a specific host like asuid.contoso.com. After adding, you click 'Verify' in the admin center. DNS propagation may take a few minutes to 72 hours. Verification succeeds when Microsoft can query the TXT record and find the expected value.
Configure Required Service Records
After verification, Microsoft presents a list of recommended DNS records based on the services you plan to use (Exchange Online, Teams, SharePoint). For each service, you add the corresponding MX, CNAME, SRV, or TXT records. For example, for Exchange Online, add MX record pointing to <tenant>.mail.protection.outlook.com with priority 0, and CNAME for autodiscover. For Teams, add SRV and CNAME records as specified. Use the exact hostnames and values provided.
Test DNS Resolution with nslookup
Use command-line tools to verify records are published correctly. For MX: `nslookup -type=mx contoso.com`. For TXT: `nslookup -type=txt contoso.com`. For CNAME: `nslookup -type=cname autodiscover.contoso.com`. For SRV: `nslookup -type=srv _sipfederationtls._tcp.contoso.com`. Ensure the responses match the expected values. TTL should be set appropriately (e.g., 3600 seconds). If records are missing or incorrect, troubleshoot DNS propagation or typographical errors.
Verify Service Health in Microsoft 365
Use Microsoft 365 Admin Center > Health > Service health to check if any services are degraded due to DNS issues. Additionally, use the Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) to test Autodiscover, MX, and other records. For email, send a test message and check headers for SPF/DKIM/DMARC results. For Teams, verify that clients can sign in and communicate. If issues persist, review DNS records again and ensure no conflicting records exist.
Scenario 1: Migrating Email to Exchange Online
A mid-sized company with 500 users is migrating from on-premises Exchange to Exchange Online. The DNS administrator must add MX record pointing to <tenant>.mail.protection.outlook.com with priority 0. However, to avoid email loss during cutover, they set a lower TTL (e.g., 300 seconds) on the existing MX record a few days before migration. On cutover day, they update the MX record and monitor mail flow. A common mistake is forgetting to update the Autodiscover CNAME, causing Outlook clients to keep connecting to the on-premises server. The administrator uses nslookup to verify both MX and CNAME records. They also publish SPF record including both on-premises and Exchange Online IPs to prevent legitimate email from being rejected. After migration, they set TTL back to 3600 seconds.
Scenario 2: Enabling Teams Federation
A global enterprise wants to enable federation with other organizations using Teams. They need to add the SRV record _sipfederationtls._tcp.contoso.com pointing to sipfed.online.lync.com with priority 100 and weight 1. They also add CNAME records for sip.contoso.com and lyncdiscover.contoso.com. Without the SRV record, external federation fails. The administrator uses Resolve-DnsName -Type SRV to confirm. They also ensure that the TXT record for SPF includes include:spf.protection.outlook.com to avoid email authentication failures. A common misconfiguration is using the wrong target hostname (e.g., sipdir.online.lync.com instead of sipfed.online.lync.com).
Scenario 3: Implementing DKIM and DMARC for Phishing Protection
A financial services company must ensure email authenticity to prevent phishing. They enable DKIM signing in Exchange Online and publish two CNAME records for DKIM key rotation (selector1 and selector2). They also publish a DMARC TXT record with policy p=quarantine. Without these records, emails might be flagged as spam by recipients. A common issue is forgetting that DKIM CNAME records must be added for each custom domain, not just the initial onmicrosoft.com domain. The administrator uses Microsoft's DKIM management page to generate the CNAME records and verifies them with nslookup -type=cname selector1._domainkey.contoso.com. They also monitor DMARC reports to ensure legitimate email passes authentication.
What MS-102 Tests on DNS Records (Objective 1.1)
The exam focuses on your ability to identify the correct DNS record type for a given scenario, recognize required record values, and troubleshoot common misconfigurations. Specific sub-objectives include:
Configure DNS records for domain verification (TXT record)
Configure DNS records for Exchange Online (MX, CNAME for Autodiscover, SPF TXT)
Configure DNS records for Teams (SRV, CNAME)
Understand SPF, DKIM, and DMARC requirements
Common Wrong Answers and Why Candidates Choose Them
Using CNAME for the root domain: Candidates often think they can point contoso.com to Microsoft 365 via CNAME, but DNS standards prohibit CNAME at the apex. Instead, they should use an A record (if needed) or rely on MX and TXT records. The exam may present a scenario where a CNAME at the root is proposed; the correct answer is to reject it.
Confusing MX priority: Many choose priority 10 because it's common for backup mail servers. But for Microsoft 365, priority should be 0 to ensure it is the primary mail exchanger. The exam may ask which MX priority is correct.
Selecting SPF include as `spf.protection.outlook.com` vs `include:spf.protection.outlook.com`: The include: prefix is mandatory. Candidates may omit it, thinking the domain alone suffices. The exam tests syntax knowledge.
Thinking DKIM is automatic without any DNS changes: While Microsoft signs emails by default with its own domain, custom domain DKIM requires CNAME records. Candidates may assume no action is needed.
Specific Numbers, Values, and Terms Appearing on the Exam
MX target: <tenant>.mail.protection.outlook.com
Autodiscover CNAME: autodiscover.outlook.com
Teams SRV target: sipfed.online.lync.com
Teams CNAME targets: sipdir.online.lync.com, webdir.online.lync.com
SPF include: include:spf.protection.outlook.com
DKIM CNAME prefix: selector1._domainkey and selector2._domainkey
TTL default: 3600 seconds (1 hour)
MX priority: 0
Edge Cases and Exceptions
If you use a vanity domain for SharePoint (e.g., sharepoint.contoso.com), you may need a CNAME or A record, but this is not commonly tested.
For hybrid deployments, additional records like an on-premises Autodiscover CNAME may be needed.
The exam may ask about DNS records for Mobile Device Management (MDM) – typically CNAME for enterpriseenrollment.contoso.com and enterpriseregistration.contoso.com.
How to Eliminate Wrong Answers
Identify the service: email -> MX, client config -> CNAME, federation -> SRV, verification -> TXT.
Check syntax: SPF must include v=spf1 and include:.
Remember that root domain cannot have CNAME.
Use TTL as a clue: lower TTL during migration is correct; high TTL for stable production.
Focus on these patterns, and you will consistently choose the correct answer.
Domain verification requires a TXT record with the value provided by Microsoft (e.g., MS=ms12345678).
MX record for Exchange Online must point to <tenant>.mail.protection.outlook.com with priority 0.
Autodiscover CNAME must point to autodiscover.outlook.com.
Teams requires an SRV record for federation: _sipfederationtls._tcp.<domain> SRV 100 1 443 sipfed.online.lync.com.
Teams CNAME records: sip.<domain> -> sipdir.online.lync.com; lyncdiscover.<domain> -> webdir.online.lync.com.
SPF record must include 'include:spf.protection.outlook.com' and should end with -all (hard fail).
DKIM for custom domains requires two CNAME records (selector1 and selector2).
DMARC is optional but recommended; uses TXT record with policy (p=none, quarantine, or reject).
Default TTL is 3600 seconds; lower TTL (e.g., 300) during migrations.
Root domain cannot have CNAME record; use A/AAAA or TXT/MX only.
These come up on the exam all the time. Here's how to tell them apart.
MX Record for Email Routing
Directs email messages to the mail server (Microsoft 365).
Uses target: <tenant>.mail.protection.outlook.com.
Priority value determines preference (0 recommended for primary).
Only one MX record should be primary; others can be backup.
Changes require DNS propagation; TTL should be set appropriately.
CNAME for Autodiscover
Maps a subdomain (autodiscover.yourdomain.com) to Microsoft's Autodiscover service.
Target: autodiscover.outlook.com.
No priority, but multiple CNAMEs can exist for different hosts.
Must match exactly; Outlook uses it to configure client settings automatically.
Missing or incorrect CNAME causes Outlook to prompt for manual configuration.
Mistake
You can use a CNAME record for the root domain (e.g., contoso.com) to point to Microsoft 365.
Correct
DNS standards (RFC 1912) prohibit CNAME records at the zone apex. For the root domain, you must use A or AAAA records, or rely on MX and TXT records. Microsoft 365 does not require an A record for the root; it uses MX for email and TXT for verification.
Mistake
SPF record for Microsoft 365 is simply 'spf.protection.outlook.com'.
Correct
The correct SPF record must include the `include:` mechanism, e.g., `v=spf1 include:spf.protection.outlook.com -all`. Without `include:`, the record is invalid. Additionally, you must include any other mail sources (e.g., on-premises servers) within the 10-lookup limit.
Mistake
DKIM is automatically configured for custom domains without any DNS changes.
Correct
While Microsoft signs outbound email with its own domain (onmicrosoft.com) by default, custom domain DKIM requires you to publish two CNAME records (selector1 and selector2) in your DNS. Without these, emails from your custom domain will not be DKIM-signed with your domain.
Mistake
MX record priority should be set to 10 for Microsoft 365.
Correct
Microsoft 365 recommends MX priority 0 to ensure it is the primary mail exchanger. Priority 10 would make it a backup, which could cause email to be delivered elsewhere first (e.g., on-premises) if another MX record with lower priority exists.
Mistake
CNAME records for Teams must point to 'sipfed.online.lync.com' for all purposes.
Correct
CNAME records for Teams client connectivity point to `sipdir.online.lync.com` (SIP) and `webdir.online.lync.com` (web services). The SRV record for federation points to `sipfed.online.lync.com`. Mixing these up causes connectivity failures.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The MX record should point to `<tenant>.mail.protection.outlook.com` with priority 0. For example, if your tenant is contoso.onmicrosoft.com, the MX record target is `contoso.mail.protection.outlook.com`. The priority ensures email is routed directly to Microsoft 365. Always verify with nslookup after adding.
By default, SharePoint Online uses the tenant domain (e.g., contoso.sharepoint.com). No additional DNS records are required. However, if you configure a vanity domain (e.g., sharepoint.contoso.com), you need a CNAME record pointing to contoso.sharepoint.com. This is not commonly tested on MS-102.
SPF (Sender Policy Framework) uses a TXT record to list authorized sending IPs. DKIM (DomainKeys Identified Mail) uses cryptographic signatures verified via DNS CNAME records. DMARC (Domain-based Message Authentication, Reporting & Conformance) uses a TXT record to tell receivers how to handle emails that fail SPF or DKIM. For Microsoft 365, you must configure SPF; DKIM and DMARC are optional but recommended.
DNS propagation depends on the TTL set on the records and the caching behavior of DNS resolvers. Typically, changes propagate within a few minutes to a few hours, but Microsoft states it can take up to 72 hours. For quick verification, set TTL to 300 seconds during migration, then increase to 3600 seconds after confirmation.
No. DNS standards (RFC 1912) prohibit CNAME records at the zone apex because the root domain already has SOA and NS records. If you need to point the root domain to a service, use an A record (if you have a static IP) or a redirect service. For Microsoft 365, the root domain only needs MX and TXT records for email and verification.
For Teams federation, you need an SRV record: `_sipfederationtls._tcp.<domain>` with target `sipfed.online.lync.com`, priority 100, weight 1, port 443. You also need CNAME records for `sip.<domain>` pointing to `sipdir.online.lync.com` and `lyncdiscover.<domain>` pointing to `webdir.online.lync.com`. These enable external users to discover your Teams services.
The minimal SPF record is: `v=spf1 include:spf.protection.outlook.com -all`. The `include:` mechanism adds Microsoft's sending IPs. The `-all` at the end means hard fail (reject email from unauthorized sources). If you have other mail sources (e.g., third-party services), add them using `include:` statements, but keep total DNS lookups under 10 to avoid SPF permerror.
You've just covered DNS Records for Microsoft 365 Services — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?