The Tech-Stack Trace Reference: Live Install, Stale Trace, or Intent Only

Before an account goes on a competitive-displacement or integration list, you need answers to two questions: does it run the vendor today, and how far can you trust the public trace that pointed you there? This reference is for founders, account executives, SDR leads, and partnerships teams doing that qualification. Each common trace gets one row: a label (Live Install, Stale Trace, or Intent Only), a confidence band, a shelf life, and the one check that upgrades or kills it.

The trace lookup table

Find your trace in the first column of one of the two tables below. Its row gives the default label, the confidence band, how long the reading stays good, and the single check that settles it. Read the definitions first, because the whole method rests on them.

A trace is any public footprint of a vendor on the account's domain, website, or documents. Each trace gets one of three labels:

• Live Install: the trace exists, or keeps working, only because the account uses the product now.
• Stale Trace: the trace proves someone set the vendor up at some point, but nothing forces anyone to remove it when the relationship ends.
• Intent Only: the trace shows hiring, planning, or interest. It does not show a running system.

Each label also gets a confidence band:

• High: list the account on this trace and its date alone.
• Medium: list the account only after one corroborating check from a different layer.
• Low: do not list the account. Use the trace to decide where to look next.

Shelf life is how long after you saw a trace you can repeat its label without checking again.

These bands are my working defaults, not measured accuracy. Nobody publishes accuracy bands per detection method (DNS, headers, scripts, backend, job posts). The only public accuracy test I know of was run by a vendor on itself (see the front-end section below). Treat the bands as a decision rule you can audit against your own won and lost deals, not as probabilities.

DNS and mail traces

Page, document, and intent traces

My sources do not measure CNAME, status-page, or repo-config traces at all. Those rows are my reasoning from how each mechanism works, so never upgrade them without a check from another row.

Which verification tokens prove current use?

A TXT verification token proves current use only when the vendor rechecks it from time to time. If the vendor only needs it once, the token proves someone verified the domain at some point, and nothing more. Often the token's format cannot tell you which rule applies.

A verification token is a TXT record (a free-text DNS entry) that a vendor asks you to publish to prove you control the domain. The table below covers the vendors where the rule is documented, plus two where only community answers exist.

Here is what each rule means for your label:

• Google Search Console says it "periodically checks if your verification token is still present and valid." If the token goes missing, "your permissions on that property will expire after a certain grace period." So a Search Console token sits on a domain where someone still holds access.
• Google Workspace says: "Once verified, the TXT record can be safely removed." A Workspace token is setup evidence only.
• Microsoft 365 guidance is to remove the TXT record (or MX record) from your DNS host once the domain is verified. A Microsoft MVP adds that removing MS= does not hide Microsoft 365 use, because "there are other methods that can be used to verify whether a certain domain is in use by Microsoft 365." So finding MS= does not prove a current tenant, and not finding it does not rule one out.
• Atlassian and Auth0 are reported to recheck their tokens, but only in community answers. Confirm in the vendor's own documentation before you treat either as a must-persist record.

Stale setup tokens pile up for a simple reason: if the vendor never rechecks, nobody is pushed to clean up. A Let's Encrypt community thread on removing challenge records after validation puts it bluntly: "Users should do that, but many don't."

A token the vendor never rechecks records a setup. It does not show that the account is still a customer.

I could not find any published census of how many tokens survive after a relationship ends. The largest structured TXT study I found covers roughly 75 billion TXT records collected over nearly four years. It classifies what records are for, not how long they last: 83.35% had a well-defined purpose, including email and domain-ownership verification. A separate SANS ISC sample found that across 300K+ TXT records, 186K were related to SPF. Both show TXT is mostly deliberate configuration. Neither tells you about persistence.

You can check persistence yourself. Take accounts you know churned from your own product, re-pull their TXT records, and count how many still carry your token. That ratio is the best estimate you will get of how stale setup-only tokens run in your market.

How do SPF includes and MX hosts map to products?

An SPF include names a system that is allowed to send mail as the domain, so it is evidence of current sending. But it only tells you as much as the include itself. One vendor can publish several includes for different products, and some products leave no SPF trace at all.

SPF (Sender Policy Framework) is a TXT record listing who may send mail for a domain. An include delegates part of that list to a vendor. Map each include to a product before you pitch a displacement:

• include:_spf.salesforce.com means Salesforce core platform mail. Salesforce warns that "other SPF records for the salesforce.com domain aren't relevant to sending mail from the Salesforce application." The include uses a macro (exists:%{i}) that dynamically authorises all Salesforce mail server IP addresses, so it tells you nothing about which org or edition the account runs.
• include:cust-spf.exacttarget.com is the include Salesforce Marketing Cloud Engagement commonly uses. Check for it separately, because it is a different product from core platform mail.
• Account Engagement (Pardot) may leave nothing to find. One implementation partner says its emails "no longer rely on your domain's SPF record for authentication." A missing SPF include is not evidence that Pardot is absent.
• include:spf.protection.outlook.com means Microsoft 365. It is the corroboration to pair with an MS= token.

