Plan the DNS record requirements for a custom domain
When you set up a custom domain in Microsoft 365, you must configure the DNS (Domain Name System) records for proper domain management and email delivery. The specific DNS records you must add depend on the services you want to use with your custom domain in Microsoft 365.
After the Microsoft 365 setup wizard verifies the organization owns the custom domain, the administrator should add other DNS records to the custom DNS zone. These records should enable the organization’s clients to locate Microsoft 365 services. Each DNS zone can contain several different DNS record types that provide differing name resolution services.
- If the organization hosts its own external DNS server, then a DNS administrator should add the necessary DNS records to provide client connectivity to Microsoft 365 services.
- If a DNS provider hosts the organization’s DNS zone, then administrators should add the necessary DNS records through the appropriate management console that the DNS provider created. Some DNS providers, such as GoDaddy, provide automated DNS record configuration for Microsoft 365. This design saves organizations from having to manually create their DNS records for Microsoft 365. Organizations may also select the option to have Microsoft 365 configure and host the DNS records.
If you purchased a custom domain from a third-party hosting provider, you can connect it to Microsoft 365 by updating the DNS records in your registrar’s account. Once you add the domain to Microsoft 365, it remains registered with the host that you purchased it from. However, Microsoft 365 can use it for your email addresses (like user@yourdomain.com) and other services.
If you don't add a custom domain, people in your organization must use the onmicrosoft.com domain for their email addresses until you do.
Tip
You should add your custom domain before you add users, so that you don't have to set them up twice.
If you previously created users and would like to change their domain, follow the steps described in Change your email address to use your custom domain using the Microsoft 365 admin center.
The following sections examine each of the DNS records used by Microsoft 365.
External DNS records required for Microsoft 365 (core services)
Microsoft 365 requires the TXT record, which proves that you own the domain. The system requires this record for all customers.
Microsoft 365 only requires the CNAME record for customers in China who use 21Vianet to operate Microsoft 365 (21Vianet is the largest carrier-neutral Internet data center services provider in China). The CNAME record ensures that Microsoft 365 can direct workstations to authenticate with the appropriate identity platform.
| DNS record | Purpose | Value to use | Applies to |
|---|---|---|---|
| TXT (Domain verification) |
Used by Microsoft 365 to verify that you own your domain. It doesn't affect anything else. | Host: @ (or, for some DNS hosting providers, your domain name) TXT Value: [A text string provided by Microsoft 365] The Microsoft 365 domain setup wizard provides the values that you use to create this record. |
All customers |
| CNAME (Suite) |
Used by Microsoft 365 to direct authentication to the correct identity platform. This CNAME record only applies to Microsoft 365 operated by 21Vianet in China. If this record is present and 21Vianet doesn't operate the organization's Microsoft 365 plan, users in the organization's custom domain receive an error message stating that "[custom domain] isn't in our system." As a result, the users can't activate their Microsoft 365 license. |
Alias: msoid Target: clientconfig.partner.microsoftonline-p.net.cn |
21Vianet customers only in China |
External DNS records required for email in Microsoft 365 (Exchange Online)
Email in Microsoft 365 requires several different records. Every Microsoft 365 customer should use the following DNS records:
Autodiscover. This record allows client computers to automatically find Exchange and configure the client properly.
MX. This record tells other mail systems where to send email for the company's domain.
Note
When an organization changes its email to Microsoft 365, by updating its domain's MX record, ALL email sent to that domain starts coming to Microsoft 365.
Sender policy framework (SPF). SPF records are actually TXT records used by recipient email systems to validate whether the server sending an organization's email is one that the company approves. This record helps prevent problems such as email spoofing and phishing.
Email customers who use Exchange federation also need the CNAME and TXT records listed at the bottom of the table.
| DNS record | Purpose | Value to use |
|---|---|---|
| CNAME (Exchange Online) |
Helps Outlook clients easily connect to the Exchange Online service by using the Autodiscover service. Autodiscover automatically finds the correct Exchange Server host and configures Outlook for users. | Alias: Autodiscover Target: autodiscover.outlook.com |
| MX (Exchange Online) |
Sends incoming mail for an organization's domain to the Exchange Online service in Microsoft 365. Once an organization's email is flowing to Exchange Online, the company should remove the MX records that are pointing to its old system. |
Domain: For example, contoso.com Target email server: [MX token].mail.protection.outlook.com Time To Live (TTL) Value: 3600 Preference/Priority: Lower than any other MX records. This value ensures the system delivers mail to Exchange Online. For example, 1 or 'low.' Find your [MX token] by following these steps: - Sign-in to Microsoft 365, go to the Microsoft 365 admin center, and then select Domains. - In the Action column for your domain, select Fix issues. - In the MX records section, select What do I fix? Follow the directions on this page to update your MX record: What is MX priority? |
| SPF (TXT) (Exchange Online) |
Helps an organization prevent other people from using its domain to send spam or other malicious email. Sender policy framework (SPF) records identify the servers that an organization authorizes to send email from its domain. | External DNS records required for SPF. |
| TXT (Exchange federation) |
Used for Exchange federation for hybrid deployments. | TXT record 1: For example, contoso.com and associated custom-generated, domain-proof hash text (for example, Y96nu89138789315669824) TXT record 2: For example, exchangedelegation.contoso.com and associated custom-generated, domain-proof hash text (for example, Y3259071352452626169) |
| CNAME (Exchange federation) |
Helps Outlook clients easily connect to the Exchange Online service by using the Autodiscover service when an organization uses Exchange federation. Autodiscover automatically finds the correct Exchange Server host and configures Outlook for your users. | Alias: For example, Autodiscover.service.contoso.com Target: autodiscover.outlook.com |
External DNS records required for Microsoft Teams
An organization must take specific steps when it uses Microsoft 365 URLs and IP address ranges to ensure it correctly configured its network.
These DNS records apply only to tenants in Teams-only mode. For hybrid tenants, see DNS implications for on-premises organizations that become hybrid.
| DNS record | Purpose | Value to use |
|---|---|---|
| SRV (Federation) |
This record enables an organization's Microsoft 365 domain to share instant messaging (IM) features with external clients by enabling SIP federation. | Domain: [domain] Service: sipfederationtls Protocol: TCP Priority: 100 Weight: 1 Port: 5061 Target: sipfed.online.lync.com If an organization's firewall or proxy server blocks SRV lookups on an external DNS, it should add this SRV record to the internal DNS record. |
| SRV (SIP) |
An organization may need this record if it has a Teams-only tenant that uses Skype for Business Online phones for Teams. | Domain: [domain] Service: sip Protocol: TLS Priority: 100 Weight: 1 Port: 443 Target: sipdir.online.lync.com |
| CNAME (Lyncdiscover) |
Teams-only tenants require this record to support PowerShell cmdlets that still use Skype for Business Online infrastructure for management. | Alias: lyncdiscover.[domain] Target: webdir.online.lync.com |
External DNS records required for Microsoft 365 Single Sign-on
| DNS record | Purpose | Value to use |
|---|---|---|
| CNAME | This record is used to verify domain ownership and configure custom domains. It typically points to a specific value or token provided by Microsoft. The CNAME record is used for domain verification and to direct traffic to the appropriate Microsoft 365 services. | Name/Host: The specific name or alias, such as "autodiscover" or "msoid." Target: The target domain or hostname provided by Microsoft. |
External DNS records required for Sender policy framework (SPF)
SPF records are TXT records that help prevent other people from using an organization's domain to send spam or other malicious email. SPF records identify the servers that an organization authorizes to send email from its domain.
Sender policy framework (SPF) helps prevent spoofing, but there are spoofing techniques that SPF can't protect against. To protect against these techniques, once an organization sets up SPF, it should configure DKIM and DMARC for Microsoft 365. To get started, see Use DKIM to validate outbound email sent from your domain in Microsoft 365 and Use DMARC to validate email in Microsoft 365.
An organization can only have one SPF record. In other words, it can only have one TXT record that defines SPF for its domain. That single record can have a few different inclusions, but the total DNS lookups that result can't be more than 10. This design helps prevent denial of service attacks. See the table and other examples in the following sections to help you create or update the right SPF record values for your environment.
Structure of an SPF record
An SPF record contains the following parts:
- the declaration that it's an SPF record
- the domains
- IP addresses that should be sending email
- an enforcement rule
Here's an example of a common SPF record for Microsoft 365 when you only use Exchange Online email:
TXT Name @ Values: v=spf1 include:spf.protection.outlook.com -all
An email system that receives an email from an organization's domain looks at the SPF record. If the email server that sent the message was a Microsoft 365 server, the email system accepts the message. However, if the server that sent the message was an organization's old mail system or a malicious system on the Internet, the SPF check may fail and the system doesn't deliver the message. Checks like this help to prevent spoofing and phishing messages.
Choose the correct SPF record structure
Sometimes an organization doesn't use just Exchange Online email for Microsoft 365 (for example, when it uses email originating from SharePoint Online as well). In this scenario, the organization must use the following table to determine what to include in the value of the record.
Caution
If you have a complicated scenario that includes, for example, edge email servers for managing email traffic across your firewall, you'll have a more detailed SPF record to set up. In this situation, Microsoft recommends that you read: Set up SPF records in Microsoft 365 to help prevent spoofing. You can also learn much more about how SPF works with Microsoft 365 by reading How Microsoft 365 uses Sender Policy Framework (SPF) to help prevent spoofing.
| Number | If you're using... | Purpose | Add these includes |
|---|---|---|---|
| 1 | All email systems (required) | All SPF records start with this value. | v=spf1 |
| 2 | Exchange Online (common) | Use with just Exchange Online. | include:spf.protection.outlook.com |
| 3 | Third-party email system (less common) | include: [email system like mail.contoso.com] | |
| 4 | On-premises mail system (less common) | Use if you're using Exchange Online Protection or Exchange Online plus another mail system. | ip4: [0.0.0.0] ip6: [: : ] include: [mail.contoso.com] The value in brackets should be other mail systems that send email for your domain. |
| 5 | All email systems (required) | -all |