Microsoft 365 DNS and MX Records: Troubleshooting Email Delivery

Microsoft 365 email depends on DNS records with different jobs. 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.

Find the authoritative DNS zone

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.

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 changes

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.