Microsoft 365 DNS and MX Records: Troubleshooting Email Delivery

Microsoft 365 DNS records have different jobs in business email delivery. MX directs incoming mail, while SPF, DKIM and DMARC help receiving systems assess outgoing messages. A website move should not silently replace mail settings. Use the values shown for the actual tenant and domain rather than examples from another account.

Locate the active zone for Microsoft 365 DNS records

Check the domain’s nameservers and edit records at the provider actually hosting that zone. A familiar old control panel may no longer be authoritative. Export or record the current zone before changes. Confirm the domain and exact record names rather than copying a value from another organisation. Lowering a TTL after an incident begins does not instantly clear cached old answers.

Microsoft 365 DNS records: check the MX destination

Use the Microsoft 365 admin centre’s domain setup guidance for the tenant’s required MX value and priority. Compare the public DNS answer with that value. An incorrect MX can route mail to an old provider or nowhere. Allow for caching, but do not use ‘propagation’ as an explanation until the authoritative record is correct. Check any additional mail-routing service intentionally used by the organisation.

Review sending authentication

SPF should authorise the real sending systems. Multiple separate SPF TXT records at the same name can break evaluation; combine authorised senders into a valid single policy where needed. DKIM configuration depends on the tenant’s current selector values. DMARC should align with a deliberate sending policy, not be copied blindly from another domain. Keep marketing and transactional senders in the inventory.

Trace a failed message

Record the sender, recipient, time and non-delivery report. In the admin centre, use message trace and delivery diagnostics to see whether Microsoft 365 accepted the message. If inbound mail arrives but a customer rejects outgoing mail, inspect authentication and reputation rather than repeatedly changing MX. A mailbox-level rule or quarantine action can explain only one affected recipient.

Retest after changing Microsoft 365 DNS records

Send an external inbound test and a reply, then examine message headers if authentication remains in doubt. Keep an inventory of website, marketing and transactional senders so a later SPF or DKIM change does not interrupt legitimate mail. Confirm the website’s form notifications as a separate path.

Related: Microsoft 365 setup and Outlook receiving-mail checklist.

Keep mail routing separate from mailbox migration

Microsoft’s external DNS records reference explains the roles of mail and authentication records. Use the values associated with your own domain and tenant. A change to incoming mail routing is not evidence that historical messages have moved. Verify mailbox readiness, old-mail access and any planned migration separately before retiring the old provider.