Skip to main content
Download

MX lookup: where a domain's mail is really delivered

Every MX record for a domain, sorted the way a sending mail server reads them, with IPs, reverse DNS and blacklist status on the Mac.

By Lucas Russo, developer of SSHive · Updated

Download SSHive FreeAll network tools
Also on iPhone and iPad
Mail stopped arriving, or it is arriving at the wrong server. The first thing to establish is not whether your firewall is open or your mailbox is full, but where the internet currently believes your mail should be delivered. That answer lives in one place: the domain's MX records. Every sending mail server on the planet queries them before it opens a single SMTP connection, and if they say something you did not expect, nothing downstream of them matters. MX lookups are also the step people skip after a migration. You move a domain to a new provider, the change looks correct in the control panel, and mail keeps landing in the old mailbox for another day because the records were never updated or because a stale copy is still being served. A thirty-second lookup would have shown it. SSHive runs that lookup itself, on Mac, iPhone and iPad. It queries the DNS resolvers your device is already configured to use: no web API in the middle, no account, no ads. On the Mac it does not stop at the record list: each exchange is resolved to its IPv4 addresses, each address is reverse-resolved to its PTR name, and the first address of every exchange is checked against eight DNSBL zones. You get the whole mail edge of a domain in one table: who receives, in what order, on which hosts, and whether those hosts carry a reputation problem. On iPhone and iPad you get the record list itself, priority and exchange hostname, pulled from the system resolver with a real DNS type 15 query, which is more than iOS's standard APIs will give you. It is free on Mac, iPhone and iPad, including the sandboxed Mac App Store build: no network tool in SSHive is behind the Pro gate. One limit stated plainly: this is an MX and reputation tool, not a full mail-authentication audit. SSHive does not inspect SPF, DKIM, DMARC, MTA-STS or TLS-RPT, does not grab SMTP banners, and does not test port 25 on any platform.

What SSHive does

Priorities, in the order SMTP reads them

SSHive queries the domain's MX records and sorts them ascending by preference, which is exactly the order a sending MTA walks them. The lowest number is tried first. On macOS the result is a five-column table; on iPhone and iPad each row carries a colour-coded priority capsule: green up to 10, orange up to 20, red above that.

Each exchange resolved to its addresses

On macOS every MX hostname is resolved to its IPv4 addresses and shown comma-separated in the IP column. An em dash means no A record came back: either the host is IPv6-only, since SSHive resolves IPv4 here, or the MX points at a name that no longer exists. Both are worth chasing down.

Reverse DNS for every mail server IP

The rDNS column shows the PTR name of each resolved address. It reveals who actually operates the host behind a vanity MX hostname, and it exposes the generic provider PTR names that receiving servers commonly penalise on outbound mail. Reverse lookup has no card of its own in the desktop panel: the MX table is where it surfaces.

Blacklist status inline, eight zones

On macOS the first IPv4 of each exchange is checked in parallel against zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net, dnsbl.sorbs.net, bl.mailspike.net, dnsbl-1.uceprotect.net, psbl.surriel.com and all.s5h.net. The column shows a green Not listed pill, or a red Blacklisted pill whose tooltip names the exact zones that flagged the address.

Real MX queries on iPhone and iPad

iOS exposes only name-to-address resolution, so getaddrinfo can never return an MX record. SSHive issues a genuine type 15 query through the BSD resolver, parses the answer section itself and reads the 16-bit preference straight off the wire. You get priority and exchange hostname, up to 32 records, with a copy button on every row.

Free on every platform, no ads

MX Lookup is not a Pro feature. None of SSHive's network tools are gated on any platform: no upgrade prompt in the tools panel, no ad interstitial before a lookup, no account to create. Pro, a one-time Universal Purchase across Mac, iPhone and iPad, is what you buy for more than 2 simultaneous SSH sessions or 5 saved profiles, for remote tunnels, and for RDP and VNC.

