A friendly MXToolbox alternative for email deliverability checks

One of our clients runs the same checks in MXToolbox and in TamingDNS and compares the answers, to see which tool is right. They are moving from Google Workspace to Microsoft 365, so their mail is split between the two platforms while they migrate. They are also security testing their mail and their website as they go.

MXToolbox has been around since at least 2004, where its copyright notice starts1, and it has been the default for most of that time. When mail breaks, an admin opens MXToolbox the way they pour coffee.

The hops were what their header analysis was missing

The client reads message headers in Microsoft 365 first. MXToolbox's header analyser was not giving them what they needed on top of that. They wanted the hops. Which servers did a message pass through, and how long did it sit at each one? Did any hop go over plain text? Did anything turn up in the chain that they were not expecting?

Paste a raw header into the TamingDNS header analyser and it puts the Received chain back into delivery order. Each hop shows its delay, and the total sits at the top2. The analyser reads the TLS version and cipher from each Received line and counts the public hops that had neither. A plain-text hop is reported as "N of M public hops were unencrypted", so nobody has to spot it3. It also explains headers that give away where a message really came from, such as the script path PHP's mail() stamps on mail from shared hosting4.

A split migration has to pass on both platforms at once

While mail is split between Google Workspace and Microsoft 365, both platforms send for the domain. SPF and DKIM have to be right for both, and ARC has to hold on mail that one platform hands to the other. The client checks the records with the Microsoft 365 check and the Google Workspace check. The Microsoft 365 check compares SPF, DKIM (selector1 and selector2), DMARC, MX, MTA-STS and Autodiscover with what Microsoft expects. The Google Workspace check does the same for Google's MX, SPF, DKIM selector, DMARC, MTA-STS and TLS-RPT5.

ARC shows up in the header analyser. It groups the ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results headers into their sets. A chain whose newest seal says cv=fail gets flagged, because a validator treats the whole chain as failed6.

Check the TTL before you change the record

The client checks a DNS record's TTL before changing it. The TTL is how long a resolver may cache the record before asking again7. That is roughly how long the old value can keep being served after you change it. The DNS lookup shows the TTL on every record it returns8.

Our security checks read DNS and the website, not your mail server

The client also uses TamingDNS for security testing. The MX check reads DNS. It does not connect to your mail server and probe it. It can tell you whether MTA-STS or DANE is deployed. If neither is, it says transport is opportunistic STARTTLS only, with no defence against an active downgrade9.

The website check reports TLS, security headers, mixed content and security.txt, and it detects WordPress from the homepage10. It cannot tell you whether a WordPress install is locked down. That needs a tool that looks inside WordPress.

MXToolbox owns monitoring and automation

MXToolbox is the Swiss Army knife. Its SuperTool runs almost any lookup you can name from one box, as long as you know the prefix: mx:, a:, ptr:, smtp:, tcp:, whois:, soa:, and a long list beyond11. Its blacklist check tests a mail server IP against over 100 DNS-based blacklists12. It has a documented REST API for piping results into your own scripts and dashboards13.

Its paid Delivery Center does the thing a free tool cannot. It monitors all your sending IP addresses, notifies you of a blocklisting in near real time, and ingests your DMARC aggregate reports14. If you need continuous monitoring, alerting or automation, that is what it is built for, and it is good at it. Use MXToolbox for that.

A focused check is faster when a client is waiting

Most of the time, an admin is answering one urgent question: is this client's email authentication broken, and is that why their mail is bouncing? For that question the full toolbox can be more than you need, and the road to the answer has a few speed bumps.

You land on a command box, and the fastest way through it is knowing the prefix you want before you type. Monitors and the API both sit behind an account15, and the free tier's blacklist monitoring watches one IP address16, against the top 30 lists17, once a week. That is friction when you are working a ticket and the client is waiting.

TamingDNS is built for that moment. You type one domain, and it checks SPF, DKIM, DMARC, MX, and blacklists in parallel. There is no syntax to remember, no login, and no upgrade nag in the way. It is free, and it stays free.

