Mail to your domain not arriving? Read the MX records before blaming the mailbox

What an MX record does

When someone writes to you@yourbusiness.co.uk, their mail server asks DNS for the domain's MX records. Each one names a mail server and carries a priority number. The lowest number is tried first, and the rest are fallbacks. If the answer is empty, wrong or names a provider you left, mail goes to the wrong place or bounces, however healthy your mailbox is. That is why the first look belongs at the domain, not at the mailbox.

Rules that are easy to break

RFC 2181 section 10.3 says the name in an MX record must not be an alias, meaning a name that is itself a CNAME, because address lookups for it do not follow the alias and can fail. Point each MX at a real mail-server name that has its own address records. Two further habits cause most of the trouble in practice: leaving the old provider's MX beside the new one, and mixing priorities from two providers so mail splits between them.

Microsoft says plainly that more than one MX record can cause delivery problems and that a single MX record directing mail to one mail system removes many of them. It also says that changing the MX record sends all mail for the domain to Microsoft 365, and that old records should be removed once mail is flowing. Our reading is that the mailboxes should therefore exist before you change it.

• No MX target that is an alias.
• One provider's records only, once the move is complete.
• Mailboxes created at the new provider before the MX change.

What each provider expects

Providers publish the exact values. Microsoft 365 uses a hostname built from a token, shown in your admin console, followed by mail.protection.outlook.com, with a preference lower than any other MX record. Google Workspace documents a single record, smtp.google.com at priority 1, and says to remove any other MX records; accounts set up before 2023 may have older values beginning aspmx, which Google says still work. Take your values from your own admin console, not from a forum post, because they differ by tenant.

• Microsoft 365: the value shown in the admin centre for your domain.
• Google Workspace: smtp.google.com at priority 1, or your existing aspmx values if mail flows.

A safe first investigation

Do not change anything yet. Run an MX lookup for the domain and write down every line. Resolve each mail-server name to confirm it has an address. Compare the list with what your provider says it expects. Send a test message from two outside providers to a named address and keep any bounce text, because the error code tells you whether the problem is the domain, the address or a policy. Allow for cached answers: a changed record can take time to reach every sender, and Google says a new MX record may take up to 72 hours to be recognised.

• dig +short MX yourbusiness.co.uk, then dig +short A for each name it returns.
• Look for a second provider, an address in place of a name, or a name that answers with another name.
• Send two outside test messages and save any bounce.

How the paid outcome is accepted

The fixed-price job for this is a published test price of £175, not yet tested with buyers, and you pay after sign-off. Acceptance has three parts: the public MX records name only your chosen provider with each name resolving to an address and none an alias, test messages from two outside providers reach each named mailbox, and a test sent from your website's host arrives at the new provider's mailbox rather than a local one. It does not fix mail that arrives in junk, which is an authentication matter, and it does not move old messages.