How to do it, step by step

  1. 1

    Open the network tools panel on the Mac

    In the Mac app, click the network icon in the sidebar, or the Network Tools pill on the Welcome screen. Either one opens a Network Tools tab. No SSH session and no connection is required first.

  2. 2

    Enter the domain in the MX Lookup card

    On the Mac, MX Lookup is the third card of the Lookup and reputation section, after DNS Lookup and DNSBL Check. Type the apex domain, not a hostname (example.com, not mail.example.com), and click Lookup MX records. The field's placeholder shows the expected format.

  3. 3

    Read the five columns

    Results come back as Priority, MX Server, IP, rDNS and DNSBL, sorted ascending by priority. Hover a red Blacklisted pill to see exactly which zones flagged the address; a green Not listed pill means none of the eight zones returned a 127.x answer.

  4. 4

    On iPhone or iPad, go to Tools then Email & IP

    Tap Tools in the bottom tab bar on iPhone, or Network tools in the sidebar on iPad, then MX Lookup, the first row of the Email & IP section. Enter the domain and run it. Each row shows a colour-coded priority capsule and the exchange hostname in monospace.

  5. 5

    Chain into Blacklist Check on mobile

    For the zone-by-zone detail on iPhone or iPad, tap the copy button on an exchange row, open Blacklist Check in the same Email & IP section and paste the hostname: it resolves the name to its first IPv4 itself, then checks ten DNSBL zones.

How to actually read an MX table

The priority number is a preference, not a quality score, and its absolute value means nothing. 5/10/20 and 1/2/3 describe exactly the same routing. Only the ordering matters: a sending MTA sorts ascending and tries the lowest first, moving to the next only when the connection fails. Two records sharing the same number are picked between at random: that is how MX-level load balancing works. That makes the highest-numbered record the one to look at hardest. A backup MX is a classic weak point: it is often older, less filtered and less monitored than the primary, and spam senders target it deliberately for exactly that reason. If your table shows a backup at a different provider than the primary, confirm it is still supposed to be there. An empty result is not necessarily a fault. Two legitimate cases exist. Priority 0 with a single dot as the exchange is a null MX (RFC 7505): the domain is declaring that it receives no mail at all, which is correct for a domain used only for a website. And a domain with no MX records is not unreachable: SMTP falls back to the A or AAAA record of the domain itself under the implicit MX rule in RFC 5321. Mail will be attempted against your web server, which is rarely the intention, but it is not silence. An em dash in the IP column means the exchange returned no A record. SSHive resolves IPv4 here, so an IPv6-only mail server reads as blank; run DNS Lookup on the exchange hostname and check for an AAAA before you call it broken. The same check catches the other classic misconfiguration: an MX pointing at a CNAME, which RFC 2181 and RFC 5321 forbid and which some MTAs reject outright. Finally, a DNSBL hit on an inbound MX does not stop you receiving mail. Its value is that in most small deployments the same host also sends, and a listing on zen.spamhaus.org, consulted by a very large share of receivers, is a materially bigger problem than one on dnsbl-1.uceprotect.net, which lists whole netblocks aggressively and is queried by far fewer servers. Read the zone, not the count.

Frequently asked questions

