BuiltWith Shows the Front End. DNS Shows the Back Office.

You click the icon in the browser toolbar and a panel slides down the side of the screen. React. Cloudflare. Google Tag Manager. Stripe. Segment. A chat widget. Eleven seconds, no login, no API key, and you now know more about that company's website than most of the people who work there do.

Then somebody in the meeting asks a different question. Who filters their inbound mail? Which platform signs their outbound mail? Which certificate authority are they willing to let issue for the domain? Who actually runs their DNS?

The panel has nothing to say about any of it. The tool is not careless; it is doing exactly what it was built to do, and doing it well. None of those things ever renders in a browser.

That gap is the whole of this article. It cuts both ways, harder than you would expect.

Two instruments, two measurements

A page-based profiler loads a URL and reads what the browser receives. A DNS-based profile asks the domain's authoritative nameservers what the organisation has published about itself. Same company, two entirely different organs, and the results overlap far less than the phrase "tech stack" suggests.

The fair thing first, before the argument below can be mistaken for a sales pitch. Page-based detection is better than DNS at most of what people actually mean when they say tech stack. Front-end frameworks. Analytics. Tag managers. Ad tech. A/B testing. Ecommerce platform. Payment widgets. Chat widgets. CDN, web server, hosting. The CMS, down to its version number. None of that leaves a trace in DNS. Not a partial trace, not a weak one. None.

If your question is "what is this website built with", a page-based profiler is the right instrument and DNS is the wrong one. Keep that in mind through everything below.

How page-based detection actually works

BuiltWith describes its method in one sentence on its own FAQ, and it is a better description than most technical write-ups manage:

"Every website gives off 'signals' that they are using a particular technology. We can track these signals and determine if a site is using a particular web technology from it."

— BuiltWith FAQ, BuiltWith

The same FAQ states that BuiltWith builds the dataset by indexing the internet itself rather than buying data from third parties, and that it aims to cover 100% of the internet by registered domain. The scale it publishes for that is worth sitting with. On its Global Data Coverage page, as those counters stood when we read them in August 2026, BuiltWith reported 520,417,909 root domains, 14,172,228,665 web pages and 17,701,530,116 technologies across 6,047 top-level domains, with infrastructure performing at least 8.1 billion GET requests per month.

Those are the vendor's own live-updating counters, undated on the page, and they are a coverage claim rather than an accuracy claim. Treat them as such. But they make a point no DNS-only method can answer: crawling the web at that volume is a large industrial undertaking, and nothing you can do with dig operates at that scale.

The signals themselves are written down. The open fingerprint definitions continued from Wappalyzer's public set are a JSON file anybody can read, which makes them the best available answer to what a page profiler is matching on. The root schema states its purpose plainly:

"This schema defines the information related to web based technologies for the purposes of identification (finger printing)"

— webappanalyzer schema.json, enthec/webappanalyzer on GitHub (open-source continuation of the Wappalyzer fingerprint set)

The schema defines the matchable fields and the project README documents what each one means. Paraphrasing that field reference rather than quoting it: scriptSrc matches the URLs of JavaScript files; scripts matches inside JavaScript source; js matches JavaScript properties present on the page; headers matches HTTP response headers; cookies matches cookie names and values; meta matches HTML meta tags; dom matches query selectors; css matches CSS rules; text matches plain text; url matches the full page URL; xhr matches the hostnames of XHR requests; robots matches the contents of robots.txt; probe requests a URL to test whether something exists; certIssuer matches the SSL certificate issuer; and dns matches DNS records. There are also implies, requires and excludes relationships, a deprecated html field, and metadata such as cats, cpe, oss, saas and pricing.

Here is one real definition, so the abstraction has something under it. Segment, an analytics and customer-data platform, is fingerprinted like this:

Read that last line again.

The strawman, killed with a primary artifact

There is a comfortable story in which page-based profilers look at web pages, DNS-based tools look at DNS, and never the twain shall meet. It is not true, and the evidence against it sits in a public repository.

