Summary

This MX record lookup tool reads the MX records you paste from dig or nslookup, sorts them into the order senders actually try, and names the mail provider behind each host. It then flags the mistakes that cause bounces: IP addresses as targets, a null MX mixed with real records, two providers on one domain, and a single host with no fallback. It does not query live DNS, so you see what your own resolver returns. It runs in your browser and nothing you paste is sent anywhere.

MX record lookup tool: read and audit your records

Run one dig command, paste the answer, and see delivery order, provider, and the mistakes that cause bounces. Nothing leaves your browser.

Audit your MX records

MX record lookup tool

Paste dig, nslookup, or plain preference and host lines. The result updates as you type.

Paste the output of dig MX yourdomain.com +short, a full dig answer, nslookup output, or one preference host pair per line.

      How it works

      What the tool reads from your MX records

      Preference sets the order

      Each MX record pairs a 16-bit preference with a hostname. Senders try the lowest number first and move up only when a host is unreachable. The tool sorts your records into tiers so the real delivery order is visible.

      Hostnames reveal the provider

      The tool matches each target against known suffixes, such as aspmx.l.google.com or mail.protection.outlook.com. It names about twenty mailbox and gateway providers. An unrecognised host is flagged, not guessed at.

      Rules come from the RFCs

      The checks are the ones written into RFC 5321, RFC 2181, and RFC 7505: hostname targets only, no CNAME aliases, and a null MX that stands alone. There is no score and no invented benchmark.

      Where to run it

      One command, then paste

      The tool does not query DNS for you, so the answer comes from your own terminal. That is a feature when you are debugging a migration: you see exactly what your resolver returns now, not a cached copy on a lookup site.

      • macOS and Linux: dig MX yourdomain.com +short
      • Windows: nslookup -type=mx yourdomain.com
      • Add @1.1.1.1 to dig to ask a specific public resolver
      Laptop with terminal output next to a notebook sketch of a mail flow
      Before you change MX records

      Four steps for a clean mail cutover

      This is the order we follow for an inbound mail migration on a domain that also sends transactional email.

      1. 1

        Record the current set

        Run dig MX and save the output. Paste it here to confirm what you are replacing and which provider owns it today.

      2. 2

        Lower the TTL ahead of time

        Drop the MX TTL to 300 seconds, then wait at least as long as the old TTL. Resolvers have to expire the long-lived copy before your edit matters.

      3. 3

        Swap the records in one edit

        Remove the old hosts and add the new ones together. A half-finished swap is how a domain ends up with two providers.

      4. 4

        Verify at a resolver, then restore the TTL

        Run dig against a public resolver and paste the result. Raise the TTL back once the tool shows one provider and no errors.

      MX record lookup questions

      Is this MX record lookup tool free?
      Yes. No signup and no request limit. The parsing and the checks run in your browser, and the text you paste is never sent to our servers. The only thing that leaves the page is the anonymous tool-run beacon.
      Does it query live DNS servers?
      No. A browser cannot send a raw DNS query, and routing your domain through a third-party lookup API would add a dependency we do not want. You run one dig or nslookup command, paste the answer, and the tool reads, sorts, and audits it. That also means you see what your own resolver sees.
      How do I get my MX records to paste?
      On macOS or Linux, run dig MX yourdomain.com +short. On Windows, run nslookup -type=mx yourdomain.com. Both formats work, as do full dig answers and plain pairs like 10 mx.example.com.
      What does the MX preference number mean?
      It is a priority, and the lowest number is tried first. If that host is unreachable, the sender moves to the next number. Hosts that share a number are tried in random order, which is how providers spread inbound load.
      Why is an IP address in an MX record an error?
      The MX target has to be a hostname that resolves through an A or AAAA record. RFC 5321 does not allow a bare IP there. Some mail servers tolerate it and many do not, so you get intermittent bounces that are hard to trace.
      Why does the tool warn about two providers on one domain?
      Mixed MX records usually come from a migration that was never finished. Senders try the lower preference first and fall back only when it is down, so mail can land on a platform where the mailbox does not exist. Keep one provider unless you route on purpose.
      Do MX records affect sending or only receiving?
      Only receiving. Outbound mail is governed by SPF, DKIM, and DMARC records, and by the reputation of the sending IP. A correct MX set will not fix a spam-folder problem on the sending side.
      Can I check a domain that has no MX record?
      Paste nothing and the tool says no records were found. Without an MX record, senders fall back to the domain's A or AAAA record, which is rarely what you want. Publish a null MX (0 .) if the domain should not receive mail at all.

      Track the infrastructure behind your own sends

      This tool covers the inbound side. Notification Harbor covers the sends you control: domain warmup, trace-level observability, and SPF, DKIM, and DMARC set up before the first production send.

      See how Notification Harbor works
      notificationharbor
      Start free