गाइड · ईमेल

Microsoft 365 DNS Records: MX, SPF, Autodiscover, DKIM and DMARC

The DNS records Microsoft 365 and Exchange Online need for mail flow and authentication: MX token, SPF include, Autodiscover, DKIM CNAMEs and DMARC.

लेखक: SiteDownCheck संपादकीय टीम · अपडेट: अक्टूबर 5, 2026 · 6 मिनट पढ़ने में

Connecting a domain to Microsoft 365 involves a set of DNS records that the admin center generates for your specific tenant. This guide explains what each record is for, what its general shape looks like with example.com placeholders, and how to test it. Two of them, MX and DKIM, contain tenant-specific values that you must copy from Microsoft rather than guess.

Where to edit

Publish the records in whichever DNS zone is authoritative for the domain. If you cannot see changes taking effect, confirm the real nameservers with the नेमसर्वर लुकअप. The admin center can add records automatically when DNS is hosted with a supported provider or when you use Microsoft's own nameservers, but a manual setup is entirely normal.

1. Domain verification

To add the domain Microsoft asks for proof of ownership, usually a TXT record:

example.com.   3600  IN  TXT  "MS=ms12345678"

The value is unique to your tenant. Keep it published.

2. MX record

Exchange Online uses a single MX record that points to a tenant-specific hostname:

example.com.   3600  IN  MX  0  example-com.mail.protection.outlook.com.

The target hostname is built from your domain with the dots replaced by hyphens, followed by .mail.protection.outlook.com, and the admin center displays the exact value, which Microsoft's documentation calls the MX token. Copy it from there. Microsoft's guidance is that this record should have the lowest priority number of any MX record, and the admin center usually suggests a value of 0 or 1. Remove MX records from your previous provider, or at least make sure they have a higher number. Better, remove them entirely after cutover.

Verify with the MX लुकअप. See MX records explained for priority rules.

3. SPF

example.com.   3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

Microsoft's documentation uses -all in its example. A softer ~all is a common choice during migrations while you inventory other senders. Rules to remember:

  • Exactly one SPF TXT record per domain. Add other senders into the same record.
  • The include:spf.protection.outlook.com term uses DNS lookups, and the total across everything you include must not exceed ten. Check with the SPF रिकॉर्ड चेकर and read fixing too many lookups if you are close.
  • Example with an additional sender:
example.com.   3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:spf.newsletter.example -all"

4. Autodiscover

Outlook uses Autodiscover to configure itself from a mail address. The standard record is a CNAME:

autodiscover.example.com.   3600  IN  CNAME  autodiscover.outlook.com.

Without it, Outlook clients may prompt for manual server settings or fail to connect. If you run a hybrid environment with an on-premises Exchange server, Autodiscover points elsewhere, so follow the hybrid deployment documentation.

5. DKIM

Microsoft 365 handles DKIM with two CNAME records, which let Microsoft rotate keys for you. You publish the CNAMEs, then turn signing on in Microsoft's security portal.

selector1._domainkey.example.com.   3600  IN  CNAME  selector1-example-com._domainkey.exampletenant.onmicrosoft.com.
selector2._domainkey.example.com.   3600  IN  CNAME  selector2-example-com._domainkey.exampletenant.onmicrosoft.com.

Here exampletenant stands for your tenant's initial onmicrosoft.com domain. The target format has varied; newer tenants may be given a different Microsoft-managed domain, which is one more reason to copy the exact targets from the portal and not rely on a pattern. The portal displays them when you open your domain under the DKIM settings of the email authentication policies.

Steps:

  1. Publish both CNAMEs.
  2. Wait for DNS to resolve them (dig +short CNAME selector1._domainkey.example.com).
  3. In the portal, switch Sign messages for this domain with DKIM signatures to enabled.

The common errors: the DNS host appends your domain to the name, producing a doubled hostname; CNAME flattening or proxying by your DNS provider hides the CNAME; or enabling signing before the records exist. If you see the portal complain that the CNAME record does not exist, query the exact names with the DNS चेकर. More diagnostics in DKIM setup and troubleshooting.

6. DMARC

Microsoft does not create this for you. Publish it yourself:

_dmarc.example.com.   3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Then move through quarantine to reject by following the DMARC rollout guide. Remember that Exchange Online will honor the sending domain's DMARC policy on inbound mail it receives too, which is separate from your own record.

7. Other records you may see in the admin center

Depending on your plan and services, the admin center may list additional records. Common ones include:

RecordPurpose
CNAMEs for device enrollment (Intune/MDM)Auto-enrollment of devices for management
Teams or Skype for Business records (lyncdiscover, sip, SRV records)Legacy Skype for Business and some Teams federation scenarios; often not needed for Teams-only tenants
Additional TXT for verificationDomain proof for other services

Add only what the admin center says your services need. Extra records do no good, and incorrect ones can break clients.

Record summary

PurposeTypeNameValue pattern
VerificationTXT@MS=ms... (tenant-specific)
Mail routingMX@<token>.mail.protection.outlook.com, lowest priority
SPFTXT@v=spf1 include:spf.protection.outlook.com -all
AutodiscoverCNAMEautodiscoverautodiscover.outlook.com
DKIMCNAMEselector1._domainkey, selector2._domainkeytenant-specific targets
DMARCTXT_dmarcv=DMARC1; p=none; rua=...

Verification checklist

  1. MX लुकअप shows only the Microsoft host (or your gateway).
  2. SPF रिकॉर्ड चेकर shows one record under ten lookups.
  3. Email DNS Checker finds DKIM and DMARC.
  4. Send a message to the ईमेल डिलीवरेबिलिटी टेस्ट and confirm spf=pass, dkim=pass with header.d=example.com, and dmarc=pass.
  5. Open Outlook with a new profile to confirm Autodiscover.

Troubleshooting

  • Mail still delivered to the old provider: a leftover MX with a lower number, or caching. See propagation.
  • Bounce 550 5.4.1 Recipient address rejected: Access denied: commonly Exchange Online refusing mail for an address that does not exist in the tenant, or a domain set as authoritative that has no matching mailbox. Check the recipient, and read bounce codes explained.
  • dkim=fail after enabling: records were not yet resolvable or you are signing with the wrong domain.
  • Spam placement though all pass: see email going to spam.

अगले कदम

सामान्य प्रश्न

What is the Microsoft 365 MX token?

It is the tenant-specific part of the MX hostname, shown in the admin center, which normally follows the pattern of your domain with hyphens before .mail.protection.outlook.com. Always copy the value from the admin center.

Why does Microsoft use CNAMEs for DKIM?

The CNAMEs point at keys Microsoft hosts, so Microsoft can rotate the keys without you editing DNS. You still have to publish both selector records and enable signing.

Can I use ~all instead of -all in the SPF record?

Yes, and many administrators do while auditing senders. Microsoft's example uses -all; pick the one you are confident about, and rely on DMARC reports to catch gaps.

Do I need the Autodiscover CNAME if I only use Outlook on the web?

It mainly matters for desktop and mobile clients that configure themselves from the email address. It is cheap to add and recommended by the admin center, so publish it.

Get notified when this guide updates

Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.