Tools

Thirty-three checks that run from this server and show you what it actually saw — DNS, delivery, sender authentication, certificates, routing, and the calculators a network engineer reaches for daily. No account, no queue, no upsell.

Which one you want

Mail is not arriving

Start with MX & mail server: it resolves the exchangers and then actually connects to each one, so you learn whether the host answers, what it announces, and whether it offers STARTTLS. A perfect DNS record in front of a server that refuses connections is a common and very quiet failure.

Then SPF, DMARC and DKIM. SPF is counted against the ten-lookup limit, which is the single most frequent reason a record silently stops working as a business adds services. DMARC is read back tag by tag, including whether the policy is p=none — which collects reports but protects nothing.

When you have the message itself, the email header analyser is faster than all of them. Paste the raw headers and it reads the route back to you: every server that handled it, how long the message sat at each one, what the receiving system concluded about SPF, DKIM and DMARC, and the earliest public address in the chain. A four-minute gap between two hops is greylisting; an authentication verdict written by the receiver settles an argument that guessing cannot.

Mail arrives, but lands in spam

Blacklist check queries twelve major blocklists and shows the return codes. Reverse DNS matters more than most people expect: a sending address with no PTR, or a PTR that does not resolve back to the same address, is penalised or rejected outright by large receivers.

MTA-STS & TLS-RPT is the modern half of this. It reads the policy record, fetches the policy file behind it, and — the part that catches people — checks whether the policy still lists the mail servers that are actually in DNS. After a mail migration, a policy naming the old hosts causes every enforcing sender to refuse delivery, with no warning unless TLS reporting is also configured. BIMI covers the last step: the logo record, the SVG itself, and the DMARC policy it depends on.

A domain change has not taken effect

DNS propagation asks twelve public resolvers, on five continents, the same question at once and compares what comes back. If they all agree, the change has landed and the problem is somewhere else. If they disagree, you are either waiting out a TTL or one authoritative server is serving something different — and the delegation trace tells you which.

That trace starts at a root server, follows the referral to the registry, and then asks every one of your nameservers directly, with recursion off. It reports whether each one considers itself authoritative and which SOA serial it is serving. Two nameservers with different serials means a zone transfer is failing, and that is usually invisible until something breaks. It also compares the registry’s delegation against the zone’s own NS records — resolvers follow the registry, so a nameserver listed only in the zone is receiving no traffic at all.

DNSSEC answers the three questions separately: is the zone signed, does the parent publish a DS record linking to it, and does a validating resolver accept the chain. A signed zone with no DS record is doing no work. A DS record with no matching key takes the domain off the internet for everyone using a validating resolver — that failure is total, and it is the reason DNSSEC is rolled back as often as it is rolled out.

A site is down, slow or insecure

HTTP headers follows the redirect chain and lists everything the server returned. Security headers grades the same response and, for each header that is missing, says what it would have prevented — these are configuration rather than code, so they are usually the cheapest security work available. TLS certificate gives the issuer, the validity window, the days remaining and the alternative names, plus the protocol and cipher actually negotiated; expiry is still one of the most common causes of a sudden outage.

Load timing splits a request into connect, TLS handshake, server thinking time and transfer. That split is the whole diagnosis: a slow handshake is a certificate or protocol problem, a slow first byte is your application, and a slow tail is size or bandwidth. robots.txt & sitemap reads what you are telling crawlers and then opens the sitemap you advertised, which is more often broken than anyone expects.

Working on the network itself

Subnet calculator handles IPv4 and IPv6: network, broadcast, usable range, wildcard mask, binary, and what you get if you divide it further. ASN & routing shows which autonomous system announces an address and the exact prefix carrying it — the route another network would install to reach you. IP location adds who runs the network and whether the address belongs to a data centre, a VPN or a mobile carrier, which is often the real question behind a log entry.

Multicast planner is the one that is hard to find elsewhere. It classifies a group’s scope, says whether routers will forward it, and shows the Ethernet address it maps to — along with the thirty-one other groups that map to the same one, because only twenty-three of the twenty-eight group bits survive the translation. Two groups chosen a bit apart can deliver each other’s traffic to hosts that never joined, and that is a difficult afternoon if you find it in production rather than here.

MAC address lookup identifies the manufacturer from a local copy of the IEEE registry, flags locally administered addresses, and derives the IPv6 interface identifier. Cisco type 7 reads back the obfuscated passwords in a configuration — it is reversible by design, has been for decades, and seeing that in one click is more persuasive than being told.

Developer odds and ends

JWT decoder, hash generator, encode / decode, cron expression and timestamp converter. The cron tool is worth a mention: as well as translating the line into English and listing its next runs, it warns when both day fields are restricted, because cron treats that as either rather than both — a job intended for the first Monday of the month that quietly runs every Monday and every first.

How these run, and their limits

• They run from this server, not from your browser, so the result is what a host on the public internet sees — which is usually the view that matters.
• DNS comes from public resolvers, never from this server’s own. Most lookups go over DNS-over-HTTPS; propagation and delegation speak DNS directly to a named server over TCP, because those two checks are meaningless through a resolver. A local resolver that filters, caches badly or simply fails would make every answer quietly wrong, and you would have no way to tell.
• Private and reserved addresses are refused. Every target is resolved before anything connects, and anything landing on RFC 1918, loopback, link-local, carrier-grade NAT or other reserved space is rejected. Redirects are re-checked at every hop rather than followed blindly. A public diagnostic form that will connect anywhere is a window into the network the server sits on, and this one deliberately is not.
• Twenty checks per visitor every ten minutes for anything that connects somewhere. The calculators and decoders contact nothing at all, so they are not counted and not limited.
• Reachability uses TCP, not ICMP, on a fixed list of service ports — it is not a port scanner. A TCP handshake is also the more honest test: plenty of well-run hosts drop pings on purpose, so a silent ping proves very little.
• Nothing pasted here is stored. Headers, tokens and certificates are parsed to build the response and then discarded. Even so, a JWT is a live credential and a private key is a secret — neither belongs in any web form, this one included.
• Nothing here is authenticated, so the checks see what any stranger on the internet sees. That is the point: it is the same view an unfamiliar mail server or browser has of you.

Something here you need at a scale these forms will not cover, or a check that is missing? Tell me what you are diagnosing.