Email Best Practices7 Practical Steps to Set MX Records for Office 365Learn how to set MX records for Office 365 with 7 practical steps. Avoid routing issues, prevent email delivery failures, and ensure stable mail flow.
Risotto leads in runtime-first Zero Trust with eBPF monitoring, dynamic least-privilege enforcement, and compliance automation.
Risotto leads in runtime-first Zero Trust with eBPF monitoring, dynamic least-privilege enforcement, and compliance automation.
Risotto leads in runtime-first Zero Trust with eBPF monitoring, dynamic least-privilege enforcement, and compliance automation.
All mailbox providers have their own technical requirements for domain setup and MX record configuration, and these details play a critical role in how email is routed and delivered. Microsoft 365 is no exception and requires specific MX records to be configured accurately for email to function as intended.
Since MX records determine where incoming mail is delivered, even minor misconfigurations can lead to bounced messages, delayed delivery, or service interruptions. That’s why, in this blog, we walk through seven practical steps to help you configure MX records for Microsoft 365 correctly, ensuring stable mail flow and a smooth transition during setup or migration.
Each mailbox provider has a unique MX record setup, and Office 365 requires specific configurations. A clear understanding of these fundamentals helps prevent misconfigurations and ensures reliable email routing from day one.
Microsoft 365 requires a specific MX record value that routes email through Microsoft’s mail protection infrastructure. The format typically looks like:
your-domain.mail.protection.outlook.com
This value is unique to each tenant. Reusing an MX record from another domain or environment is a common cause of email delivery issues.
Each MX record also includes a priority value. Microsoft often recommends priority 0, but many DNS providers use 10 or lower numbers by default. The key principle to remember is that the lowest number always has the highest priority. Issues commonly occur when a legacy provider’s MX record has a lower priority number than Microsoft or when multiple MX records are configured with the same priority.
Accurate routing is the foundational requirement for ensuring reliable email delivery. Inbox placement depends on what happens after routing, including authentication and reputation signals, which is why teams often validate mail flow alongside inbox placement behavior during a deliverability test.
Since routing issues are often diagnosed alongside inbox placement and authentication behavior, teams typically validate mail flow as part of a broader deliverability check.
If you’re looking to understand how these signals are evaluated in practice, this guide on Email Deliverability Testing and how to do it right walks through the process step by step, helping you identify where delivery breaks down beyond just MX configuration.
The correct MX record for your domain is available in the Microsoft 365 admin center. After signing in, go to Settings, then Domains, select your domain, and open the DNS records section. Microsoft displays the exact MX value assigned to your tenant along with a recommended priority.
In more complex or hybrid environments, administrators often manage mail routing through Microsoft’s Exchange admin tools. These tools display the same MX record value shown in the Microsoft 365 admin center, since Microsoft assigns a single tenant-specific endpoint for incoming mail.
Before updating MX records, it is important to validate a few key prerequisites. These checks help minimize uncertainty during the change and enable faster recovery if mail flow does not function as expected.
Configuring MX records for Office 365 requires precision and the correct sequence of actions. The following steps outline a clear, practical approach to ensure accurate setup and uninterrupted email flow.
Before you configure MX records for Office 365, Microsoft needs to confirm that you control the domain. This verification step is required before any routing changes take effect. It does not alter mail flow or affect existing messages.
Verification is done inside the Microsoft 365 admin center. After signing in, open domain management and add the domain you plan to use for email. Microsoft will guide you through a short verification process tied to your DNS.
The most common method uses a TXT record. Microsoft generates a unique value that you publish at your DNS provider. Once that record is visible, Microsoft checks for it to confirm ownership. This check is passive. It does not redirect email or interrupt delivery.
Most verification failures come from simple issues:
Correcting the record and allowing time for DNS propagation resolves most cases. Verification often completes within 15 minutes, but some DNS providers can take up to 72 hours.
Before introducing Microsoft 365 into your DNS, you need a clear snapshot of how email is routed today. This step is about visibility, not change.
Start at the DNS provider that controls your domain. This is usually the registrar where the domain was purchased or a DNS service the domain was later pointed to, such as GoDaddy, Namecheap, or Cloudflare. The interface differs, but the goal is always to access the zone file where mail records live.
Once inside DNS management, look only at MX records. Do not edit anything yet.
Capture the current setup:
A quick way to structure this is to document what you see in a simple table.
This snapshot matters more than most teams expect. Conflicts during Office 365 migrations usually come from old MX records that were never removed or from priority values that still favor a previous provider.
Log in to the DNS provider that manages your domain and open the section where MX records are edited. Most providers label this as DNS management, zone settings, or mail records. The naming differs, but the destination is the same.
Add a new MX record using the values provided by Microsoft 365.
Microsoft commonly recommends priority 0, but many DNS providers default to 10 or use different numbering conventions. What matters is ordering. The Microsoft 365 MX record must have the lowest number so it is tried first.
TTL settings are often misunderstood. Lower values like 300 or 600 seconds are fine during testing, but TTL does not control global propagation speed. It only affects how long resolvers cache the record. Leaving the provider default is usually sufficient.
Some DNS platforms introduce quirks that can cause subtle errors:
After saving the record, double-check the value for typos and formatting issues. A single missing character is enough to impact deliverability.
MX records are evaluated based on priority. The rule is simple. Lower numbers are tried first. When multiple MX records exist, the one with the lowest value receives email before the others.
Microsoft often recommends using priority 0 for its MX record, but that is not a strict requirement. Some registrars default to 5 or 10, and others do not allow 0 at all. What matters is not the number itself, but that Microsoft’s MX record has the lowest priority value among all active MX records for the domain.
If the priority is not set correctly, incoming email may continue routing to the previous provider even though the Microsoft 365 record exists. This is why migrations sometimes look successful on the surface while messages still arrive in the old system.
It is normal to have more than one MX record. Higher priority values are commonly used for fallback routing, and in some environments, multiple MX records intentionally share the same priority for load balancing. Problems only appear when equal priorities are added unintentionally, without a clear routing plan.
During staged migrations or hybrid setups, it is often safer to keep the old MX record temporarily. In that case, assign it a higher priority number so it only receives mail if Microsoft’s servers are unavailable.
Once Microsoft 365 is receiving email successfully, the next consideration is how to manage the legacy provider’s MX record. The right choice depends on how confident you are in the current mail flow and whether the environment is simple or hybrid.
If multiple SPF records exist, they must be merged into a single record. Leaving more than one SPF record causes authentication to fail. After updating the record, it is worth validating the final result using an SPF checker to confirm the record resolves correctly and includes all required senders.
DKIM verifies that email content has not been altered during delivery. Microsoft 365 uses DKIM through CNAME records, not TXT records.
The selector values are generated by Microsoft and are unique to each tenant. Both CNAME records must be added before DKIM can be enabled successfully. Once published, a DKIM checker can help confirm that the selectors resolve correctly and are visible to receiving mail servers.
DMARC ties SPF and DKIM together and tells receiving servers how to handle authentication failures.
A basic monitoring policy is recommended during migrations. It provides visibility into authentication results without affecting delivery while mail flow stabilizes.
After updating MX records, the final step is confirming that the change has propagated and that email is flowing into Microsoft 365 as expected. DNS propagation is not instant. Depending on the DNS provider and previous TTL values, updates can become visible anywhere from a few minutes to 72 hours after the change.
Propagation also does not happen uniformly. Different DNS resolvers may return different results during the transition, which is why validation should include both DNS lookups and real mail flow testing.
To check propagation status, use a combination of tools:
A successful DNS check shows the Microsoft 365 MX record with the correct mail.protection.outlook.com value and the expected priority. If older MX records still appear, propagation is still in progress, or the update has not been applied correctly.
DNS confirmation alone is not sufficient. Always validate actual mail flow.
Once test emails arrive consistently and headers confirm Microsoft handled delivery, propagation is effectively complete for real-world sending.
MX records control routing. Deliverability determines whether the email is accepted and placed correctly once it arrives. After configuration, the focus should shift to validation and monitoring.
Send test emails from your domain to a mix of inbox providers:
Check the inbox and spam folders, then review message headers to confirm SPF, DKIM, and DMARC are passing. Failures at this stage usually point to authentication or DNS issues rather than content.
Use Microsoft’s Message Header Analyzer to review how messages were processed. Check blacklist status to rule out inherited or historical reputation issues.
Inbox placement testing adds deeper visibility. An inbox placement test shows where messages land across providers and surfaces authentication or reputation problems early. MailReach’s spam test tool helps validate placement signals in one place instead of relying on assumptions.
Monitor deliverability closely after the change:
Many issues appear quickly, even if they resolve on their own. Documenting anomalies helps identify patterns.
Email warm-up is not required simply because the MX records changed. In scenarios where sending patterns do change, such as launching new mailboxes or increasing volume, a structured warm-up process helps rebuild consistent reputation signals.
MailReach Email Warmup is designed for this phase, automating gradual volume ramp-up while generating real engagement signals that inbox providers look for. This allows teams to stabilize inbox placement before returning to full-scale sending, without manually managing warm-up activity or risking sudden reputation drops.
Inbox providers evaluate reputation based on consistency, volume, and engagement. When those signals reset or change significantly, a controlled ramp-up helps stabilize placement before full sending resumes.
Setting up MX records for Office 365 is a precision task. The seven steps in this guide are designed to help you route email correctly, avoid DNS conflicts, and validate delivery before the migration is considered complete.
That said, MX configuration is only the starting point. Inbox providers continue evaluating sender reputation after the change, based on authentication, consistency, and how sending patterns evolve. This is where many migrations quietly run into deliverability issues, even when the technical setup looks correct.
When an Office 365 migration coincides with new domains, new mailboxes, or changes in sending volume, sender reputation often needs time to stabilize. A controlled warm-up, combined with real visibility into inbox placement, reduces the risk of sudden filtering or engagement drops.
MailReach helps teams protect deliverability after migration by rebuilding sender trust gradually, monitoring inbox placement in real time, and scaling safely as sending resumes. To safeguard deliverability beyond day one, you can validate real-world delivery using an inbox placement test or stabilize reputation with a structured email warmup as your Microsoft 365 sending ramps up.
Every email in spam equals to a lost potential customer. Start improving your inbox placement today with MailReach spam testing and warmup.
Following the rules isn’t enough—know where your emails land and what’s holding them back. Check your spam score with our free test, and improve deliverability with MailReach warmup.
Without the right warmup, your best campaigns are of no use. You can start by first testing your inbox placement and begin improving it today.
7 Practical Steps to Set MX Records for Office 365
5 Steps to Setup MX Record Google Workspace in 2026
How to Improve Inbox Placement for B2B Outreach
GDPR Email Compliance Checklist for 2026
Google Workspace Email Sending Limits for 2026: A Practical Guide for Cold Outreach Teams
