Free MXToolbox Alternatives, Sorted by the Job

Most people arrive at MXToolbox with one specific question. Why is Gmail rejecting our mail? Did the new SPF record go live? Is our server on a blocklist? The site answers all of those from one search box, which is why it became the default. But "one search box" hides the fact that these are different jobs with different inputs, and a tool built for one of them is often clearer than a bundle built for all of them.

So rather than a ranked list of look-alike sites, this is a map. For each thing MXToolbox does, here is a free alternative, what it is good at, and what it cannot see. We build some of the tools named below, so we have tried to be precise about their limits as well as their strengths.

What MXToolbox actually bundles#

Its SuperTool menu lists roughly two dozen commands. They fall into five groups:

• DNS reads: MX, A, AAAA, TXT, CNAME, SOA and PTR lookups, plus WHOIS and ASN.
• Email authentication checks: SPF, DKIM, DMARC, BIMI, MTA-STS and TLS-RPT.
• Reputation: a blacklist check that tests an IP against more than 100 DNS-based lists.
• Live connection tests: an SMTP test against port 25, plus ping, traceroute and HTTP/HTTPS checks.
• Ongoing monitoring: which needs an account. The free account covers one domain with weekly blacklist monitoring.

The first three groups only read public data, so plenty of free tools can do them. The fourth needs a server that can open outbound connections to your mail server, which is rarer. The fifth needs someone to run a scheduler on your behalf, which is where free usually stops.

Checking the records#

This is the most common job, and the one where depth matters more than breadth. Fetching an SPF record is trivial. Telling you it will fail is the useful part.

Our SPF checker walks the whole include: chain and counts DNS lookups against the limit of ten that RFC 7208 sets for a single evaluation. That limit is the classic silent failure: every record in the chain looks fine on its own, the total is eleven, and receivers return permerror for every message you send. The DKIM lookup handles the other classic problem, which is that you usually do not know your selector. It probes more than 50 common ones (Google, Microsoft, SendGrid, Mailchimp, Amazon SES and others) and reports the key type and length, flagging 1024-bit RSA keys and revoked keys. The DMARC checker parses each tag and checks that the reporting addresses are usable.

If you would rather see the whole domain at once, the domain health report runs DNS, SPF, DKIM, DMARC, DNSSEC, the TLS certificate and WHOIS together and marks each section OK, warning, fail or unavailable. "Unavailable" matters: a check that could not run is reported as exactly that, rather than quietly counted as a pass.

Two outside options are worth knowing. Google's Admin Toolbox has a Check MX tool that looks for common MX misconfigurations, and a web version of dig. It is aimed at Google Workspace admins but works for any domain. And internet.nl, an initiative of the internet community and the Dutch government, runs an email test covering IPv6, DNSSEC, DMARC, DKIM, SPF, STARTTLS, DANE and RPKI in one pass. It grades against modern standards rather than just checking that records exist, which makes it a good second opinion once the basics pass.

Blocklist lookups#

This is where the difference between tools is most visible, and it is mostly about which lists they are allowed to query.

MXToolbox checks more than 100 lists. Our IP blacklist check checks seven, including SpamCop, PSBL and DroneBL, and it is IPv4 only. That gap is deliberate. Several of the best-known lists license their free query access for non-commercial use only, or require a registered resolver or a paid key. This site is ad-supported, so we dropped every list whose terms we could not meet, rather than query them anyway. We also health-check each list using the test addresses RFC 5782 defines (a working list must answer for 127.0.0.2 and must not answer for 127.0.0.1), so a dead list shows up as unhealthy instead of producing a false "clean".

The practical upshot: a clean result from any aggregator, ours included, only covers the lists it checked. If mail is being rejected and the bounce message names a specific list, go straight to that list's own lookup page. Large list operators generally run their own lookup page, and bounce messages often include a link to it. Our guide to getting an IP delisted covers what to do once you find a listing.

Reading a message header#

Record checks tell you what your domain publishes. A header tells you what actually happened to one message, which is often the more useful question.

