SMTP Server Finder — MX Hosts with IPv4 Resolution

Mail transfer agents look up MX at the recipient domain, sort by priority, and attempt delivery starting with the lowest number. Multiple MX entries at the same priority imply load sharing without strict preference order. Each MX target must resolve to addresses reachable on SMTP — historically port 25.

Our finder answers who and where: hostname and IPv4 for each exchanger. It does not open SMTP sessions — pair with port checking tools elsewhere when confirming listeners.

priority is the numeric preference from the MX_rdata — 1 beats 10. host is the mail exchanger hostname without trailing dot. ips lists IPv4 A records currently returned for host. Empty ips means resolution failed or only AAAA exists — investigate before blaming SMTP refusal.

primary mirrors servers[0] after sort — the preferred destination for new mail under normal conditions. Backup MX with higher priority numbers receive mail when primaries are unreachable.

Security teams allowlist inbound connections from known ESP ranges but must also allow outbound MTA resolution to customer MX IPs. Listing ips beside each MX row saves separate A lookups during change windows.

When ips change after a provider migration, SMTP may still attempt old cached addresses until DNS TTL expires on sending side — document both hostname and IP in migration runbooks.

Hosted mailbox migrations publish provider-specific MX clusters. Verify post-cutover that only expected aspmx or protection.outlook.com style hosts appear with correct priorities. Stray legacy MX pointing at on-premise servers causes split delivery.

Run finder before and after MX TTL windows. Compare serverCount and primary.host against vendor documentation — extra unexpected MX often means incomplete decommission.

Higher priority numbers (e.g. 20, 30) typically indicate backup or spam-filtering gateways. Some backups queue mail when primary is down; others are sinkholes. Knowing hostname and IP clarifies which path mail took during incidents.

serverCount zero means no MX — domain cannot receive mail via standard SMTP. Intentional for send-only domains; surprising for marketing sites with contact forms expecting replies.

MX record lookup in our classic toolkit returns raw MX strings. SMTP server finder adds IPv4 resolution and primary summary. MX priority checker validates duplicate priorities and configuration issues — run both when auditing complex MX sets.

Together they cover content, resolution, and configuration hygiene.

When delivery delays hit one destination domain, compare their MX ips to your MTA logs — did you connect to expected IP? If ips differ from finder results, stale cache or split-horizon DNS may be involved. If ips match but SMTP fails, escalate to port and TLS diagnostics.

Bounce messages citing MX resolution failures should trigger immediate finder rerun — operators sometimes delete MX during unrelated DNS edits.

We filter ips to IPv4 only for broad firewall compatibility. If ips is empty but host resolves via AAAA, your sending infrastructure may need IPv6 egress or the provider may be misconfigured for IPv4-only senders.

Check AAAA separately with DNS lookup when IPv4 list is empty yet mail flows — dual-stack providers often publish both.

Call extended API with action smtp-server-finder and domain parameter. Ingest primary.host and ips into configuration management databases when onboarding customer domains for managed mail filtering.

Refresh after customer DNS self-service changes — MX drift is a top cause of mysterious mail loss.

MX and A records are public. Lookups are appropriate for domains you administer or troubleshoot with permission. Do not use resolved IPs for port scanning without authorization.

We do not store queried domains permanently.