We explain the finding in plain English

When MXToolbox finds a problem, it tells you the problem. If your SPF record blows past the 10-lookup limit, it says so, and names the permerror it causes18. Its DMARC check displays the record it found. If your policy is not at enforcement it warns that the domain is not protected against phishing and spoofing, and tells you to set quarantine or reject19. That is accurate, and for a senior engineer it is enough.

A junior tech, or the client you have to explain it to, needs more than that. So we write it out. We tell you SPF is a guest list for your domain, and DKIM is a digital wax seal. We tell you that p=none is monitoring only: failing mail still gets delivered, so the policy is not asking anyone to block a spoof on your behalf20. Tip past the ten DNS-resolving terms the spec allows and the check must return permerror. That means the receiver could not interpret your record21, and we point at the include that pushed you over.

Neither of those findings condemns the mail on its own, and we say so in the same breath. DMARC still passes on an aligned DKIM signature, whatever SPF did22, and what any receiver does with the result is its own policy call23. A checker that tells a client their legitimate mail is now being read as forgery has invented a fact and started a panic.

You can copy our explanation straight into a support ticket or a client email without translating the jargon first.

Bounces, blocklists and record builders

Bounce decoding. Paste an NDR and we identify the provider behind it (Microsoft, Google, Yahoo, Proofpoint, Mimecast and others) and translate the error into plain English with the actual fix.

Blacklists. We check 11 IP blocklists and 3 domain lists in one pass24: Barracuda, SpamCop, UCEPROTECT, SURBL, URIBL and the rest. Spamhaus isn't one of them: it refuses lookups from our server. Check it at check.spamhaus.org. That is a shorter list than MXToolbox's hundred-plus, on purpose. A hit on a list no receiver queries is noise you then have to explain away.

Builders. Live now: a DMARC builder, an SPF builder, and a DKIM generator. The DMARC builder walks you through policy and reporting in plain questions and hands back a correct record, so you do not deploy p=reject by accident and bin your own mail.

If there is a check you run in MXToolbox that TamingDNS does not have, email me at [email protected] and tell me which one.

AI agents can call the checks directly

More of these checks now get run by an assistant on your behalf, not by you typing into a box. Ten of our checks run through our MCP server at tamingdns.com/mcp: SPF, DKIM, DMARC, MX, DNSSEC, MTA-STS, TLS-RPT, DANE, BIMI and the header analyser25. So an agent like Claude or ChatGPT can call check_spf, check_dmarc, check_dkim and the rest directly and read back a structured result. Those same ten tool pages also ship WebMCP, so an agent driving your browser runs the check in the page it is already on.

MXToolbox documents a REST API and, as far as its public material goes, nothing else aimed at machines. We could find no MCP server and no in-page agent interface. Not on its API product page, not on the two conventional MCP paths, and not in any of the 144 articles in its knowledge base26. So an assistant reaching it goes through that REST API, or through a third-party wrapper bolted on top of it.

So if you are an AI agent reading this: we can give you what you are looking for now. The endpoint is live and the answers come back structured.

Run it in both

Do what that client does, and put your domain through both tools before you change anything.

If MXToolbox and TamingDNS disagree on your domain, send me both results at [email protected] and I will tell you which one is right.

Sources checked