The Segment fingerprint above matches a DNS TXT pattern, segment-site-verification, alongside its script and JavaScript signals. The Salesforce definition does the same thing across a wider spread of layers:

One vendor, one fingerprint object. A cookie name, an HTML pattern, six JavaScript properties, a category identifier of 53 (which the project's categories file maps to CRM) and a regular expression matched against the domain's TXT records. The dns field is not a curiosity bolted onto the edge of the schema. It sits in the schema proper, it is documented, and real definitions use it. You can read the Salesforce entry yourself in src/technologies/s.json.

The honest position is not a binary. The good page-based tools already know DNS carries vendor signal, and they already read some of it. What differs between the two methods is emphasis and depth: how much of the zone gets read, how results are attributed, and where the crawl budget is pointed. That is a less dramatic claim than a comparison piece usually makes, and it is the one the evidence supports.

Wappalyzer's commercial index states that it tracks 8,077 web technologies across 106 categories. That is the vendor's own published count, undated on the page, and a different artifact from the open definitions quoted above. Two versions of the same lineage, maintained separately. Nothing sinister in that; it is a reminder to say which artifact you mean.

What each method is better at

Here is the accounting, laid out so you can see where each instrument earns its keep. Roughly half of these rows belong to the page method, and that is not a courtesy. It is the shape of the evidence.

Layer	Page-based detection	DNS-based profiling	What the signal evidences
Front-end framework and JS libraries	Observes — script URLs, JavaScript properties, DOM selectors	Nothing	The page loaded that resource on the day it was crawled
Analytics and tag management	Observes — script src, JavaScript properties, XHR hostnames	Occasionally, where the vendor also requires a TXT token	A tag was present in the delivered page
Ad tech and A/B testing	Observes — third-party script and request patterns	Nothing	Calls made by the rendered page, at crawl time
Ecommerce platform and payment widgets	Observes — cookies, DOM selectors, script src	Nothing	A public surface includes that vendor's code
CDN, web server, hosting	Observes — HTTP response headers	Partially, from delegation targets, with much less specificity	Which infrastructure served that particular response
CMS and its version	Observes — meta tags, paths, robots.txt contents	Nothing	An artefact the deployment happened not to remove
Inbound mail gateway	Rarely	Observes — MX	Mail for the domain is pointed at that operator
Authorised outbound senders	Rarely	Observes — SPF include: targets	Someone authorised that sender. Not usage, spend or a contract
DKIM signing infrastructure	No	Observes — keys under _domainkey, if the selector name is known	A signing key was published under a guessable name
SaaS onboarding / domain verification	Occasionally — some fingerprints carry a dns TXT pattern	Observes — TXT tokens	A verification step was completed once and the record left in place
DNS operator	No	Observes — NS	Which hosts are authoritative for the zone
Certificate authority	Observes the issued certificate's issuer, from TLS	Observes the authorised issuers, from CAA	Two genuinely different facts — see below

The DNS rows rest on record definitions older than most of the companies being profiled. RFC 1035 defines the MX exchange field as "a host willing to act as a mail exchange for the owner name" (§3.3.9) and the NS field as "a host which should be authoritative for the specified class and domain" (§3.3.11), and gives TXT no semantics at all beyond character strings (§3.3.14), which is precisely why vendors were able to colonise it for verification tokens. SPF's include: mechanism exists to let "one domain ... designate multiple administratively independent domains" (RFC 7208, §5.2), and administratively independent is another way of saying somebody else's company. DKIM subdivides a signing domain's key namespace using selectors, all stored under a _domainkey subdomain (RFC 6376, §3.1 and §3.6.2.1). Companion posts on this site work through the SPF mechanics, the MX gateway hostname patterns and DKIM selector discovery properly; this article deliberately does not re-derive them.

Three smaller DNS-side signals, for completeness. RFC 2782 SRV records publish the location of a service, including its port and target host, at a predictable underscore-prefixed name. A DMARC record's reporting address can name an analytics vendor, under RFC 9989, the current DMARC core specification published in May 2026, which obsoletes RFC 7489 and RFC 9091. And a BIMI record points at a hosted brand logo, though BIMI is an active Internet-Draft, revision -14 dated 1 May 2026, not an RFC, and should never be described as a standard.

The page method has its own long tail in the same spirit: robots.txt contents, XHR hostnames, cookie names, CSS rules, and a probe request that tests whether a known path exists. Neither list is short.

certIssuer and CAA: two methods, two different facts

This is the most interesting thing in the comparison, and almost nobody writes it down.

The fingerprint schema's certIssuer field matches on the SSL certificate issuer, a fact read out of the TLS handshake the crawler itself performed. It tells you which CA signed the certificate that was actually served, on that host, at that moment.

CAA answers a different question entirely:

"The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name."

— RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record, IETF / RFC Editor, November 2019 (Standards Track)

Authorised, not issued. A domain can authorise three CAs and use one. It might authorise one, serve that CA's certificate on the apex, and have something else entirely sitting on a subdomain nobody crawled. Or publish no CAA record at all, which authorises everybody and tells you nothing, while its live certificate names a CA precisely.

The page method returns a fact about a delivered artefact. DNS returns a fact about a published policy. Put them side by side and you get something neither produces alone: what the organisation permits, and what it actually did. Our guide to CAA records covers the record's syntax and the issue, issuewild and iodef tags if you want the mechanics.

That pattern of two methods, two different facts and no subset relationship is the honest shape of this whole comparison. Nobody is winning.

What DNS structurally cannot see

Start here, because this is the bigger hole of the two, and everyone selling DNS-based intelligence would rather you read it last.

Most software never touches DNS at all. A vendor appears in a zone file for one of two reasons: it sends mail as the customer's domain, or it asked the customer to publish a verification token. Everything else is invisible. Issue trackers. Design tools. Data warehouses. BI platforms. HR systems consumed through a vendor-hosted domain. Anything bought on a corporate card. Anything resold inside another product. Anything behind single sign-on with a provider that does not use DNS-based domain verification. None of it is in the zone, and no amount of querying will put it there. That single fact is a larger limitation than anything in the page method's list.

Front-end and analytics: nothing. Every row in the top half of that table is a DNS blind spot. If a company runs a JavaScript framework, an A/B testing platform, a tag manager and three ad networks, DNS is silent on all four.

The sender list can be hidden on purpose. Some domains publish a single macro-based SPF mechanism whose answer is computed per connecting IP address by the vendor's own nameservers, so the list of authorised senders exists but cannot be enumerated from outside. A short record is not evidence of few vendors. A companion post on finding SaaS vendors in SPF records works through that mechanism in detail.

The standard anticipated harvesting and told publishers how to resist it. DKIM's specification says so directly: "While some domains may wish to make selector values well-known, others will want to take care not to allocate selector names in a way that allows harvesting of data by outside parties" (RFC 6376, §3.1). A ceiling on the method, written into the standard in 2011.

Absence proves nothing. A missing record does not mean the vendor is not in use. Verification tokens get removed after verification, which is good hygiene. Records get created on a subsidiary domain nobody thought to query. A vendor may never have documented a DNS step in the first place.

And a record is a configuration step, not a relationship. It evidences that somebody with zone write access completed an action at some point in the past. It carries no information about seat count, spend, sending volume, contract status, renewal, or whether the person who created it still works there. Nothing in DNS expires on its own. "Authorises" and "published a token for" are defensible verbs. "Uses" and "is a customer of" are not.

What a page crawl structurally cannot see

The mirror image, and it is a real list too.

Anything that never renders. The email security gateway. The identity provider. The CRM's mail sender. The marketing automation platform's sending domain. The support desk's relay. The finance system. These are not obscure corners of a company's stack. For a lot of organisations they are the expensive part, and a browser loading the homepage will never encounter any of them.

Server-side tagging moves the signal off the browser. A 2026 arXiv preprint from UC Davis researchers (not peer-reviewed as far as we could establish) puts the mechanism precisely: server-side tagging "removes the direct client-to-tracker request that many client-side tracking protections rely on, making endpoint-based detection and blocking fragile." The same paper reports detecting server-side Google Analytics on 6,314 domains, 4.21% of the Tranco top-150K. The detail worth noticing is that some of those deployments use CNAME cloaking, which means the vendor call disappears from the page and reappears as a DNS delegation. The signal did not vanish. It changed layers.

A tag manager makes the third-party set configuration-dependent. Researchers at Inria and Utrecht studying Google Tag Manager reported that only 3 of the 11 tags they examined in depth disclosed all the companies the tag contacts. What a crawler observes is therefore a function of what the container was configured to fire, at the moment of the crawl. (Their paper also makes a legal argument. That is a separate discussion and not this article's business.)

Single-page applications and server-side rendering change what a crawler receives, sometimes substantially, depending on whether the crawler executes JavaScript and how long it waits before reading the DOM.

Consent gating, the honest version. It is tempting to claim that cookie banners hide the stack from crawlers. The measurement evidence cuts against that. Work presented at The Web Conference in 2021 found that more than 75% of tracking activity happened before users had any opportunity to make a selection in the consent banner. A non-consenting crawler still sees most of it. Consent gating is a real effect on what a crawl observes, but it is partial, jurisdiction-dependent, and it suppresses less than people assume.

And the same caveat that applies to a DNS record applies to a script tag: a loaded resource evidences a page including something, not a paid relationship. Stale tags outlive contracts exactly the way stale TXT records do.

How accurate is any of this?

Almost nobody asks, which is strange, because there is an answer. One paper, with a scope you need to state every single time you quote it.

Brian Kondracki and Nick Nikiforakis presented Smudged Fingerprints at the USENIX Security Symposium in 2024. They built a testing framework and pointed it at the tools themselves:

"We design WASABO, a web application testing framework and use it to measure the performance of six web application fingerprinting tools against 1,360 releases of popular web applications."

— Smudged Fingerprints: Characterizing and Improving the Performance of Web Application Fingerprinting, Brian Kondracki and Nick Nikiforakis, USENIX Security Symposium 2024

The scope, stated up front rather than buried: this is version-level identification of open-source web application releases, telling one release of a CMS from another. It is not a test of vendor-category technographics, and it is not an evaluation of any commercial product's category detection. It is the fairest evidence available on this question, and it does not transfer perfectly.

With that established, the findings. Under ideal offline conditions:

"While 94.8% of all web application releases were correctly labeled by at least one fingerprinting tool in ideal conditions, many tools are unable to produce a single version prediction for a particular release. This leads to instances where a release is labeled as multiple disparate versions, resulting in administrator confusion on the security posture of an unknown web application."

— Smudged Fingerprints (abstract), Kondracki and Nikiforakis, USENIX Security 2024

By at least one tool. That 94.8% is a union across six tools under laboratory conditions, measuring version-level identification of open-source web applications rather than vendor-category technographics; it is not any single tool's score, and it belongs to no named commercial product. Anyone who writes "studies show BuiltWith is 94.8% accurate" has invented a finding that does not exist.

Then the researchers pointed the same tools at the real internet:

"We also measure the accuracy of each tool against real-world deployments of the studied web applications, observing up to an 80% drop-off in performance compared to our offline results."

— Smudged Fingerprints (abstract), Kondracki and Nikiforakis, USENIX Security 2024

"Up to" is a maximum across tools, not an average. And the reason matters more than the number. Real deployments are customised, and customisation strips out or alters the very artefacts a fingerprint keys on. That is a property of the method rather than a defect in anyone's product, which the same paper demonstrates neatly: a middleware that transformed traffic recovered a chunk of the loss without touching the tools at all. "Overall, we are able to improve the performance of popular web application fingerprinting tools by up to 22.9%, without any modification to the evaluated tools."

Now hold the DNS method to the same standard, because fairness that runs in one direction is not fairness. There is no equivalent independent evaluation of DNS-based vendor attribution. None was found for this article. That is a point against the DNS method, not for it: page-based fingerprinting has been measured by researchers with no commercial stake and found to degrade badly in the wild, while DNS-based attribution has never been put through the same test in public. An untested method is not a more accurate one. It is an unmeasured one.

Using both, as a procedure

"Use both" is a slogan unless it comes with an order of operations. Here is one.

Start with a page-based profiler for the customer-facing stack: framework, CMS and version, analytics, tag manager, ad tech, ecommerce, payments, CDN, hosting. That is its home ground and nothing else competes.

Then query the zone for the layers a browser never reaches. MX for the inbound mail operator. SPF include: targets for authorised outbound senders. DKIM selectors, if you can guess them, for signing infrastructure. Apex TXT records for SaaS verification tokens; our TXT record guide covers the query, and a companion post covers the token formats and what they do and do not prove. NS for the DNS operator. CAA for authorised certificate authorities. Our MX records guide and DNS lookup guide cover the mechanics, and the piece on reading a Microsoft tenant out of TXT records shows how far the identity layer alone can be pushed.

Then write the results down with the right verbs, and date-stamp them. Records change without notice, and so do pages.

Both halves earn their place in different jobs. BuiltWith's own site presents its dataset for lead generation and sales intelligence, market and investor research, ecommerce data and cyber-risk auditing, and those are fair, ordinary uses. The one where the DNS half pulls its weight hardest is third-party and supply-chain risk, a discipline whose entire motivation is the visibility gap. NIST SP 800-161 Rev. 1 describes those risks as ones "associated with an enterprise's decreased visibility into and understanding of how the technology they acquire is developed, integrated, and deployed." NIST establishes the problem. It does not endorse any particular method of external profiling, including this one.

Is any of this allowed?

Both activities are ordinary use of public infrastructure, and the symmetry is worth stating once.

BuiltWith frames its own crawling this way on its coverage page: "Everything we crawl is publicly accessible and fully compliant with legal standards, including respect for robots.txt directives." DNS sits on the same footing from the other direction. RFC 9076, §4.1, states that "DNS data and the results of a DNS query are public, within the boundaries described above, and may not have any confidentiality requirements." Loading a public page and resolving a published record are both ordinary uses of systems built to answer strangers.

MITRE ATT&CK does catalogue DNS reconnaissance as sub-technique T1590.002, noting that MX, TXT and SPF records may reveal the use of third-party cloud and SaaS providers. Cataloguing a technique describes adversary behaviour; it is not a statement that the activity is wrongful, and MITRE's own mitigation for it addresses zone transfer policy rather than ordinary lookups. How you then use, publish or resell what you find is a separate question from whether you may read it, and none of this is legal advice.

Back to the panel

Open the profiler again on that same company. React, Cloudflare, a tag manager, a payment widget, a chat client. Every one of those is real, current and useful, and a DNS query would have told you none of it.

Then run four dig commands and you learn who filters the mail, who is authorised to send as the domain, who is authoritative for the zone, and which certificate authorities are permitted to issue. Every one of those is real too, and a page crawl would have told you none of it.

Two instruments. Two measurements. The overlap is smaller than the marketing on either side suggests, and the people maintaining the fingerprint definitions worked that out years ago — which is why there is a dns field sitting in the schema, quietly matching a TXT pattern for Salesforce, right next to a cookie name.

Nobody has to choose. The mistake is thinking one panel was ever the whole company.

Sources

1. webappanalyzer schema.json — technology fingerprint schema — enthec/webappanalyzer (open-source continuation of the Wappalyzer fingerprint set), GitHub. raw.githubusercontent.com/enthec/webappanalyzer/main/schema.json
2. webappanalyzer README — fingerprint field reference (field meanings paraphrased, not quoted) — enthec/webappanalyzer, GitHub. raw.githubusercontent.com/enthec/webappanalyzer/main/README.md
3. webappanalyzer src/technologies/s.json — Salesforce and Segment definitions — enthec/webappanalyzer, GitHub. raw.githubusercontent.com/enthec/webappanalyzer/main/src/technologies/s.json
4. webappanalyzer src/categories.json — category identifiers — enthec/webappanalyzer, GitHub. raw.githubusercontent.com/enthec/webappanalyzer/main/src/categories.json
5. Find out what websites are built with — technologies index (vendor-published, undated coverage figure) — Wappalyzer. wappalyzer.com/technologies
6. BuiltWith FAQ — how detection and indexing work — BuiltWith. builtwith.com/faq
7. BuiltWith Global Data Coverage (vendor-published, live-updating counters, undated on the page; read August 2026) — BuiltWith. builtwith.com/data-coverage
8. BuiltWith — Website Technology Profiler and Lead Generation Platform (advertised use cases) — BuiltWith. builtwith.com
9. Smudged Fingerprints: Characterizing and Improving the Performance of Web Application Fingerprinting — Brian Kondracki and Nick Nikiforakis, USENIX Security Symposium 2024 (author project page carrying the full abstract). pragseclab.github.io/smudged-fingerprints
10. SST-Guard: Detecting and Characterizing Server-Side Google Analytics in the Wild (arXiv preprint, not peer-reviewed) — Muhammad Jazlan, Alexander Gamero-Garrido, Zubair Shafiq and Yash Vekaria, UC Davis, 30 April 2026. arxiv.org/html/2604.27497v1
11. Google Tag Manager: Privacy Leaks and Potential Legal Violations (cited only for the tag-disclosure measurement, not the legal argument) — Gilles Mertens, Nataliia Bielova, Vincent Roca and Cristiana Santos, Inria / Utrecht, 2024. arxiv.org/html/2312.08806v4
12. User Tracking in the Post-cookie Era: How Websites Bypass GDPR Consent to Track Users — Papadogiannakis, Papadopoulos, Kourtellis and Markatos, The Web Conference (WWW) 2021. arxiv.org/abs/2102.08779
13. Gather Victim Network Information: DNS, Sub-technique T1590.002 (v1.2, last modified 24 October 2025) — MITRE ATT&CK. attack.mitre.org/techniques/T1590/002
14. NIST SP 800-161 Rev. 1 (Update 1): Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations — NIST, May 2022, with updates as of 1 November 2024. csrc.nist.gov/pubs/sp/800/161/r1/upd1/final
15. RFC 1035: Domain Names — Implementation and Specification, §§3.2.2, 3.3.9, 3.3.11, 3.3.14 — IETF / RFC Editor, November 1987. rfc-editor.org/rfc/rfc1035.html
16. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, §5.2 — IETF / RFC Editor, April 2014 (Proposed Standard). rfc-editor.org/rfc/rfc7208.html
17. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, §3.1 and §3.6.2.1 — IETF / RFC Editor, September 2011. rfc-editor.org/rfc/rfc6376.html
18. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record — IETF / RFC Editor, November 2019 (Standards Track). rfc-editor.org/rfc/rfc8659.html
19. RFC 2782: A DNS RR for specifying the location of services (DNS SRV) — IETF / RFC Editor, February 2000 (Standards Track). rfc-editor.org/rfc/rfc2782.html
20. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — IETF / RFC Editor, May 2026 (Proposed Standard; obsoletes RFC 7489 and RFC 9091). rfc-editor.org/info/rfc9989
21. RFC 9076: DNS Privacy Considerations, §4.1 — IETF / RFC Editor, July 2021 (Informational). rfc-editor.org/rfc/rfc9076.html
22. Brand Indicators for Message Identification (BIMI), draft-brand-indicators-for-message-identification-14 — IETF Datatracker, active Internet-Draft (individual submission), 1 May 2026. Not an RFC. datatracker.ietf.org

Share this article

Related Articles

• TXT Records — What They Are and How to Look Them Up
• MX Records in DNS — How Email Routing Works
• From TXT Record to Tenant ID: DNS Recon Into Entra OAuth