DNS Zones for Microsoft 365: Records, SPF, DKIM & DMARC

A DNS zone is the administrative slice of the DNS namespace where you actually manage records: the A, MX, TXT, and CNAME entries that route traffic for your domain. Specifically, this guide breaks down zone anatomy, M365-critical records (SPF, DKIM, DMARC, MX), resolution flow, and troubleshooting. Moreover, every recommendation comes from what Wintive observed across 60+ Microsoft 365 and Azure tenant audits.

🧭 Why DNS zones for Microsoft 365 matter in 2026

DNS used to feel like plumbing. However, in 2026 it sits at the heart of email security and zero-trust posture. Specifically, every Microsoft 365 onboarding requires 6 to 8 DNS records. Furthermore, a missing DKIM key or a wrong SPF flag means messages land in junk or get rejected outright.

Email auth records are now the primary attack surface for tenant takeover. Consequently, attackers harvest credentials, forge sender domains, and abuse weak SPF policies. Therefore, knowing your zone cold is no longer optional for any admin running Exchange Online, Defender for Office 365, or a custom Azure App Service domain. For deeper protocol references, see Microsoft Learn — Add a domain and RFC 7489 (DMARC).

🧬 Anatomy of a DNS zone for Microsoft 365

A DNS zone is a contiguous portion of the namespace under one administrative authority. Specifically, when you buy example.com, you become authoritative for the example.com zone. Furthermore, every record under that name lives inside your zone — not at the registrar, not at the TLD.

At the top sits the root zone (a single dot). Below the root, ICANN delegates to top-level domains like .com, .org, .net, and 1500+ others. Then, each TLD operator delegates second-level domains (SLDs) to registrants like you. Finally, you operate the SLD zone — example.com — and add records below it: www, mail, autodiscover, _dmarc, and so on.

Every zone has two mandatory records: an SOA (start of authority, names the primary nameserver and serial) and a set of NS records (which servers hold the zone). Notably, both are created automatically by your DNS provider. As a result, your job is the records below: A, MX, TXT, CNAME — the ones that actually route traffic.

📋 The 7 record types every M365 admin must know

Hundreds of record types exist in DNS. However, M365 admins use seven on a daily basis. The table below summarizes when each one matters in a typical Microsoft 365 estate.

Looking at the distribution observed across 60+ Wintive tenant audits, three record types dominate. Specifically, A records and TXT records together account for 60% of zone entries. Furthermore, TXT explosion comes from the email auth stack — SPF, DKIM selectors, DMARC policy, and tenant verification all live there.

📧 Email auth records: SPF, DKIM, DMARC, MX

For any M365 tenant sending email, four records work together to prove sender legitimacy. Specifically, MX routes inbound mail. Furthermore, SPF, DKIM, and DMARC defend outbound mail against spoofing. Notably, weak email auth is the #1 finding in Wintive tenant audits.

SPF: declare who can send for your domain

SPF (Sender Policy Framework) is a TXT record at the apex of your zone. It lists the IPs and includes allowed to send mail using your domain. For M365, the canonical record is short: v=spf1 include:spf.protection.outlook.com -all.

However, two traps catch most admins. First, the 10-lookup limit: each include:, a:, or mx: counts. Therefore, stacking many third-party senders breaks SPF silently. Second, the policy flag: -all (hard fail) is recommended; ~all (soft fail) is permissive. Consequently, audit your SPF flag on every onboarding.

DKIM and DMARC: signature and policy

DKIM signs outgoing messages with a cryptographic key. Specifically, M365 publishes two CNAME selectors per accepted domain: selector1._domainkey and selector2._domainkey. Both point to selector1-{domain-com}._domainkey.{tenant}.onmicrosoft.com. Notably, both must resolve before DKIM signing activates in Exchange Admin Center.

DMARC sits on top: it tells receivers what to do when SPF or DKIM fail. The TXT record lives at _dmarc.example.com. Furthermore, the policy progression is p=none (monitor only) → p=quarantine → p=reject. Therefore, start at none, collect aggregate reports for 4 weeks, then tighten. Indeed, jumping straight to reject blocks legitimate senders you forgot to authorize.

📌 M365 onboarding: the 6 DNS records you must configure

When you add a custom domain to a Microsoft 365 tenant, the admin center prompts you to add a fixed set of records. Therefore, copy the block below into your DNS provider (Azure DNS, Cloudflare, Route 53, OVH, GoDaddy — same syntax everywhere). Then, replace example-com with your {domain}-{tld} Microsoft tenant identifier.

