Announcing SSL Checker and MX Records Check
Published Apr 15, 2026 by Product Team
We just added two new mini tools to TotalWebTool: SSL Checker and MX Records Check.
That is a small release on paper, but it targets two failure modes that are rarely small in practice. A broken certificate chain can damage trust immediately. A bad MX setup can quietly send inbound mail to the wrong place, or nowhere useful at all. For teams that depend on contact forms, sales inboxes, quote requests, and lead notifications, those are not edge cases. They are revenue and response-time problems.
Why These Two Checks Matter
Certificate and mail routing issues often sit in the gap between "looks fine in DNS" and "works in production."
On the TLS side, what matters is the chain your server actually presents to a client. Let's Encrypt's documentation explains the point clearly: the browser validates signatures from the end-entity certificate through one or more intermediates up to a trusted root, and presenting the full chain helps the client validate trust without having to fetch missing intermediates itself. (Let's Encrypt: Chains of Trust)
On the mail side, MX records are what direct a domain's email to the servers responsible for receiving it. Google describes MX records as the DNS records that route a domain's email to the servers hosting the domain's user accounts, and notes that multiple MX records can exist with different priorities. If the highest-priority destination cannot accept delivery, lower-priority destinations are used next. (Google Workspace Help: DNS basics, RFC 5321)
That is why these checks matter operationally. They help answer two practical questions:
- what certificate chain are clients really seeing right now
- where will inbound email actually try to go, and is anything there answering like an SMTP server
SSL Checker: See the Chain You Are Actually Serving
Our new SSL Checker opens a real TLS connection server-side and returns the live certificate chain from leaf to root.
It is built to show the details people usually end up hunting for across several tools:
- TLS authorization status and any authorization error
- negotiated protocol and cipher
- each certificate in the returned chain
- common name, organization, issuer details, validity window, serial number, and SHA-256 fingerprint
That matters because many TLS issues are not really "certificate exists" problems. They are chain, issuer, or deployment problems:
- a renewed certificate is live on one edge but not another
- an intermediate is missing after a migration or proxy change
- the certificate is valid, but not for the hostname people think they deployed
- the leaf certificate changed, but the served fingerprint does not match what the team expected
Seeing the chain from the leaf certificate to the self-signed root makes troubleshooting faster. It also makes reviews with vendors, hosts, or infrastructure teams much more concrete because you can point to the exact certificate being served instead of debating assumptions.
MX Records Check: Validate Mail Routing Before Leads Go Missing
The new MX Records Check resolves the published MX records for a domain, sorts them by priority, and can optionally probe each mail exchanger for a live SMTP banner.
That gives you a faster read on whether a domain is plausibly configured to receive mail the way you expect.
RFC 5321 requires SMTP senders to sort MX records by preference, with lower numbers being more preferred, and to try alternate destinations for reliable delivery when multiple valid targets exist. The same RFC also defines the connection greeting a receiver normally sends when the connection is established: a 220 "Service ready" reply. (RFC 5321)
In plain terms, this tool helps you confirm:
- whether MX records exist at all
- which hosts are published as inbound mail exchangers
- which priority order they will be attempted in
- whether a probed host answers like an SMTP service on port 25
For client work, that matters more than many teams realize. If inbound mail is misrouted, unreachable, or still pointing at an old provider, the impact often shows up first in the "small" workflows:
- website form notifications
- sales and lead-routing inboxes
- appointment or quote request handling
- password resets and operational alerts
Google's guidance on MX migrations explicitly warns that MX changes can lead to email bounces and disruptions while records propagate or when accounts and routing are not fully prepared. (Google Workspace Help: Avoid issues when changing MX records)
For agencies and small teams, this is often the difference between "mail should be working" and "we confirmed at least one published exchanger is reachable right now."
What These Tools Actually Verify
Both tools are deliberately practical, but they do different jobs.
SSL Checker verifies what the remote endpoint is actually presenting during a live TLS handshake.
MX Records Check verifies the published MX destinations and, when probing is enabled, whether those hosts answer with an SMTP-style banner.
That second point is important. An MX probe is not a full deliverability or inbox-placement test. It does not prove that every mailbox exists, that spam filtering will accept a message, or that SPF, DKIM, and DMARC are all configured correctly. What it does do is validate the first layer of mail handling: are the records there, do they point somewhere sensible, and is at least one published destination reachable as a mail server.
That is exactly the layer you want to test when a client says, "We are not receiving lead emails," and nobody is yet sure whether the problem is DNS, mail hosting, application sending, or mailbox-side filtering.
Where They Fit Best
These two mini tools are especially useful during:
- domain and DNS cutovers
- email provider migrations
- TLS renewals and certificate replacements
- CDN, load balancer, proxy, or hosting changes
- post-launch checks for forms, notifications, and transactional flows
They also fit well as low-friction checks before escalating to a larger incident review. In many cases, the fastest path is to confirm the chain, confirm the MX targets, and confirm whether a live SMTP service is answering before you start debugging application code.
The Bottom Line
SSL and mail routing issues are classic examples of infrastructure problems that look small until they affect trust, conversions, or response time.
SSL Checker gives you a clean view of the certificate chain your server is actually presenting.
MX Records Check gives you a fast read on whether inbound mail routing is published correctly and whether a mail exchanger is reachable.
If you manage websites for clients, run lead-driven forms, or support production launches, those are two checks worth having close at hand.