Paste the raw header into our email header analyzer and it lays out the delivery path hop by hop, with the SPF, DKIM and DMARC verdicts the receiving server recorded for that message. The parsing runs in your browser. Looking up the IP addresses along the route is optional, so a header you would rather not send anywhere can stay on your machine. Google's Admin Toolbox also has a Messageheader tool, which is particularly good at showing where delivery delays crept in between hops.

If you have never read one by hand, our walkthrough of how to read email headers explains why the Received: lines run bottom to top.

Sending a real test message#

Every tool above reads DNS or reads a header you already have. Sometimes you want to send a fresh message and see how it lands. Two free services do this well, and both work the same way: they give you an address, you send mail to it from the system you are testing, and they report back.

learndmarc.com, sponsored by URIports, is the clearer teaching tool. It shows the SPF, DKIM and DMARC evaluation step by step, including which domain each check used and whether it aligned with the visible From address. Alignment is the step most people misunderstand, so seeing it laid out for your own message is worth more than any explanation. mail-tester.com works the same way and returns a broader report on the message you sent.

Use these after any change to a sending service. A record check proves the record is valid. A test message proves the service is actually signing with it.

The job MXToolbox still does best#

MXToolbox's SMTP test connects to your mail server over SMTP on port 25, runs a simple open relay test, confirms the server has a reverse DNS (PTR) record, and measures how long it takes to respond. The relay test and the response times cannot be learned from DNS. They need a machine that can open outbound connections on port 25, which many cloud platforms do not allow, ours included.

We do not offer an SMTP conversation test, and we would rather say so than point you at something that only looks like one. If the question is "is my inbound mail server answering properly", MXToolbox is the right tool. What we can check from DNS alone is your inbound TLS policy: the MTA-STS and TLS-RPT checker fetches the policy file, reads its mode, confirms the policy covers your MX hosts, and reports whether TLS failure reports are switched on.

DMARC reports and monitoring#

Once DMARC is published with a rua= address, mailbox providers start sending you daily aggregate reports as compressed XML. Nobody reads them raw. Paid DMARC services exist largely to parse them.

For occasional reading, our DMARC report viewer opens .xml, .xml.gz and .zip reports in your browser without uploading them, and shows who sent mail as your domain, how much passed, and where authentication passed but alignment failed. That last case is usually a forgotten third-party sender. Our guide to reading a DMARC aggregate report explains each field.

What no free tool on this page does is watch for you. Continuous monitoring, alerting and report ingestion across many domains need a service that runs on a schedule and stores history. If you manage several domains and want an email when something changes, that is the point at which paying for a monitoring product, from MXToolbox or a DMARC specialist, makes sense.

The command line is free too#

Every DNS read in this article can be done with dig (or nslookup on Windows). The three queries worth memorising:

• dig MX example.com +short for the mail servers.
• dig TXT _dmarc.example.com +short for the DMARC policy.
• dig TXT selector._domainkey.example.com +short for a DKIM key, once you know the selector.

A blocklist check is a DNS query too: reverse the octets of the IP and append the list's zone, so 192.0.2.50 against SpamCop becomes 50.2.0.192.bl.spamcop.net. An answer means listed, no answer means not listed. The command line answers from whatever resolver your machine uses, though, which can be serving a cached copy. After a change, the DNS propagation checker asks several public resolvers at once and shows what each one returned.

One tool per problem#

• "Is my setup right?" The domain health report, then internet.nl as a stricter second opinion.
• "SPF broke after adding a service." The SPF checker, and count the lookups.
• "This message went to spam." Its header, in the header analyzer.
• "Did my new sender start signing?" A test message to learndmarc.com.
• "Are we blocklisted?" An aggregator first, then the specific list named in the bounce.
• "Is our mail server answering?" MXToolbox's SMTP test.
• "Tell me when something changes." A paid monitoring service.

The single search box is convenient, but knowing which of these questions you are asking gets you to the answer faster. If you are still getting the three authentication records straight, start with our overview of how SPF, DKIM and DMARC work together.