Getting Microsoft 365 working with your custom domain is not just about clicking "Add domain" in the admin portal. You need to publish a specific set of DNS records at your registrar or hosting provider, and if any one of them is wrong or missing, you will deal with bounced email, broken Outlook profiles, or failed Teams federation. This guide covers every record Microsoft 365 needs, why each one matters, exactly where to add it, and how to confirm everything is working before you cut over live mail traffic.
What DNS Records Microsoft 365 Requires
When you add a custom domain to Microsoft 365, the setup wizard in the admin portal lists the records you need to create. There are six categories of records across three services: email (Exchange Online), desktop client autoconfiguration (Autodiscover), and Skype for Business / Teams federation. Here is the full set:
- Domain ownership TXT record - proves you control the domain before Microsoft activates anything
- MX record - routes inbound email to Exchange Online
- SPF TXT record - authorizes Microsoft servers to send mail on your behalf
- DKIM CNAME records - two records that allow Exchange Online to sign outbound messages
- Autodiscover CNAME - lets Outlook, iOS Mail, and Android Mail configure themselves automatically
- Teams / Skype SRV records - two SRV records for federation and SIP communication
- DMARC TXT record - not strictly required by Microsoft, but essential for deliverability and spoofing protection
Step 1: Find Your Exact Record Values in the Admin Portal
Every tenant gets unique record values. Do not copy values from another company's guide or a blog post — the MX hostname and DKIM CNAME targets are specific to your tenant. Log in to admin.microsoft.com, go to Settings > Domains, click your domain name, then click DNS records. You will see a table with every record Microsoft expects. Keep this tab open while you work in your DNS provider's control panel.
Step 2: Add the Domain Verification TXT Record
Microsoft will not activate your domain until you prove ownership. The verification record looks like this:
The MS=ms value in your portal will be different. Log in to your DNS provider, create a new TXT record at the root of your domain (represented as @ at most registrars), paste the value, and save. Then return to the Microsoft admin portal and click Verify. If verification fails, wait five minutes and try again — some registrars take a moment to publish new records.
Step 3: Add the MX Record
This is the most critical record. Once you change your MX, all inbound email flows to Exchange Online. Get this wrong and mail bounces.
The actual target hostname in your portal will follow the pattern yourdomain-com.mail.protection.outlook.com with hyphens replacing dots in your domain name. Set the priority to 0 (highest priority). If you have existing MX records pointing to another mail server, delete them after adding the Microsoft 365 one — do not leave two competing MX records in place.
If you are migrating from an existing mail server and need zero-downtime cutover, keep the old MX in place until you have migrated all mailboxes, then delete it and lower the TTL of the new MX afterward.
Step 4: Add the SPF Record
SPF tells receiving mail servers that Microsoft's IP ranges are allowed to send email for your domain. You can only have one SPF TXT record at the root of your domain. If you already have an SPF record (for example from Google Workspace or a marketing platform), you need to merge them rather than create a second record.
If you also send from a third-party service like Mailchimp or SendGrid, the merged record would look like:
Keep the number of include mechanisms below ten or SPF lookups will exceed the DNS query limit and receivers will treat the record as invalid.
Step 5: Enable and Add DKIM CNAME Records
DKIM adds a cryptographic signature to every outbound message. Microsoft 365 handles key generation, but you need to publish two CNAME records that point to Microsoft's signing infrastructure, then enable DKIM in the Defender portal.
After adding both CNAME records, go to security.microsoft.com, navigate to Email and Collaboration > Policies and Rules > Threat Policies > Email Authentication Settings > DKIM, select your domain, and toggle DKIM signing on. Microsoft will verify the CNAMEs are resolving before it activates signing. If you get an error, wait 30 minutes for the CNAMEs to propagate and try again.
Step 6: Add the Autodiscover CNAME
Autodiscover allows Outlook and mobile mail clients to automatically discover mailbox settings — server names, ports, and authentication methods — without users having to enter anything manually. Without it, users will either fail to set up Outlook or have to enter settings by hand.
This record is the same for every Microsoft 365 tenant. Some DNS providers require you to enter the full hostname including the domain (autodiscover.yourdomain.com) in the Name field rather than just the subdomain — check your provider's documentation if the record saves incorrectly.
Step 7: Add SRV Records for Teams and Skype
If your organization uses Microsoft Teams or Skype for Business, two SRV records enable federation with external organizations and SIP authentication for desk phones and compatible hardware.
SRV records trip up a lot of registrars because the Name field format varies. Some providers want just the service and protocol combined as the hostname (_sip._tls), while others want the full domain appended. If your registrar's interface separates Service, Protocol, and Name into three fields, enter each component separately.
Step 8: Add a DMARC Record
DMARC is not in Microsoft's required record list, but major inbox providers including Gmail and Yahoo now require it for high-volume senders, and it protects your domain from being spoofed in phishing attacks. Start with a monitoring-only policy and tighten it after you have reviewed reports for a few weeks.
Once you have confirmed all your legitimate mail streams are passing SPF and DKIM alignment, change p=none to p=quarantine and eventually p=reject. This tells receivers to block any message that fails DMARC — meaning attackers cannot send convincing phishing emails that appear to come from your domain.
Verifying All Records Are Correct
Do not rely solely on the Microsoft admin portal verification tool. Use command-line tools to independently confirm what resolvers around the world see.
On Linux or macOS, use dig instead of nslookup:
You can also use the DNS Lookup tool on this site to query any record type for your domain and see exactly what is published — useful if you do not have command-line access.
Common Problems and How to Fix Them
MX Verification Fails in the Admin Portal
This almost always means the record has not propagated yet. Check the TTL on your old MX record — if it was set to 86400 (24 hours), you may be waiting a full day for caches to expire. Lower the TTL to 300 before making changes in the future. Also confirm you deleted all old MX records; having multiple MX records with different priorities does not break delivery, but Microsoft's portal expects only its own MX to be present.
DKIM Enable Button Stays Greyed Out
Microsoft cannot find your CNAME records. Double-check that you entered the selector values exactly as shown in the portal — they are case-insensitive but the format must be exact. Some registrars append your domain name automatically to CNAME host fields, causing a record like selector1._domainkey.yourdomain.com.yourdomain.com. Enter only the subdomain portion in the Name field, not the full hostname.
Autodiscover Fails for Some Users
If Autodiscover is pointing to the correct CNAME but desktop Outlook still fails, check whether your organization has an on-premises Exchange server. Hybrid environments require Autodiscover to be handled differently — typically through an Autodiscover service connection point in Active Directory. Also check that no local hosts file entry or internal DNS zone is overriding the CNAME for domain-joined machines.
SPF Hard Fail on Legitimate Mail
If you send transactional email through a third-party service and that provider's IP range is not in your SPF record, those messages will fail SPF. Audit all services that send email on behalf of your domain and add their include mechanisms or IP ranges to your SPF record before switching to -all (hard fail). Use ~all (soft fail) during the transition to avoid blocking legitimate mail.
TTL Best Practices Before and After Cutover
Before you make any DNS changes for a live domain, lower the TTL on all affected records to 300 seconds (5 minutes). Do this 24 to 48 hours in advance to allow existing caches to drain. This means that if something goes wrong after you switch MX records, you can revert and the old settings will propagate back quickly. After the cutover is stable and you have confirmed mail is flowing correctly, raise the TTL back to 3600 or higher to reduce DNS query load.
How to Prevent Problems Going Forward
Document every DNS record you create, including the date, the purpose, and the value. Microsoft occasionally rotates DKIM keys (selector1 and selector2 alternate) — this is handled automatically, but if you ever need to delete and re-add the domain, you will need to republish the CNAME records. Set a calendar reminder to review DMARC reports monthly and tighten your policy from p=none toward p=reject once you are confident all mail streams are properly authenticated. Keep the Microsoft admin portal DNS records page bookmarked so you can always verify what the expected values should be if something breaks months down the line.