Your domain already knows which vendors you use

Ask a small team which third parties can reach their customer data and you will usually get a confident answer that is also incomplete. Not through negligence — through arithmetic. Somebody started a trial. Somebody connected a plugin. Somebody's card paid for a scheduling tool that now holds a list of customer email addresses. Self-service SaaS is designed to need no procurement, so none of those decisions passed a desk where they could have been written down.

The register you can write from memory is the one you remember. The gap between it and reality is where third-party risk actually lives.

The records you already publish

Here is the useful part: adopting a service usually leaves a public trace, because the service asks you to leave one.

When you set up a new tool that sends email as your company, you add it to your SPF record. When a vendor needs to know you own the domain, it asks you to publish a verification token in DNS. When your website loads a script from a third party, your Content-Security-Policy has to name that origin. Your nameservers say who runs your DNS. Your MX records say who runs your mail. Your DMARC reporting address often names the service that processes the reports.

None of this is secret, and none of it is a leak. It is the ordinary exhaust of running a company on other people's software — published deliberately, by you, so those services work. But nobody reads it back as a list, because reading it back is tedious and there was never a reason to.

What that looks like in practice

We pointed the tool at our own domain while writing this. It came back with nine vendors, every one of them correct, and every one carrying the record it came from:

• Our DNS and CDN provider — named three separate times, by the nameservers, by the DMARC reporting address, and by a script-src entry in the Content-Security-Policy.
• Our productivity suite — a domain-verification token in a DNS TXT record.
• Our mail provider — the MX hosts, plus an SPF include and a TXT record.
• A second service authorized to send as us — an SPF include and a TXT record.
• Five front-end services — analytics, product analytics, a social pixel, a social-scheduling tracker, and an automation platform — all from script-src and connect-src entries in the Content-Security-Policy.

Note what that list is: nine relationships, reconstructed from records we published ourselves, with no access to anything of ours. Every row came back as declared — each one traceable to something our organization deliberately put in public to make a service work.

Reading it yourself, without a tool

You do not need software for this. If you want to do it by hand, these are the queries:

dig TXT   yourdomain.com          # verification tokens, SPF
dig MX    yourdomain.com          # who runs your mail
dig NS    yourdomain.com          # who runs your DNS
dig TXT   _dmarc.yourdomain.com   # DMARC policy and reporting address
curl -sI  https://yourdomain.com  # response headers, including CSP

Read the results as a list of relationships rather than a configuration. A google-site-verification token means somebody proved ownership to Google. An include: in your SPF means you authorized a service to send mail as you. A script-src entry means your homepage is allowed to run code from that origin.

The free tool

We built vendor discovery to do exactly that pass and hand you the list. It is free, there is no signup, and nothing you enter is saved.

Four things about how it behaves are worth stating plainly, because they are the difference between a useful tool and an irresponsible one.

It is passive. It makes DNS-over-HTTPS queries against a public resolver — so your nameservers never see them — and one ordinary GET of the homepage, which shows up in that site's access log as a single request identifying itself as Keel. There is no port scanning, no directory guessing, no admin-panel probing, and no credential testing — in this version or any later one. That is a design limit, not a roadmap gap.

It separates what you said from what we concluded. A verification token or an SPF include is a statement your organization deliberately published. A CNAME is not: it proves where a name points, and a subdomain aimed at a service you cancelled last year looks identical from outside to a live integration. So the results are grouped by confidence. Declared rows arrive selected. Observed and inferred rows arrive deselected, because those are our conclusion rather than your statement.

It shows its work. Every row quotes the record it came from, the URL that was read, and the time it was read. You are meant to check it, not trust it.

It proposes; a person decides. In the app, discovery hands you a list of candidates with checkboxes. Nothing lands in your vendor register until you tick it. A tool that silently fills a register with guesses has not solved the problem — it has moved the problem into the register, where it looks like fact.

Where this stops

A starting point for a third-party register, not a complete one.

Plenty of real vendors leave no public trace at all. A contract analytics platform your finance team uses in a browser, with no email sending, no domain verification, and no script on your marketing site, is invisible to every signal above. A vendor that touches your data but leaves no public trace is invisible to this, and still belongs in your register.

The honest framing is that this removes the blank page. It does not certify that the page is full. Pair it with the records you already control — card and expense statements, your identity provider's application list, the OAuth grants people have approved against your email and file storage — and you will get close. Then keep reconciling, because this is a recurring check rather than a cleanup.

Why we made it free

Because the blank page is the actual barrier, and it is a bad reason for a small team to have a worse vendor register than a large one. You can run it, take the list, and never create an account; the output is yours either way.

If you want the rest of it — tiering by data access, review cadences, assessments, and the evidence in one place — that is what vendor risk management in Keel is. But start by finding out what you are already running.

Run vendor discovery on your domain →