What can you learn from just a domain name?

Best move: treat the domain as a public join key, then read every layer it unlocks in one pass.

Why it works: DNS, the TLS certificate, and the served page are all public and all keyed to that one string. Resolve them together, correlate the results, and one input gives you a five-layer dossier.

Key takeaways

• A domain is a public join key. From it alone, with no keys and no licensed dataset, you resolve infrastructure, tech stack, firmographics, AI stack, and security.
• DNS turns one string into IP, ASN, hosting org, CDN, nameservers, MX, and the email-auth booleans (SPF, DKIM, DMARC) plus the vendor tokens in TXT.
• The TLS certificate’s SAN list leaks sibling domains and subdomains the marketing site never links, because certificate transparency logs are public.
• The served HTML and JavaScript carry both the tech-stack fingerprint and the AI-stack fingerprint (model providers, SDKs, vector stores, orchestration, observability).
• A domain does not reveal traffic volume, revenue, or headcount. For those you still need a traffic panel or a firmographics corpus, and the dossier is honest about that.

What can DNS alone tell you?

DNS is the first layer a domain unlocks, and it needs no login. Resolve the A and AAAA records and you have the IP. That IP maps to an ASN, which names the hosting org (AWS, Cloudflare, Fastly, a regional colo). Nameservers point to the DNS provider and often the CDN in front of the origin. MX records name the email provider (Google Workspace, Microsoft 365, Proofpoint). TXT records carry the email-auth story: SPF lists who may send, a DKIM selector proves the domain signs its mail, and a DMARC record sets the enforcement policy. Those three collapse into booleans you can read at a glance, which is the difference between a domain that is locked down and one that is spoofable.

TXT does more than auth. It carries vendor verification tokens (Stripe, Atlassian, Facebook domain verification, Google site verification), and each token is a small firmographic tell about the tools a company already pays for. None of this requires an API key or a scraped corpus. It is a sequence of public lookups keyed to one string, and it forms the infrastructure layer of the dossier.

What does the TLS certificate reveal?

The TLS certificate is a second public artifact keyed to the domain, and it is one of the highest-signal reads you get for free. The issuer (Let’s Encrypt, DigiCert, Google Trust Services) tells you something about the operator’s tooling and budget. The SAN list tells you far more: it names every domain and subdomain that shares the certificate, which often surfaces siblings, staging environments, and internal tools the public site never links to. Certificate transparency logs publish this by design, so a cert read is a reconnaissance shortcut that OSINT tools like Censys and Shodan built whole products around.

The validity window matters too. Read notAfter and you get the expiry and days_remaining, a small operational tell (a certificate with three days left says something about how the team runs). The certificate also feeds the security assessment alongside the response headers, contributing to the TLS grade that combines with the header grade for an A-to-F score. One domain, one public certificate, and you have half the infrastructure and security picture before you have even parsed the HTML.

What does the served page expose about the tech and AI stack?

Fetch the page and two more layers open at once. The tech stack lives in the loaded scripts, the meta tags, and the response headers: the framework (Next.js, Astro), the CMS (WordPress, Webflow), analytics, chat widgets, payment and ecommerce SDKs. This is the commoditized BuiltWith-style layer, cheap to mirror, and it is not the headline.

The AI stack is the unclaimed axis, and it is deeper than a homepage keyword scan. The signatures survive minification: model-provider hostnames (Anthropic, OpenAI, Gemini, Cohere, Mistral), an SDK import (Anthropic SDK, OpenAI SDK, Vercel AI SDK), an orchestration library (LangChain, LlamaIndex, Haystack, CrewAI), a vector-store client (Pinecone, Weaviate, Qdrant, Chroma, Milvus), an observability shim (Helicone, LangSmith, Langfuse). Add the standards checks: an llms.txt file classified as standard or technical, a .well-known AI file, an advertised MCP endpoint. Each distinct signal group counts toward an ai_readiness score out of six, capped at 1.0, and resolves to a verdict of shipping, experimenting, or none. Where a static crawl cannot reach a client that only initializes after a user action, an optional JS render fills the gap, and the dossier flags what stayed out of reach.

Where do firmographics come from without an API?

You do not need an Apollo or ZoomInfo lookup to learn who a company is, because the page describes itself in machine-readable markup. JSON-LD structured data names the organization, its logo, its address, and sometimes its founders. Open Graph and meta tags give the description and the vertical. The footer and contact page carry emails, phone numbers, and links to social profiles. The sitemap and robots file hint at the size and shape of the property.

This is the company telling you who it is, which is different from a corpus telling you who it was at last enrichment. The tradeoff is honest: a firmographics vendor covers companies whose sites are thin, and it carries fields (headcount, revenue band) that no page exposes. What the domain gives you is current and self-declared, pulled from the same crawl that produced the tech, infra, AI, and security layers. Because it comes from one pass, the firmographics arrive already correlated with the stack, so the “who” and the “what they run” describe the same origin rather than two lookups you have to reconcile by hand.

What can’t a domain tell you?

Plenty, and pretending otherwise is where cheap tools lose credibility. A domain does not carry traffic volume. For that you need a measurement panel like SimilarWeb. It does not carry revenue or headcount. Those live in a firmographics corpus like Apollo, ZoomInfo, or Clearbit, built from filings and contributed data, not from a page read.

The crawl has limits too. A static fetch plus an optional JS render can miss components that are fully server-side, proxied through a reverse proxy that hides the origin stack, or initialized only after a click. A domain sitting behind a CDN and an edge worker can mask what runs at the origin. A parked domain resolves in DNS but serves nothing, so the tech, AI, and firmographic layers come back thin. The right response is to report the gap, not to guess past it. Every Bassethound dossier marks what it could not reach (how_detected and evidence on every detection, an explicit note when a render was needed), so you know the difference between “not present” and “not observable from here.”

Bassethound perspective

Most tools that read a domain hand you one layer. BuiltWith and Wappalyzer give you the tech stack. Censys, IPinfo, and Shodan give you the infrastructure. Apollo and ZoomInfo give you the firmographics. Each is good at its slice, and each leaves the join to you.

Here is the conviction a competitor would dispute: fan-out is not the product, fusion is. An agent that wants the correlated picture from five single-layer MCPs has to make five calls, hold five schemas, and stitch the result itself, paying latency and losing the join between (say) a Pinecone client and an OpenAI hostname on the same origin. That correlation is the whole point, and you cannot rebuild it after the fact without repeating all five calls. Bassethound does the investigation inside one request and returns the five layers already correlated, keyless, because we own the crawl. The domain is the only input. One correlated dossier comes back, and the tech stack, the infra, the firmographics, the AI stack, and the security grade all trace to the same company before you read the first line.

Sources

• MDN Web Docs, HTTP headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• DMARC (RFC 7489): https://datatracker.ietf.org/doc/html/rfc7489
• llms.txt specification: https://llmstxt.org
• Model Context Protocol: https://modelcontextprotocol.io
• Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org