MX Record Verification Checklist: Routing and Incoming Email

Verify incoming mail at both DNS and mailbox level. A correct MX lookup is useful, but it does not show that the intended address exists, its aliases work or its users can access the inbox. Keep those checks separate.

Find the authoritative DNS zone

Identify which service currently hosts the domain’s DNS, then compare its record list with a public lookup. The registrar, website host and DNS provider may be different companies. Editing a retired zone can produce a convincing dashboard screenshot without changing public routing.

Record existing MX values, priorities and TTLs before an authorized change. Use the receiving mail provider’s current instructions. Google Workspace notes that some older accounts use a different supported record set from newer setups; do not replace a working configuration simply because a tutorial shows another format.

Confirm the receiving service is ready

Create or verify the required mailboxes, aliases, groups and shared addresses at the destination. Check service activation, domain verification and access for the responsible users. A forwarding address and a full mailbox are different deliverables.

Test the addresses people actually use: sales, billing, support and an individual mailbox. Include a less frequent alias that receives invoices or registrar notifications. Record who owns the catch-all policy if one exists rather than silently recreating it on a new provider.

Run external delivery tests

Send from an independent mailbox to each critical recipient, then confirm the message reaches the intended destination. Record time, recipient and message identifier. A message sent between two accounts in the same system may not exercise the public MX route.

If a message bounces, save the response privately and ask the mail administrator to interpret it. If it arrives elsewhere, compare the delivery path and mailbox rules. Spam-folder placement is a different issue from mail routing; note which outcome actually occurred.

Watch a planned transition

During an email move, keep both services available for the agreed overlap and inspect both destinations. Existing DNS caches can mean different senders observe a change at different times. Do not promise a universal propagation deadline based only on the TTL displayed in a control panel.

MX changes route new incoming mail; they do not copy message history. Use the business email migration checklist for old messages and mailbox reconciliation. Keep the website move without breaking email guide nearby when only hosting is changing.

Close with separate outbound tests

Once inbound routing is verified, test outbound delivery and authentication independently. SPF, DKIM and DMARC address different questions from MX. A domain receiving mail successfully can still have a broken website sender.

Sign off only when DNS, critical recipients, user access and external delivery each have a dated result. Retain the prior settings and a named escalation contact until the change owner closes the transition.

Example: routing works but one address bounces

If a hypothetical external test reaches one mailbox but another address bounces, check whether the failing mailbox, alias or group exists and accepts that sender at the receiving service. Preserve the bounce text and time. The difference does not by itself prove an MX error. Separately confirm the authoritative records and repeat representative inbound tests before closing the migration.

Sources and scope

Official documentation checked October 6, 2026: Google Workspace: Set up MX records; Google Workspace: Troubleshoot incoming mail. This is HRL’s general operating checklist, not a test of your domain or a guarantee of delivery, recovery or search visibility.

Related guides

Verify the wider DNS change · Check outbound sender authorization