What SaaS is your company actually using?
Your public DNS already names a good number of your suppliers. Type a domain and see what it gives away — in about a second, without connecting anything.
No domain to hand? Try , or .
Reads public DNS only — the same records any lookup returns. Nothing is probed, connected to, or stored.
Four public records, four kinds of supplier.
Nothing here is clever or covert. Organisations have to publish DNS records for email and third-party services to function at all, and those records name suppliers by design. The scan reads four families and matches what it finds against a list of known vendor fingerprints.
SPF v=spf1
Lists every service permitted to send email as you. This is the richest signal by far — your CRM, marketing platform, helpdesk, invoicing tool and transactional email provider all have to appear here or their mail bounces.
MX mail exchanger
Names who runs your mail, and often the security layer in front of it — Microsoft 365, Google Workspace, Proofpoint, Mimecast. One record, two suppliers, and usually the two most expensive ones.
DMARC _dmarc
The reporting address gives away your email security or deliverability vendor, because aggregate reports have to be sent somewhere a product can read them.
TXT verification tokens
The strings SaaS vendors ask you to paste into DNS to prove you own the domain. They are rarely removed once added, so they accumulate into a quiet archaeological record of everything anyone ever signed up for.
Why the leftovers matter: a verification token for a product nobody remembers buying is one of the cheapest shadow-IT signals there is. It costs nothing to publish, nothing to keep, and it outlives the person who added it.
A vendor list is not the point. What it overlaps with is.
Knowing you run sixteen SaaS products is mildly interesting. Knowing that three of them do the same job, that one is billed to a department that no longer exists, and that a fourth is the single point of failure for something the business actually depends on — that is worth acting on.
That is the work Arcamira is built for: taking an estate you can finally see and answering the questions that follow. What overlaps. What has no owner. What is past end of support and now an insurance and audit problem. What breaks if you turn any of it off.
Start where you are. A domain scan, a CSV of your app list, or a read-only collector you run yourself and inspect before anything leaves your network. Whichever you pick, the estate lights up in about an hour — no framework programme first.