An MX record names the server that receives the domain's mail. If it points to a provider, mail flows there today, which is why MX gets a high band. I have not mapped MX hosts to individual products in detail, so read an MX host as "mail provider" and nothing finer. Pair it with an SPF include from the same vendor before you upgrade the reading to a product.

If you are trying to detect the CRM a company uses, remember that a CRM only shows up in DNS when it sends mail as the domain. Many CRM installs never touch DNS, which is why the people check further down carries so much weight for CRM qualification.

Front-end traces and the tag-manager blind spot

A script tag or response header proves the page served that vendor on the day you fetched it. A blank result proves nothing, because tags that a tag manager injects do not appear in the raw HTML a simple fetch reads.

Fingerprinting means matching a page's headers, cookies, script URLs, and markup against a library of patterns. webappanalyzer, the open fork of the most widely used fingerprint set, covers 7,628 technologies across 109 categories. Tools that read public DNS alongside the page can also find tools that never appear on the website.

The engines score their matches, so check how a score was built before you trust it:

• In one engine built on the common open fingerprint format, a match's confidence is the sum of every matching pattern's own confidence, capped at 100.
• Another engine uses a default threshold of 50%.
• The fingerprint schema supports implies and requires rules. Detecting one technology can imply another with no direct evidence on the page.

So a score just over a 50% threshold may rest on a single implied pattern. Headers and cookies agreeing beats a lone script source.

How accurate is technographic data? Nobody has measured it independently. The only published accuracy test I found was run by a vendor about itself. It hand-checked 100 technologies and reported 86% precision for itself against 64% for a widely used open-fingerprint tool. The test counts false positives and says nothing about what either tool misses. Use it as a reminder that misses are unmeasured, not as a benchmark.

The miss rate has at least one structural cause. In W3Techs' latest snapshot, Google Tag Manager is used by 45.1% of all websites, which is 99.6% of the tag-manager market. In an earlier snapshot, 53.1% of sites used none of the tag managers W3Techs monitors. Across four snapshots, Tag Manager's share of all sites drifted from 47.1% down to 45.1%. The figure moves, so recheck it on the W3Techs tag-manager survey rather than carrying a number forward.

Detectors that only read the raw page miss anything that appears after JavaScript executes, such as client-side chat widgets injected by a tag manager. Server-side tagging and reverse-proxied analytics are a further blind spot. I found no primary source with a share figure for either, so their size is not established.

Documents and intent: subprocessor lists, status pages, job posts, repo configs

A document records the date it was written, not the date you read it. Log that date, or log "undated", and set the band from it.

Subprocessor lists

A subprocessor is a vendor that a data processor uses to handle its customers' personal data. Searching a subprocessor list for a company's vendors only works when the target is itself a processor, such as a SaaS company handling customer data. Here is what the rules actually require:

• GDPR Article 28(2): "the processor shall not engage another processor without prior specific or general written authorisation of the controller."
• EDPB guidance: "it is not sufficient for the processor to merely provide the controller with a generalized access to a list."
• So GDPR requires telling customers. It does not require a public page, and a public list is one voluntary way of meeting the duty.
• GDPR sets no notice period for subprocessor changes, so the data processing agreement (the contract between the two parties) sets it. One trust-center vendor says the window is typically around 15 days in Europe.

I could not establish any public-listing rules under SOC 2 or ISO 27001. Nor could I find data on how often these pages show a last-updated date. A dated entry is a medium-band Live Install. An undated entry is a Stale Trace until something else agrees.

Status pages, job posts, repo configs

These are the rows with the thinnest evidence behind them:

• Status-page component. A third-party component on the account's status page suggests a current dependency. My sources do not cover this trace, so hold it at medium and require a DNS or front-end trace that agrees.
• Job-posting mention. A posting that names a tool may describe the current stack, a migration target, or a wish list, and the text rarely says which. It is Intent Only until a named admin or a technical trace upgrades it. It stops meaning anything once the posting closes.
• Public repo config. A config file in a public repo that references a vendor is only as current as its last commit. Label it Stale Trace, low, unless the commit is recent and another layer agrees.

The people check: does anyone at the account admin the tool?

A current employee at the account whose title names the tool is the strongest non-technical corroboration. How often such a person exists depends heavily on the tool, and keyword searches mostly return the vendor's own staff.

In Refolk's index of professional profiles, density by tool and market looks like this:

Three readings follow from the table:

• Admin culture sets the base rate. For Salesforce accounts, a named admin is common, and the US to UK ratio is 7.1x. For HubSpot accounts, the check will usually come back empty even when HubSpot is installed. Only treat a missing admin as evidence against an install when the tool has a strong admin culture.
• Exact titles matter. Between 19 and 21 of each 25-profile sample carried the title exactly. The HubSpot admin sample also included a "Grocery Clerk". Read the titles you get back. Do not count rows.
• The employer is not always the install. In the UK Salesforce Administrator sample, Deloitte (a consultancy) and Linnworks were the only employers with two people each. Consultancy admins work on client orgs, so their employer's name tells you nothing about which account runs the tool.

