Free diagnostic
Inspect a domain's published MX records, priorities, and mail exchanges without probing a mailbox or retaining the submitted domain.
DNS
live evidence
No SMTP
mailbox probing
0
stored submissions
MX records identify the servers a domain publishes for inbound email. Priority values describe preference order, while the exchange names identify the receiving infrastructure.
An MX record does not prove that a specific mailbox exists, that SMTP will accept mail, or that an outbound message will reach the inbox. Those are separate questions with different evidence.
Fundamentals
An MX (mail exchange) record is a DNS record that names the servers responsible for accepting email addressed to a domain. When a sending server delivers to [email protected], it queries DNS for the MX records of example.com, then connects to one of the listed hosts over SMTP. Each record has two parts: a preference value (a number, sometimes called priority) and an exchange hostname. A domain can publish several records so delivery continues when one server is unavailable. The preference value sets the order senders should try. Lower numbers are more preferred, so a record at preference 10 is contacted before one at 20. Records sharing the same preference are treated as equivalent and may be used in any order, which is why a backup exchange should always carry a higher number than the primary. A domain can also declare that it accepts no email at all by publishing a null MX record: a single record with preference 0 and an exchange of "." (one dot), defined by RFC 7505. Senders that honor it reject mail to that domain immediately instead of retrying. Inbound routing matters to senders too: if you mail customers from a domain, bounces and replies return to its MX hosts, and a broken inbound path means you never see them. Check MX alongside authentication with the SPF checker and DMARC checker, and see the MX records guide for a deeper walkthrough.
Reading the output
This tool runs one live DNS query for the domain you submit and reports exactly what is published. It does not open an SMTP connection, probe any mailbox, require a login, or retain the submitted domain.
Troubleshooting
Most MX problems fall into a small set of patterns, each visible in the lookup output or a follow-up DNS query.
Providers
The major mailbox providers publish well-known MX hostnames, so the lookup output alone usually reveals who handles a domain's inbound mail.
Comparison
All three can tell you something about a domain's mail setup, but they are built around different jobs. MXToolbox is a broad DNS toolbox with ad-supported free lookups and paid monitoring subscriptions from $129 per month. dmarcian is DMARC-focused and has no standalone MX tool. WillItInbox runs free MX checks with no login and no retention of the submitted domain, paired with optional domain monitoring and a full deliverability test when you need evidence beyond DNS.
| Capability | WillItInbox | MXToolbox | dmarcian |
|---|---|---|---|
| MX lookup | Free, one-off, live DNS | Free, one-off, ad-supported | No standalone MX tool |
| SPF/DMARC checks in one place | Yes, free tools for both | Yes, as separate lookups | DMARC-focused |
| Login required | No for free checks | No for free lookups | Account-oriented platform |
| Ads | None | Ads on free tier | None |
| Monitoring beyond one-off checks | Optional domain monitoring | Paid plans from $129/mo | DMARC reporting platform |
| Submitted-domain retention | None for public checks | Varies by product | Varies by product |
Live diagnostic
This anonymous tool is rate limited and does not retain submitted input. It reports observable evidence without promising delivery, authentication alignment, or inbox placement.
No SMTP mailbox probing, account lookup, or tenant data is used.
Related
Understand priorities, fallbacks, and common errors.
Classify recipient risk with layered evidence.
Track MX and authentication drift over time.
Open the domain workflow for recurring MX, authentication, TLS, and reputation evidence.
See how this workflow applies to teams running developer testing, sdks, webhooks, and ci/cd.
Read the supporting guide for practical context around developer testing, sdks, webhooks, and ci/cd.
Review request and response patterns for single validation, bulk verification, suppression, and webhook flows.
Use the REST API reference when validation, bulk jobs, webhooks, reports, or usage need to run from your own systems.
Verify signed callbacks for bulk jobs, reports, sandbox events, delivery logs, and operational automation.
Use the Node and Python clients for validation, sandbox capture, report access, and webhook verification.
Compare validation volume, monitoring, API access, reporting, and workspace limits by plan.
FAQ
No. MX records only name the servers that accept mail for a domain; they say nothing about individual mailboxes. Even a successful SMTP conversation is not conclusive, because large providers such as Gmail and Microsoft often accept mail at the SMTP stage and filter or drop it later. MX evidence answers a routing question, not an existence question.
A null MX record, defined by RFC 7505, is a single record with preference 0 and an exchange of one dot. It deliberately declares that the domain accepts no email, and senders that honor it reject mail to that domain immediately rather than retrying. It is the correct setup for domains that should never receive mail.
No. The exchange hostname must resolve directly to A or AAAA address records, not to a CNAME alias. Email standards prohibit aliases here, and senders that enforce the rule fail delivery. If your MX host is an alias, create a hostname with its own address records and point MX at that instead.
Propagation is governed by the TTL on the old records: until it expires, resolvers that cached the previous answer keep returning it, so changes take anywhere from minutes to a day or more. For a planned migration, lower the TTL in advance, change the records, then re-run an MX lookup after the old TTL passes to confirm.
RFC 5321 defines a fallback: when a domain has no MX records, senders try the domain's A or AAAA address. If that host runs a mail server, mail arrives anyway. It is fragile, though: some senders treat missing MX as undeliverable, you get no backup ordering, and moving your web host can break mail. Publish explicit MX records, or null MX if the domain should not receive mail.
Preference numbers set the order senders try your mail servers: lower is more preferred, so 10 receives mail before 20. Equal preferences are interchangeable and used in any order, so backups should always carry a higher number than the primary or they take a share of normal traffic.
No. The tool performs one live DNS query and shows the published answer. It opens no SMTP connection, probes no mailbox, requires no login, and retains nothing you submit. The result is DNS evidence only, shown with its limitations and a link to RFC 5321.
