Microsoft 365 Domain Verification: The TXT and MX Methods

Microsoft gives you a choice most other platforms don't — verify with a TXT record, or verify with an MX record instead. The reasoning behind offering both is worth understanding.

📅 Published August 2026· ⏳ 18 min read· ✍️ ToolsNovaHub Editorial Team
🛠️ Related tool: Open TXT Lookup →

Two Roads to the Same Proof

When adding a custom domain to Microsoft 365 or Azure AD, the setup wizard typically presents a choice of verification methods, and the two most common are a TXT record and an MX record — an option most other major platforms don't bother offering. Both prove the same thing (DNS zone control), just through different record types, and Microsoft's decision to support both reflects a genuinely practical consideration: not every domain's DNS management situation makes adding a TXT record trivially easy, and MX records are something almost every domain owner already manages for mail regardless.

⭐
ToolsNovaHub Pro Tip
If you're planning to route mail through Microsoft 365 anyway, the MX verification method is worth considering — it verifies ownership using a record you'll likely be configuring regardless, rather than adding a separate TXT entry purely for verification.
⚠️
Common Beginner Mistake
Choosing MX verification for a domain that isn't actually going to route mail through Microsoft 365. The MX verification record can conflict with existing mail routing if not planned carefully — TXT verification is the safer default when mail stays elsewhere.

What the TXT Method Looks Like

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

The prefix MS=ms is fixed, followed by a numeric identifier unique to your specific tenant and domain verification attempt. It coexists with SPF, DKIM, and any other TXT records already on the domain without conflict, since TXT records have no coexistence restriction the way CNAME does.

What the MX Method Looks Like

The alternative method asks you to publish a specific MX record, with a particular hostname and priority value provided by Microsoft, purely for verification purposes rather than for actually routing mail. Microsoft's system checks for that exact MX entry to confirm ownership, the same underlying logic as TXT verification, just using a different record type that many domains already have infrastructure and processes around.

TXT vs MX Verification, Compared

FactorTXT MethodMX Method
Risk of conflicting with existing configVery low — TXT records coexist freelyHigher — MX changes can affect actual mail routing if not planned
Best fitDomains keeping mail elsewhere, or simply preferring the safer defaultDomains already planning to route mail through Microsoft 365
Ease of adding without side effectsGenerally simple, low riskRequires care to avoid disrupting existing mail flow

Step-by-Step: TXT Verification

1

Start Domain Setup in the Admin Center

Add your custom domain and choose the TXT record verification method.

2

Copy the Provided Value

Copy the exact MS=ms string Microsoft provides, without modification.

3

Publish It as a TXT Record

Add it at your domain's apex through your DNS provider's dashboard.

4

Verify Before Clicking Verify

Confirm the record is live with an independent lookup first, then complete verification in the admin center.

Real-World Scenarios

🏢
Enterprise Migrating to Microsoft 365
A common first step in enterprise onboarding — verifying every domain the organization plans to use for mail and identity under the new tenant.
💼
IT Admin Managing Multiple Tenants
Admins overseeing several Microsoft 365 tenants across different domains benefit from documenting which verification method was used where.
🔒
Domain Kept Separate From Mail Routing
Organizations that route mail through a different provider entirely still commonly use Microsoft services (like Teams or SharePoint) requiring domain verification via TXT specifically, to avoid disturbing existing mail flow.

Common Mistakes

MistakeConsequence
Choosing MX verification without planning mail routingCan conflict with or disrupt existing mail flow if not coordinated carefully
Publishing the TXT value with extra charactersCauses an exact-match failure indistinguishable from a propagation delay
Removing the verification record after setup completesMicrosoft can periodically re-validate and revoke verified status if it disappears
Not documenting which method was used for which domainMakes future troubleshooting or migration slower for teams managing many domains

Best Practices

Default to TXT verification unless you're specifically planning to route mail through Microsoft 365 already, in which case MX verification can be a reasonable, dual-purpose choice. Always confirm the record is live with an independent tool before completing verification in the admin center, and keep the record documented and in place rather than assuming it's safe to remove once verification succeeds.

Related Tools

Confirm your Microsoft verification TXT record is live with TXT Lookup, or check MX configuration directly with MX Lookup. Review the complete record set with DNS Lookup, or check propagation with DNS Propagation Checker. Also managing Google services on this domain? See Google Verification, or read the broader Domain Verification guide.

FAQ

It's typically formatted as MS=ms followed by a unique numeric identifier, published as a TXT record at the domain's apex.
The MX method exists mainly for domains where TXT record management is inconvenient, offering an alternate path using a record type most domains already manage for mail.
TXT is the safer default for most cases. MX verification makes sense specifically if you're already planning to route mail through Microsoft 365.
Yes, potentially, if not planned carefully — the verification MX record can conflict with existing mail routing, which is why TXT is the lower-risk choice for domains keeping mail elsewhere.
Not recommended — Microsoft can periodically re-validate, and removing the record risks revoking verified status later.
Yes — TXT records have no coexistence restriction, so the Microsoft verification string sits alongside SPF, DKIM, and any other TXT records without conflict.
Most often propagation delay or an exact-match issue from extra characters in the value — confirm with a live lookup before retrying.
Generally yes — domain-level verification under a tenant typically covers multiple Microsoft services tied to that same tenant and domain.
Yes — coordinate with whoever manages existing mail routing before adding the verification MX record, to avoid unexpected mail delivery disruption.
Use our TXT Lookup tool for TXT verification, or MX Lookup if you chose the MX method.
✓ Reviewed by: ToolsNovaHub Editorial Team📅 Last updated: August 2026📜 Sourced from: Standard Microsoft 365 / Azure AD domain-verification practice

ToolsNovaHub tools are built and independently maintained with a focus on accurate, no-signup network and security utilities. Spotted an error? Let us know.

📋 Related Tools & Guides Comparison

ResourceTypeLink
TXT LookupToolOpen Tool →
MX LookupToolOpen Tool →
Google VerificationGuideRead Guide →
Domain VerificationGuideRead Guide →
🔗 Continue exploring: TXT Lookup · MX Lookup · DNS Lookup · TXT Records · Domain Verification · Google Verification · TXT Record Security
Try it yourself — 100% free
🚀 Open TXT Lookup

🔗 More Guides