The exclusions matter as much as the inclusions here. In Refolk you can ask for the role, the tool, the market, the company size, and the exclusions in one plain-English sentence, then read the titles that come back.

The labeling procedure

Run these eight steps in order for each account, from DNS through to people. Stop as soon as a trace reaches the band your list requires. Nobody publishes a standard order. I put this one together from tool documentation, and sources do not say whether rendering should come before or after the raw fingerprint. The desk estimates add up to roughly 17 minutes per account plus about a minute per token. Those times are unverified.

Use one record per trace so that someone else can recheck an account without asking you:

account_domain:
trace_type: MX | SPF include | TXT token | CNAME | script | header | subprocessor | status page | job post | repo config | person
raw_value:
vendor:
product: (or "vendor-level only")
token_rule: must persist | setup-only | rule unknown | n/a
detection_method:
tool_confidence: (score and threshold, if a tool produced it)
label: Live Install | Stale Trace | Intent Only
band: high | medium | low
corroborated_by: (trace_type and raw_value of the second layer)
first_seen:
last_confirmed:
page_date: (or "undated")
next_recheck:

How trace reading goes wrong

Most bad displacement lists come from a handful of repeat misreads: a setup token read as live, a vendor include read as a product, a blank scan read as absence, a weak match read as strong, a keyword hit read as a customer, and an undated page read as current. Each one below has the check that catches it.

1. Google token read as Search Console (live).
   • What it looks like: a google-site-verification= record gets labeled Live Install.
   • Why it is wrong: Workspace uses the same prefix and treats the record as setup-only, so the token alone cannot tell you the product or whether it is current.
   • Check: look for Google evidence in MX or SPF as well.
2. MS= token treated as proof of a current tenant.
   • What it looks like: an MS=ms######## record puts the account on a Microsoft 365 displacement list.
   • Why it is wrong: Microsoft says the record can be removed after verification, so its presence only proves that someone verified the domain at some point.
   • Check: look at MX and for include:spf.protection.outlook.com in SPF.
3. Vendor-level SPF read as product-level.
   • What it looks like: _spf.salesforce.com gets read as "they run Marketing Cloud" or "they run Pardot".
   • Why it is wrong: that include covers core platform mail only, and Pardot may leave no SPF trace at all.
   • Check: look for cust-spf.exacttarget.com separately, and never infer Pardot from the absence of a trace.
4. "No detection" read as absence.
   • What it looks like: an account is marked "not using the competitor" after a raw-HTML scan.
   • Why it is wrong: no result does not prove absence, and Tag Manager alone sits on about 45% of all sites, injecting tags a raw fetch never sees.
   • Check: render JavaScript or inspect the container.
5. Low-confidence single match.
   • What it looks like: a score just over the 50% threshold gets treated like a confirmed install.
   • Why it is wrong: the score may come from a single implied pattern with no direct evidence.
   • Check: see which method matched. Headers and cookies together beat one script source.
6. People-signal pollution.
   • What it looks like: a keyword search for the tool returns hundreds of "users".
   • Why it is wrong: in Refolk's index, 16 of 25 sampled US profiles with HubSpot in the headline work at HubSpot. Consultancy admins, such as the Deloitte staff in the UK Salesforce sample, work on client orgs. Off-target titles slip in too.
   • Check: exclude the vendor and consultancies, and require the tool in the person's current title.
7. Subprocessor list read as current.
   • What it looks like: an entry on a trust-center page gets labeled Live Install with no date.
   • Why it is wrong: GDPR requires telling customers, not keeping a public page current, and no published data shows how often these pages carry a date.
   • Check: record the page date, or log "undated" and drop the band.

A failure that sits under all seven: counting traces instead of weighing them. Three setup-only tokens from three vendors tell you less than one MX record. An account is labeled by its strongest corroborated trace.

Keeping labels current

A label stays good only for its shelf life. Store the last-confirmed date, and recheck each trace on its own clock rather than on a fixed calendar. Some lookup tools return a last-confirmed timestamp (for example, a confirmedAt field) saying when the tool last verified a detection. Store it next to your own date, because the two are often different.

Recheck in these situations:

• Before any sequence starts. Re-pull DNS and re-render the page for every account where the label rests on a front-end or SPF trace.
• When the only evidence is setup-only. These accounts stay Stale Trace until a load-bearing trace appears. Recheck them for one rather than promoting them on age.
• When an admin is your corroboration. People change jobs. Re-asking the same people question in Refolk just before outreach catches admins who have moved on.
• When vendor rules change. Re-read the vendor's verification documentation whenever you rely on a must-persist rule, and recheck the W3Techs tag-manager survey before quoting a blind-spot figure.