# M365 baseline DNS records for example.com
# Replace example-com with your {domain}-{tld} M365 identifier
# Replace example with your tenant short name in onmicrosoft.com

# 1. Domain ownership verification (TXT at apex)
@   IN  TXT  "MS=ms12345678"

# 2. Mail flow (MX at apex, priority 0)
@   IN  MX   0  example-com.mail.protection.outlook.com.

# 3. Anti-spoofing - SPF (TXT at apex)
@   IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

# 4. Outlook autodiscover (CNAME)
autodiscover    IN  CNAME  autodiscover.outlook.com.

# 5. DKIM signing - both selectors required
selector1._domainkey   IN  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.
selector2._domainkey   IN  CNAME  selector2-example-com._domainkey.example.onmicrosoft.com.

# 6. DMARC policy (TXT at _dmarc subdomain)
_dmarc  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

Once propagation completes (5 minutes to 48 hours depending on your TTL), validate everything from the Microsoft 365 admin center under Settings > Domains. Specifically, every record turns green when DNS resolves correctly. Furthermore, after DKIM CNAMEs resolve, enable signing in Exchange Admin Center under Email authentication settings > DKIM.

🔄 How DNS resolution works for inbound M365 email

When an email arrives at your M365 tenant, a multi-step authentication chain runs in milliseconds. Notably, knowing this sequence helps debug messages stuck in junk or quarantine.

The MX lookup tells the sender where to deliver. Then, on arrival at {tenant}.mail.protection.outlook.com, Defender for Office 365 fetches the SPF record at the sender domain. Specifically, it verifies the sending IP against the SPF allowlist. Furthermore, DKIM signature verification follows: the recipient pulls the public key from the signing domain’s selector._domainkey CNAME chain.

Finally, DMARC policy evaluates the alignment between SPF/DKIM signing domains and the From header. As a result, three outcomes exist: pass (deliver), quarantine (junk folder or admin queue), or reject (bounce). Indeed, mail flow rules in Defender can override DMARC for trusted partners, but only when explicitly configured.

🌍 Public vs Private zones for M365 and Azure

DNS zones come in three flavors depending on the audience. Specifically, public zones answer queries from anywhere on the internet. In contrast, private zones answer only inside an Azure VNet or on-prem network. Furthermore, conditional forwarders bridge the two for hybrid scenarios.

Most SMBs only ever touch the public zone — that is where M365 records live. However, growing organizations adding Azure VNets, private endpoints for storage, or App Service VNet integration will end up running both. Therefore, plan zone strategy at architecture stage, not after the first private endpoint breaks.

🚨 Troubleshoot M365 DNS issues

Most M365 mail issues trace back to DNS misconfiguration. Specifically, four PowerShell and shell commands solve 90% of zone problems. The block below is the Wintive go-to triage script.

# PowerShell + dig: M365 DNS triage
# Replace example.com with your domain

# 1. SPF check
Resolve-DnsName -Name example.com -Type TXT | \`
    Where-Object { $_.Strings -like '*spf1*' }

# 2. MX check (must point to mail.protection.outlook.com)
Resolve-DnsName -Name example.com -Type MX

# 3. DKIM CNAMEs (both selectors must resolve)
Resolve-DnsName -Name selector1._domainkey.example.com -Type CNAME
Resolve-DnsName -Name selector2._domainkey.example.com -Type CNAME

# 4. DMARC policy + alignment
Resolve-DnsName -Name _dmarc.example.com -Type TXT

# Bonus: verify DKIM signing is enabled in Exchange Online
Get-DkimSigningConfig -Identity example.com | \`
    Format-List Domain, Enabled, Status, KeySize

If Get-DkimSigningConfig returns Enabled: False while the CNAMEs resolve, simply enable signing: Set-DkimSigningConfig -Identity example.com -Enabled $true. However, if the CNAMEs do not resolve, propagation has not completed or the records were typed wrong. Therefore, always verify DNS propagation with dig +trace from a clean resolver before opening a Microsoft support ticket.

❓ DNS zones — FAQ

🔗 Keep exploring

Need help auditing your DNS zone, M365 email auth (SPF/DKIM/DMARC), or hybrid setup? Book a free 30-minute consultation with our Microsoft 365 and Azure experts.