What does this actually look at?

Public DNS records for the domain you enter — TXT verification tokens, the SPF record and the senders it authorizes, MX routing, DMARC reporting addresses, CNAME targets and nameservers — plus one ordinary request for the domain’s homepage to read its Content-Security-Policy. That is the whole list. Nothing touches a system of yours, nothing is scanned, and no path is guessed.

Is this a security scan?

No, and it is deliberately not one. It sends no port scan, no directory or path guessing, no admin-panel probing, no credential testing and no payload of any kind. Every lookup is a question anyone can ask of a public nameserver, and the single homepage request is the same request a visitor’s browser makes. If you would not call loading a website a scan, this is not one either.

Do you store the results?

No. The tool runs the lookups, returns what it found, and keeps nothing — no account, no record of the domain, and no copy of the page it read. If you want the results kept, reviewed and turned into a vendor register you can work from, that is what a Keel workspace does; this page does not quietly become one.

Why do some results say you are less sure?

Because the evidence differs in strength. A verification token in your DNS or a sender in your SPF record is something your organization published on purpose — that is a statement you made. A CNAME only proves where a name points: a subdomain still aimed at a service you cancelled two years ago looks identical from the outside. The tool groups results by which of those it has, and never presents the second as the first.

It found almost nothing for my domain. Is that bad?

Not necessarily, and it is not a verdict on your security. A domain with few TXT records, no published Content-Security-Policy and mail handled somewhere unusual will legitimately show little. It means the public record is quiet, not that you use no vendors — which is exactly why this is a starting point for a register rather than the register itself.

What do I do with the list?

Treat it as a first draft of your third-party register. Most compliance frameworks expect you to know who your suppliers are, what they touch, and that someone reviewed them — the supplier-relationship and cloud-services controls all start from a list that is actually complete. Getting that list out of DNS in a few seconds beats reconstructing it from expense reports.

What does this actually look at?

Public DNS records for the domain you enter — TXT verification tokens, the SPF record and the senders it authorizes, MX routing, DMARC reporting addresses, CNAME targets and nameservers — plus one ordinary request for the domain’s homepage to read its Content-Security-Policy. That is the whole list. Nothing touches a system of yours, nothing is scanned, and no path is guessed.

Is this a security scan?

No, and it is deliberately not one. It sends no port scan, no directory or path guessing, no admin-panel probing, no credential testing and no payload of any kind. Every lookup is a question anyone can ask of a public nameserver, and the single homepage request is the same request a visitor’s browser makes. If you would not call loading a website a scan, this is not one either.

Do you store the results?

No. The tool runs the lookups, returns what it found, and keeps nothing — no account, no record of the domain, and no copy of the page it read. If you want the results kept, reviewed and turned into a vendor register you can work from, that is what a Keel workspace does; this page does not quietly become one.

Why do some results say you are less sure?

Because the evidence differs in strength. A verification token in your DNS or a sender in your SPF record is something your organization published on purpose — that is a statement you made. A CNAME only proves where a name points: a subdomain still aimed at a service you cancelled two years ago looks identical from the outside. The tool groups results by which of those it has, and never presents the second as the first.

It found almost nothing for my domain. Is that bad?

Not necessarily, and it is not a verdict on your security. A domain with few TXT records, no published Content-Security-Policy and mail handled somewhere unusual will legitimately show little. It means the public record is quiet, not that you use no vendors — which is exactly why this is a starting point for a register rather than the register itself.

What do I do with the list?

Treat it as a first draft of your third-party register. Most compliance frameworks expect you to know who your suppliers are, what they touch, and that someone reviewed them — the supplier-relationship and cloud-services controls all start from a list that is actually complete. Getting that list out of DNS in a few seconds beats reconstructing it from expense reports.

Free tool · $0 · no signup

Find the vendors your domain already names

Your DNS records and your own website say more about which SaaS you use than most vendor registers do. Enter a domain and see what they declare — with the evidence for each one, so you can check it rather than take our word for it.

Two things, and nothing else. DNS-over-HTTPS queries to a public resolver, asking about public records in a public zone — the domain’s own servers never see those. And one ordinary GET of the homepage, which does appear in the site’s access log as a single request identifying itself as Keel.

There is no port scanning, no directory or path guessing, no admin-panel probing, no credential testing and no payload injection. Those are ruled out by design rather than by policy, and they stay ruled out in every future version of this.

A verification token sitting in your DNS is something someone at your organization deliberately published in order to prove ownership to that vendor. A sender in your SPF record is your organization authorizing that service to send email as you. Those are statements you made.

A CNAME is not. It proves where a name points, which is a different and weaker fact — a subdomain aimed at a service you stopped paying for is indistinguishable from a live integration when you are looking from outside. The tool separates the two and shows you which it has, because a list that mixes them is a list you cannot act on.

FAQ

What does this actually look at?: Public DNS records for the domain you enter — TXT verification tokens, the SPF record and the senders it authorizes, MX routing, DMARC reporting addresses, CNAME targets and nameservers — plus one ordinary request for the domain’s homepage to read its Content-Security-Policy. That is the whole list. Nothing touches a system of yours, nothing is scanned, and no path is guessed.
Is this a security scan?: No, and it is deliberately not one. It sends no port scan, no directory or path guessing, no admin-panel probing, no credential testing and no payload of any kind. Every lookup is a question anyone can ask of a public nameserver, and the single homepage request is the same request a visitor’s browser makes. If you would not call loading a website a scan, this is not one either.
Do you store the results?: No. The tool runs the lookups, returns what it found, and keeps nothing — no account, no record of the domain, and no copy of the page it read. If you want the results kept, reviewed and turned into a vendor register you can work from, that is what a Keel workspace does; this page does not quietly become one.
Why do some results say you are less sure?: Because the evidence differs in strength. A verification token in your DNS or a sender in your SPF record is something your organization published on purpose — that is a statement you made. A CNAME only proves where a name points: a subdomain still aimed at a service you cancelled two years ago looks identical from the outside. The tool groups results by which of those it has, and never presents the second as the first.
It found almost nothing for my domain. Is that bad?: Not necessarily, and it is not a verdict on your security. A domain with few TXT records, no published Content-Security-Policy and mail handled somewhere unusual will legitimately show little. It means the public record is quiet, not that you use no vendors — which is exactly why this is a starting point for a register rather than the register itself.
What do I do with the list?: Treat it as a first draft of your third-party register. Most compliance frameworks expect you to know who your suppliers are, what they touch, and that someone reviewed them — the supplier-relationship and cloud-services controls all start from a list that is actually complete. Getting that list out of DNS in a few seconds beats reconstructing it from expense reports.

This page gives you the list and forgets it. A Keel workspace keeps it: every proposed vendor arrives with the evidence attached, you accept or dismiss each one, and what you accept becomes a real third-party register with an audit trail of who decided what and when. Re-run it later and it only shows you what is new.

See plans →

Third-party names are trademarks of their respective owners. Keel is not affiliated with, endorsed by, or partnered with any vendor this tool names; naming them is a statement of what your public records say, nothing more.