# Supply-Chain Dependency Mapping > Maps every external provider a domain depends on — nameservers, mail exchangers, third-party email senders (SPF), CDN and hosting networks, registrar and DKIM vendors — by reading each layer of the graph and keeping only providers whose registrable apex differs from the target’s own. Each dependency is grouped by function and the flow flags single-vendor concentration: one DNS operator, one mail provider or one hosting network is a single point of failure whose outage takes the whole function down. The mirror of Digital Infrastructure Mapping: that flow maps what an entity owns, this maps what it depends on. *Source: https://www.whisper.security/docs/workflows/supply-chain* --- ## What it solves An outage or breach at a third-party DNS, mail or hosting provider takes down every customer relying on it, and most organisations don’t have a clear map of which providers their own domain actually depends on for which function. Building that map by hand means checking DNS, SPF, hosting and DKIM records separately and working out by eye which ones are third-party. ## How it uses the graph Traverses the DNS, email, BGP, WHOIS, physical layers of the graph, in 12 steps: 01. **Operator (atlas)** _(DNS)_ — Attributing the domain to its operator… 02. **Registrable apex** _(DNS)_ — Resolving the registrable apex (eTLD+1)… 03. **DNS providers** _(DNS)_ — Finding the external nameserver operators… 04. **Mail providers** _(email)_ — Finding the external mail exchangers… 05. **Registrar** _(WHOIS)_ — Reading the domain registrar… 06. **Hosting networks** _(BGP)_ — Mapping the networks the addresses sit on… 07. **Authorized email senders** _(email)_ — Reading the third-party SPF senders… 08. **Candidate origin behind a CDN** _(BGP)_ — Looking for a candidate origin behind any CDN front… 09. **DKIM signing vendors** _(email)_ — Reading the DKIM signing vendors… 10. **Technology concentration** _(web)_ — Checking which technologies the suppliers share… 11. **SaaS subdomain delegations** _(BGP)_ — Grouping the subdomain estate by the network it delegates into… 12. **Physical dependency** _(physical)_ — Mapping the physical facilities the hosting networks sit in… ## Why each step runs 1. **Operator (atlas).** whisper.identify names who operates the domain itself — the vendor, its category and derived roles. It is the anchor the external dependencies hang off: everything run by a DIFFERENT apex is a supply-chain dependency. 2. **Registrable apex.** whisper.psl.tldPlusOne collapses a host to its registrable domain via the Public Suffix List — the reference apex every provider is classified against. A provider whose apex matches this is self-hosted; a provider whose apex differs is an external dependency. 3. **DNS providers.** The nameservers that answer for the domain (NAMESERVER_FOR, reverse), folded to their operator apex and kept only where that apex differs from the domain's own — the third-party managed-DNS vendors. DNS root servers are filtered. One operator answering for the whole zone is a single point of failure. 4. **Mail providers.** The mail exchangers accepting inbound mail for the domain (MAIL_FOR, reverse), folded to their operator apex and kept only where external — the mail provider (Google Workspace, Microsoft 365, …). A single mail operator handling all inbound is a concentration risk. 5. **Registrar.** The registrar the domain is registered through (HAS_REGISTRAR) — the ownership-layer dependency that controls the domain's very existence. Registrar lock and transfer-control policy live here. 6. **Hosting networks.** The networks (ASNs) that route the domain's addresses — its own IPs and a sample of its subdomains (RESOLVES_TO → ANNOUNCED_BY → ROUTES), with the ASN name and registrant org. This is the compute/CDN hosting dependency. A single dominant network is a hosting single point of failure. 7. **Authorized email senders.** The third-party senders the domain authorizes to send mail on its behalf (SPF_INCLUDE), folded to their operator apex and kept only where external — SendGrid, Zendesk, Salesforce, Mailchimp and the like. Each is a delegated-trust email-delivery dependency. 8. **Candidate origin behind a CDN.** whisper.origins proposes a candidate origin IP and ASN behind a CDN (high-confidence candidates only; the bar adapts to the score scale). If confirmed, the origin network is the hosting dependency the CDN hides; it is unconfirmed (in our audit, 6 of 71 checked candidates were the origin). 9. **DKIM signing vendors.** The vendors that DKIM-sign mail for the domain (DKIM_SIGNED_BY → VENDOR) — the cryptographic email-authentication dependency. A pattern-comprehension keeps it to one row whether or not the edge is populated. 10. **Technology concentration.** For each external supplier the run found (DNS, mail and email-sender apexes, up to 10), lists the 100 most widely adopted technologies it runs. Counting how many suppliers run each one shows what the supply chain shares: a technology common to several suppliers is one dependency behind several "independent" vendors. Adoption is a lead to confirm, not exposure. 11. **SaaS subdomain delegations.** Which external networks the subdomain estate actually delegates into: sample the resolving subdomains (CHILD_OF → RESOLVES_TO → ROUTES) and tally by ASN. Subdomains pointing into AWS, Google Cloud, Fastly, Zendesk and the like are SaaS/cloud dependencies woven through the namespace. 12. **Physical dependency.** The datacenter facilities (AS_PRESENT_AT) and internet exchanges (IX_MEMBER) the hosting networks are physically present at — the deepest supply-chain layer. Sparse: only networks with PeeringDB coverage report it. [Open the full use-case page, with the live runner](/products/intelligence/use-cases/infrastructure-supply-chain/supply-chain)