What does the MX priority number actually mean?+
It is a preference value, and only the ordering matters. A sending mail server sorts the records ascending and tries the lowest number first, moving to the next only if the connection fails. 5/10/20 and 1/2/3 describe identical routing. Records sharing the same number are selected at random, which is how load balancing works at the MX level. The number is not a quality rating and carries no unit.
My domain returns no MX records. Is mail broken?+
Not necessarily. If a domain has no MX record at all, SMTP falls back to the domain's own A or AAAA record under the implicit MX rule in RFC 5321. Mail is attempted against whatever your web server is, which is usually a misconfiguration but is not silence. The other legitimate case is a null MX: a single record with priority 0 and an exchange of a lone dot, which declares under RFC 7505 that the domain receives no mail and makes senders bounce immediately.
Does MX Lookup work on iPhone and iPad?+
Yes, on both, and free. The mobile version is narrower than the Mac's, though: it returns the priority and the exchange hostname, with no IP column and no reverse DNS, which exist only on the Mac. The mobile parser also stops at 32 records. For the zone-by-zone reputation of a mobile result, copy the hostname into the separate Blacklist Check tool.
Is MX Lookup available in the Mac App Store version?+
Yes, with all of its columns and all of its DNSBL zones. MX Lookup is plain DNS over the system resolver, so it needs no raw sockets and the App Sandbox does not restrict it. Nothing in the tools panel is restricted there: ping and traceroute send real ICMP from the App Store build too, through a datagram socket that needs no privileges.
Does SSHive check SPF, DKIM or DMARC?+
No. There is no SPF, DKIM, DMARC, MTA-STS or TLS-RPT inspection on any platform, no SMTP banner grab and no port 25 connectivity test. What you can do is read the raw records: SPF is published as a TXT record at the domain apex, and the DNS Lookup card on the Mac returns TXT alongside A, AAAA, MX, CNAME and NS. SSHive shows you that string; it does not parse or validate it. DMARC policies live at the separate _dmarc name.
Why is the IP column empty for one of my mail servers?+
The desktop MX Lookup resolves exchanges to IPv4 only, so an IPv6-only mail server has nothing to show and displays an em dash in both the IP and rDNS columns, and is never blacklist-checked, since the DNSBL engine is IPv4-only too. The other explanation is worse: the MX points at a hostname with no address record at all. Run DNS Lookup on that exchange to tell the two apart. If an AAAA record comes back, it is the first case.
Can I trust a "Not listed" result?+
Mostly, with one caveat worth knowing. Several DNSBL operators, Spamhaus in particular, refuse queries arriving from large public resolvers and answer with an error or a blanket return code. The Mac counts any answer beginning with 127. as listed, and everything else, a DNS error included, as not listed, so both directions can mislead you there on a public resolver: Spamhaus refuses those queries with a 127.255.255.x code, which reads as Blacklisted even though nothing is listed, while a zone that answers with an outright error reads as clean even if it does list you. iPhone and iPad set both cases apart as undetermined rather than counting them either way. When a result matters, confirm it against your ISP's resolver or a dedicated web checker before acting on it.

MX on the wire, and what it takes to query it from an iPhone

An MX record is one of the simplest resource records in DNS and one of the most consequential. Type 15, class IN, and an RDATA section with exactly two parts: a 16-bit preference in network byte order, followed by a domain name for the exchange. That name is subject to DNS name compression, so it is frequently stored as a pointer back into an earlier part of the message rather than as a literal string, which is why you cannot read an MX answer by treating the packet as text. RFC 5321 section 5.1 defines what a sending MTA does with the set. It queries MX for the recipient domain, sorts the results by preference ascending, resolves each exchange to address records, and attempts delivery in that order, randomising among records that share a preference value. If the MX query returns nothing, the sender falls back to the address records of the domain itself: the implicit MX rule. If it returns a single record with preference 0 and an exchange of a lone dot, RFC 7505 says the domain accepts no mail and the sender must bounce immediately instead of retrying for five days. The exchange must be a hostname with address records; it must not be a CNAME and must not be an address literal. Getting that answer on macOS is straightforward. SSHive uses Node's c-ares-backed resolver, which speaks DNS directly to the servers your OS is configured with rather than going through getaddrinfo. resolveMx returns the set, sorted ascending. Each exchange is then passed to resolve4, each resulting address to a PTR lookup, and the first address of each exchange to the DNSBL engine, which fans all eight zones out in parallel. Every enrichment step is independently error-trapped, so an exchange with no PTR record or no A record degrades to an em dash instead of failing the whole lookup. None of this needs a raw socket, which is why MX Lookup behaves identically in the Mac App Store build. iOS is the harder problem. Apple's high-level networking gives you name-to-address resolution and nothing more: getaddrinfo and NWEndpoint return A and AAAA records, and there is no public Swift API for an arbitrary record type. To read MX (and, since the same helper was generalised, every other record type the DNS Lookup screen now shows), SSHive drops to the BSD resolver in libresolv through a small C helper: res_init, then res_query with class C_IN and type T_MX for the raw answer, then ns_initparse and ns_parserr over the answer section, reading the preference big-endian from the first two RDATA bytes and expanding the compressed exchange name with dn_expand. Swift sorts the result by preference and hands it to the view. No third-party resolver library, no web API in the path: the query goes from your device to the resolvers it is already using. The costs are honest ones. The query uses the system resolver configuration, so a captive portal or a DNS64/NAT64 network that mishandles type 15 makes res_query fail and the app reports no MX records rather than a network error. The parser stops at 32 records. And across every platform there is no custom nameserver field, no TTL display, and no SPF, DKIM, DMARC, MTA-STS or TLS-RPT inspection.

Related tools

DNSBL check

DNS lookup

Whois

Ping

Traceroute