HostMortem Documentation
HostMortem runs ten diagnostic panels against any domain or IP address in parallel. Each panel checks a different dimension of host health — from DNS propagation to email deliverability to security posture. This reference covers what each panel checks and how to interpret what you find.
DNS Records
Field Notes
When you type a domain name into a browser, the Domain Name System (DNS) is the phone book that translates it into an IP address. This panel fetches all the DNS records published for your domain — the IPv4 and IPv6 addresses serving your website (A and AAAA records), the mail servers that accept email for your domain (MX records), nameserver assignments (NS), text-based verification tokens and policies (TXT), and the domain's administrative metadata (SOA).
It also checks whether the domain is signed with DNSSEC (a security extension that cryptographically verifies DNS answers haven't been tampered with), whether your nameservers are hosted on different network subnets for redundancy, and whether Cloudflare's and Google's DNS resolvers agree on your A record — a quick propagation sanity check.
Lab Report
Queries 8 record types (A, AAAA, MX, NS, TXT, CNAME, SOA, CAA) via Cloudflare's DNS-over-HTTPS endpoint (cloudflare-dns.com/dns-query) with Accept: application/dns-json. DS and DNSKEY records are queried in the same batch to detect DNSSEC signing. Nameserver IPs are resolved and their first two octets compared across up to 4 NS entries to flag /16 subnet diversity.
Propagation check: queries the A record against Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9) DoH resolvers in parallel. Resolvers that return empty (some block data center IPs) are marked unavailable and excluded from the consistency comparison. For IP inputs, a PTR (reverse DNS) lookup is performed instead.
SSL / TLS
Field Notes
The padlock in your browser's address bar means the connection is encrypted with TLS (Transport Layer Security, commonly called SSL). This panel verifies your site serves HTTPS, checks the TLS certificate for its issuer and expiry date, and tests two hardening features: HSTS (HTTP Strict Transport Security), which tells browsers to refuse any unencrypted connection to your domain, and HSTS preload, which bakes that rule into browsers themselves so it takes effect even on the first ever visit.
Results are graded A–F based on how many of these protections are in place.
Lab Report
Issues an HTTPS HEAD request (following redirects) and captures the strict-transport-security response header. Certificate data is fetched from the crt.sh certificate transparency log API (crt.sh/?q={domain}&output=json), sorted by not_before date descending, returning the most recently issued entry. HSTS preload status is queried from hstspreload.org/api/v2/status.
Note: crt.sh may be unavailable from cloud data center IPs. The panel still grades based on live HTTPS and HSTS data.
HTTP Headers
Field Notes
Every time a browser loads a page, the server sends invisible metadata alongside the HTML content. Security-related response headers tell the browser how to protect the visitor — blocking your site from being embedded in iframes on other domains (clickjacking), controlling which scripts can run (CSP), and preventing browsers from guessing content types in ways that can expose vulnerabilities. This panel audits eight of these headers and grades your configuration A–F.
Lab Report
Fetches the URL with a standard GET request and audits the following response headers. Missing headers score 0; presence earns the stated points.
Also checks for a security.txt file at /.well-known/security.txt and /security.txt per RFC 9116, which lets security researchers report vulnerabilities responsibly.
CORS
Field Notes
CORS (Cross-Origin Resource Sharing) governs whether JavaScript running on one website is allowed to read responses from another. If you run a public API, misconfigured CORS can either break legitimate integrations (too restrictive) or expose authenticated data to any website on the internet (too permissive). This panel simulates what a browser does when a web app on another domain tries to talk to yours.
Lab Report
Sends an OPTIONS preflight request with Origin: https://cors-probe.hostmortem.io, Access-Control-Request-Method: GET, and Access-Control-Request-Headers: Content-Type. Records the preflight HTTP status and all Access-Control-* response headers. Then sends a plain GET request to the same URL with the probe origin and records the CORS headers from that response.
*)Flagged when Access-Control-Allow-Origin is *trueIP Info
Field Notes
Every domain resolves to at least one IP address. This panel shows you where that server physically is, which organization or ISP controls the IP block, the Autonomous System Number (ASN) that identifies the network owner, and — importantly — whether the IP is a Tor exit node. Tor exit nodes are the last relay in the Tor anonymization network, commonly used to bypass geo-restrictions or obscure the origin of automated requests.
Lab Report
Resolves the domain to an IPv4 address via DoH if a hostname is provided. Queries ipapi.co/{ip}/json for geolocation data (country, region, city, coordinates, timezone), organization name, ASN, and reverse hostname. Performs a Tor exit node check in parallel by querying {reversed-ip}.dnsel.torproject.org A — a response of 127.0.0.2 indicates the IP is a confirmed Tor exit node per the Tor Project's DNS-based exit list.
Robots / Sitemap
Field Notes
The robots.txt file is a plain text file at the root of every website that tells search engine crawlers (Googlebot, Bingbot, etc.) which pages they're allowed to index and which to skip. The sitemap XML file tells them which pages exist and when they were last updated. This panel fetches both and shows you exactly what web crawlers see when they visit your site — critical for diagnosing why pages might not be indexed, or for verifying that sensitive areas are properly blocked.
Lab Report
Fetches /robots.txt and records the HTTP status code and full body text (up to 8 KB). Parses all Sitemap: directives from the robots.txt body. Checks the first 3 referenced sitemaps (or falls back to /sitemap.xml and /sitemap_index.xml) and records each sitemap's HTTP status. Returns robotsStatus, robotsTxt body, discovered sitemap URLs, and per-sitemap status codes.
Email Deliverability
Field Notes
Email authentication records tell receiving mail servers that messages from your domain are legitimate — not spam or phishing. Without them, your emails may land in junk folders or never arrive. This panel checks every email authentication standard in use today and gives your domain a deliverability score from 0 to 100.
- SPF — lists which servers are authorized to send email as your domain.
- DMARC — instructs receiving servers what to do with messages that fail SPF or DKIM (none, quarantine, or reject). The
rejectpolicy gives the highest score. - DKIM — a cryptographic signature attached to outgoing messages, checked by querying common selector names used by major email platforms.
- BIMI — lets your brand logo appear next to messages in supporting email clients (requires DMARC at reject/quarantine first).
- MTA-STS — enforces TLS encryption on connections between mail servers, preventing downgrade attacks.
- TLS-RPT — enables delivery failure reports for MTA-STS issues.
- RBL — checks your sending IP against four real-time blacklists (Spamhaus ZEN, Barracuda, SpamCop, SORBS).
Lab Report
All checks are DNS-based — no SMTP connections are made. Queries run in parallel:
all mechanism_dmarc.{domain}; parsed for p= and pct={selector}._domainkey.{domain} — 20 selectors checkeddefault._bimi.{domain}_mta-sts.{domain} + GET https://mta-sts.{domain}/.well-known/mta-sts.txt_smtp._tls.{domain}_25._tcp.{domain}{reversed-ip}.{rbl-suffix} for each blocklistScore: SPF present=15pts (+5 if -all, +2 if ~all), DMARC=15pts (+10 if reject, +5 if quarantine), DKIM=20pts, MTA-STS=10pts, TLS-RPT=5pts, BIMI=5pts, RBL clean=15pts.
WHOIS / RDAP
Field Notes
The WHOIS record shows who registered a domain, when it was registered, when it expires, and which nameservers are authoritative for it at the registrar level. It's how you verify a domain's age, find the registrar to report abuse, or confirm that the nameservers in the WHOIS record match the ones actually answering DNS queries. IP addresses return the organization that controls the IP block.
Lab Report
Uses the RDAP (Registration Data Access Protocol) — the modern successor to WHOIS — which returns clean JSON rather than the inconsistently formatted plain text WHOIS responses. Queries TLD-authoritative RDAP servers directly to avoid third-party proxies that block data center IPs:
rdap.verisign.com)rdap.publicinterestregistry.org)rdap.nic.io)rdap.nic.google)rdap.arin.net)Performance
Field Notes
Time to First Byte (TTFB) measures how long a server takes to respond to the very first byte of a page request. It's the clearest single indicator of backend performance — high TTFB usually means slow server-side processing, database queries, or geographic distance. This panel also identifies whether a CDN is serving the content (which dramatically reduces TTFB for global visitors) and whether responses are compressed to reduce transfer size.
Lab Report
Issues a timed GET request and measures Date.now() before and after. CDN detection inspects response headers: cf-ray (Cloudflare), x-served-by containing "cache" (Fastly), x-akamai-transformed (Akamai), x-amz-cf-id (CloudFront), x-varnish (Varnish), server prefix (nginx/Apache). HTTP version is inferred from cf-ray presence and via headers. Compression is read from content-encoding.
Security Overview
Field Notes
This panel rolls up signals from across all other checks into a single security score (0–100) and letter grade. Think of it as a credit score for your domain's security posture — one number that captures HTTPS, HSTS, DNSSEC, security header quality, responsible disclosure setup, and blacklist status. For IP addresses, it runs a blacklist-only audit against four real-time blocklists.
Lab Report
Runs five checks in parallel: HTTPS HEAD request, DNSSEC (DS record), HSTS preload status, security header grade, and security.txt discovery. RBL check resolves the domain to an IP then queries four blocklists. All checks are combined into a composite score:
How HostMortem Works
All ten panels run in parallel the moment you submit a target — there is no sequential queue. Most diagnostics complete in under two seconds.
No agents, no installs
HostMortem is entirely browser-based. Nothing is installed on your machine, and nothing is installed on the server being checked. Every diagnostic is a read-only probe — the target never knows it's being examined, and no changes are made anywhere.
Results are live and uncached. Run the same domain twice and you get two fresh snapshots — useful for confirming that a DNS change propagated or that a newly deployed certificate is visible.
Data sources
Each panel draws from public, authoritative sources:
Common Questions
My TTFB is over 500ms — what do I look at?
Start with the CDN row in the Performance panel. If it shows your server directly (nginx, Apache) instead of a CDN like Cloudflare, every visitor's request travels all the way to your origin server, adding geographic latency on top of any server-side processing time. Putting a CDN in front of a slow origin often cuts TTFB by 60–80% for international visitors before you touch a line of server code.
If you're already behind a CDN, high TTFB usually means your origin is doing expensive work before it can send the first byte — slow database queries, heavy framework bootstrapping, or no page-level caching.
My domain isn't DNSSEC-signed — does that matter?
DNSSEC prevents a class of attack called DNS cache poisoning, where an attacker tricks resolvers into serving fraudulent IP addresses for your domain. For most sites the practical risk is low — DNSSEC adoption is still uneven and the attack requires network-level access. That said, for domains handling sensitive data (banking, healthcare, government) DNSSEC is increasingly expected. Most registrars now offer it for free.
DMARC shows policy: none — is that a problem?
A none policy means DMARC is configured for monitoring only — receiving mail servers take no action on messages that fail authentication. It's a common starting point when you first set up DMARC and are still auditing your sending sources via the rua reporting address. Once you're confident all legitimate senders pass SPF and DKIM, you should graduate to quarantine (spam folder) and eventually reject, which gives you the full spoofing protection DMARC was designed for.
Why are my DKIM selectors not detected?
HostMortem checks 20 common DKIM selector names used by major email platforms (Google Workspace, Microsoft 365, Mailchimp, SendGrid, Postmark, and others). If your provider uses a custom selector name, it won't appear in the results — the selector is simply not on the probe list. This is not a deliverability issue; it just means the automated check didn't find the record by name. Your email is still signing correctly.
The WHOIS panel shows an error for my .io domain
The .io registry's RDAP server (rdap.nic.io) is operated by the Internet Computer Bureau and has a history of intermittent availability — particularly from cloud data center IPs, which is where HostMortem's diagnostics run. If the panel shows a registry error, wait a few minutes and run the diagnostic again. The underlying domain registration data is unchanged; it's a retrieval issue with the .io registry endpoint, not a problem with your domain.
My security score is lower than I expected
The two biggest contributors to a high security score are HTTPS with HSTS (30 pts combined) and a strong security header grade (up to 25 pts). If you're missing grade A on headers, the most common gaps are Content-Security-Policy (3 pts — the hardest to configure correctly) and Permissions-Policy. The Security panel shows the exact point breakdown, so you can see precisely which checks you're passing and which you're not. HSTS preload (5 pts) and a clean security.txt file (10 pts) are quick wins that many sites overlook.
What does "RBL listed" mean for my domain?
RBL (Real-time Blackhole List) results reflect the IP address your domain resolves to, not the domain name itself. If your IP is listed on a blocklist, mail servers receiving email from that IP may reject or junk-folder it regardless of your SPF, DKIM, and DMARC setup. Shared hosting is a common cause — one tenant's spam gets the IP listed, affecting all domains on that server. Contact the blocklist operator (Spamhaus, Barracuda, SpamCop, or SORBS) to request a removal once the underlying issue is resolved.
My robots.txt looks fine but my pages aren't indexed
HostMortem verifies that robots.txt is reachable and shows you the exact rules Googlebot reads. If the file looks correct but indexing is still an issue, the culprit is usually elsewhere — a noindex meta tag or X-Robots-Tag response header on specific pages, a sitemap that Google hasn't discovered or validated, or a crawl budget issue on large sites. The Headers panel will show you the raw response headers for the homepage; page-level noindex requires checking individual URLs through Google Search Console.