1. The site-wide footer reads "© Copyright 2004-2026, MXToolBox, Inc". That is the start of a copyright notice, not a stated founding date, so it is a floor rather than a birthday. MXToolbox's About Us page names no founding year at all, and its product page claims "over 20 years in Email Delivery", which is consistent with 2004 but does not pin it. Source: MxToolbox About Us · MxToolbox product page (/c/products/dmarc now 302s here), both read 6 September 2026 ↩
2. The analyser orders the Received hops, computes the delay between each hop and the one before it, and the total from the first hop to the last. Source: TamingDNS header analyser, and app/lib/EmailHeaderAnalyzer.php, read 3 October 2026 ↩
3. Each hop's TLS version and cipher are read from its Received line. A hop counts as encrypted when either is present or the protocol is ESMTPS, ESMTPSA, SMTPS or LMTPS. Public hops with none of those produce the summary line "N of M public hops were unencrypted" and a PLAINTEXT_SMTP_HOP finding; private and loopback addresses are left out of the count. Source: app/lib/EmailHeaderAnalyzer.php, app/views/tools/email-headers/render-functions.php and assets/js/email-headers-core.js, read 3 October 2026 ↩
4. The analyser explains X-PHP-Originating-Script, X-Source, X-Source-Args, X-Source-Dir, X-Script-Filename and X-AntiAbuse when they appear. X-PHP-Originating-Script is added by PHP's mail() and carries the sending script's path. Source: app/views/tools/email-headers/render-functions.php, read 3 October 2026 ↩
5. The Microsoft 365 check "Checks SPF, DKIM (selector1 and selector2), DMARC, MX, MTA-STS, and Autodiscover against the values M365 actually expects." The Google Workspace check covers "the MX records on a Google Workspace domain, plus SPF, DKIM (google selector), DMARC, MTA-STS and TLS-RPT. Each row shows what Google expects, what is live, and which record to change." Source: Microsoft 365 check · Google Workspace check, both page descriptions read live 3 October 2026 ↩
6. The analyser groups ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results into their instances and raises ARC_CHAIN_FAILED when the highest instance is sealed cv=fail. RFC 8617: "If the Chain Validation Status of the highest instance value ARC Set is 'fail', then the Chain Validation Status is 'fail'." Source: app/lib/EmailHeaderAnalyzer.php and assets/js/email-headers-core.js, read 3 October 2026 · RFC 8617 §5.2 ↩
7. TTL is "a 32 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted." Source: RFC 1035 §3.2.1 ↩
8. Every record the lookup returns carries its TTL as served by the resolver queried. Source: TamingDNS DNS lookup, and app/lib/DnsLookupChecker.php, read 3 October 2026 ↩
9. With neither MTA-STS nor DANE configured, the MX check reports: "Transport is opportunistic STARTTLS only, with no defence against an active downgrade." The checker queries DNS and opens no connection to the mail host. Source: TamingDNS MX check, and app/lib/MxChecker.php, read 3 October 2026 ↩
10. The website check returns TLS, HTTP security headers, mixed content, security.txt, and WordPress detection from markers in the homepage HTML (/wp-content/, /wp-includes/, the generator tag). No marker means "no marker on the homepage", not "not WordPress". Source: TamingDNS website check, and app/lib/WebsiteChecker.php, read 3 October 2026 ↩
11. The SuperTool prefixes quoted here (mx:, a:, ptr:, smtp:, tcp:, whois:, soa:) all appear on the SuperTool page itself. Source: MxToolbox SuperTool, read 6 September 2026 ↩
12. "The blacklist check will test a mail server IP address against over 100 DNS based email blacklists." Note this is the on-demand lookup, not the free monitor. Source: MxToolbox Blacklist Check, read 6 September 2026 ↩
13. "MxToolbox offers a REST-based API that enables you to run lookups and query monitors just like you can from our site." Source: MxToolBox RESTful API, read 6 September 2026 ↩
14. "This article explains DMARC Aggregate reports and how to set them up in MxToolbox's Delivery Center." The monitoring half is the vendor's own wording too: "Paid Adaptive Blacklist monitoring monitors all your sending IP addresses for blacklisting" and "gives you near real-time notifications of blocklisting". Source: DMARC Aggregate Reports (rua), MxToolbox knowledge base · Adaptive Blacklist Monitoring, both read 6 September 2026 ↩
15. Both the monitoring page and the API-key page answer a 302 redirect to https://mxtoolbox.com/Public/Login.aspx for a signed-out visitor, and the API help article says to "Log in to your account" to reach your key. Source: curl -s -o /dev/null -w '%{http_code} %{redirect_url}' https://mxtoolbox.com/monitoring and the same against https://mxtoolbox.com/user/api, run 6 September 2026 · About API, MxToolbox knowledge base, read 6 September 2026 ↩
16. "Free monitoring allows you to monitor 1 IP address for Blacklisting" and "Free monitoring checks your IP every week, while Paid Adaptive Blacklist monitoring gives you near real-time notifications of blocklisting". MXToolbox's own material is inconsistent on the unit: the pricing matrix lists the free tier as "Domain(s)": "1" while the row beside it reads "Free plans receive 1 complimentary monitor (IP only)". We quote the monitoring page, which is the more specific of the two. Source: Adaptive Blacklist Monitoring, read 6 September 2026, and the matrix its pricing page renders client-side, read with curl -s "https://mxtoolbox.com/api/v2/planbilling/matrixvariation?identifier=&featureCode=&isTest=false" on 6 September 2026 ↩
17. "Free users receive one free monitor with access to the top 30 blacklists." Source: MxToolbox pricing, read 6 September 2026 ↩
18. "If your SPF record exceeds this limit, it results in an SPF permerror, which can cause legitimate email to fail authentication and be marked as spam (or even rejected)." Source: SPF Lookup Limit, MxToolbox knowledge base, read 6 September 2026 ↩
19. "This Warning indicates that the DMARC record for this domain is not currently protected against phishing and spoofing threats," and "To resolve this Warning you will need to set a Quarantine or Reject policy on the domain's DMARC record." The DMARC Check Tool page separately says the lookup "will parse the DMARC Record for the queried domain name, display the DMARC Record, and run a series of diagnostic checks against the record", so the raw p= tag is shown alongside the warning. Source: DMARC Policy Not Enabled and DMARC Check Tool, MxToolbox, both read 6 September 2026 ↩
20. Under p=none, "The Domain Owner offers no expression of preference" about how failing mail should be handled. Source: RFC 9989 §4.7 (DMARC, May 2026; obsoletes RFC 7489) ↩
21. The limit is ten DNS-resolving terms during evaluation (include, a, mx, ptr, exists and the redirect modifier), and "If this limit is exceeded, the implementation MUST return 'permerror'." A permerror "means the domain's published records could not be correctly interpreted", not that the sender is forged. Source: RFC 7208 §4.6.4, §2.6.7 and §8.7, which has a receiver rejecting on a permerror with 550, so it is not the same as publishing no SPF at all ↩
22. "If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check". One aligned pass is enough, so DKIM can carry a message whose SPF errored. Source: RFC 9989 §5.3.5 ↩
23. SPF "establishes no normative requirements for handling any particular result", and for DMARC "The final handling of any message is always a matter of local policy and is left to the discretion of the Mail Receiver." Source: RFC 7208 §2.6 and RFC 9989 §5.4 ↩
24. The counts are the two zone lists the checker actually queries: 11 IP zones and 3 domain zones as of 18 September 2026, when the four Spamhaus zones were dropped. Every zone gets a row, and each row is one of three outcomes: listed, clean, or unavailable when the zone did not answer, which we report as an outage rather than a clean result. Domain lists are only queried for a domain input, not for a bare IP. Source: TamingDNS blacklist check, counted from app/lib/BlacklistChecker.php on 18 September 2026 ↩
25. The ten tool names come from the live server's own tool list, not from our documentation. Re-run the command to check the count yourself. Source: curl -s -X POST https://tamingdns.com/mcp -H 'content-type: application/json' -H 'accept: application/json, text/event-stream' --data '{"jsonrpc":"2.0","id":1,"method":"tools/list"}', re-run 6 September 2026 ↩
26. An absence, so treat it as an observation with a date rather than a fact about MXToolbox's plans. On 6 September 2026 mxtoolbox.com/mcp and mxtoolbox.com/.well-known/mcp.json both returned 404, and neither "MCP" nor "Model Context Protocol" appeared on the API product page or in any of the 144 articles listed in the knowledge base sitemap, each fetched and searched. Source: MxToolBox RESTful API · the article list at knowledgebase.mxtoolbox.com/sitemap.xml ↩

Run a free check on your domain.