DNS Supply Chain: a beginner's guide

A domain's supply chain is the complete list of third-party vendors the domain has formally authorized to act on its behalf. Every `include:` in your SPF record is a delegated-trust relationship with an email vendor. Every CAA record lists a certificate authority you've authorized to issue SSL certificates for your name. Every CNAME points at a SaaS provider whose uptime and security you've implicitly inherited. Every NS record names the DNS host whose compromise would compromise your entire domain. These relationships are invisible in normal operations — they only become visible when one of the vendors has a breach, and suddenly your brand is part of the blast radius.

You should care because the 2020s are the decade of supply-chain attacks — SolarWinds, Log4j, MOVEit, the steady stream of CDN and SaaS vendor breaches. Each of those incidents showed that attackers now find it easier to compromise a widely-used vendor than to go after any one of the vendor's customers directly. Your domain's supply-chain exposure is the set of vendors whose compromise would also compromise you, mapped out in advance so you can make informed decisions about which dependencies to keep.

The five signals every supply-chain check examines:

• SPF `include:` chain. Every email vendor you've delegated sending authority to — after full recursive expansion, which often reveals second- and third-tier vendors you never explicitly authorized.

• NS records and glue. Your DNS provider is the most consequential single dependency — their compromise is your complete compromise.

• CAA records. Which certificate authorities are authorized to issue for your domain. A permissive or missing CAA policy widens the set of CAs whose mis-issuance could hurt you.

• CNAME targets for production hostnames. Every `www`, `api`, `app`, or `static` CNAME points somewhere — a SaaS account, a CDN, a load-balancer service. Each target is an inherited dependency.

• SRV and TXT verification records. Services like Microsoft 365, Google Workspace, Atlassian, and hundreds of smaller SaaS tools publish verification records on your domain. Each one is evidence of an active vendor relationship.

Three questions a supply-chain check answers:

• Who are all the third parties that are cryptographically authorized to act on behalf of my domain — email senders, certificate issuers, DNS hosts, SaaS integrations?

• Which of those dependencies are still active versus leftover from vendors I've stopped using?

• If one of my vendors has a breach tomorrow, which of my domains is exposed?

The cost of unknown supply-chain exposure is discovering your vendor list during the post-incident briefing rather than before it. The fix is a complete vendor map that's refreshed quarterly and tied to a cancellation workflow — every time a vendor is deprecated, the corresponding SPF include, CAA entry, or verification TXT record gets removed the same day. NIST SP 800-161 Rev. 1 and CISA's supply-chain guidance cover the operational discipline; the OWASP Top 10 A06:2021 (Vulnerable Components) covers the code-level angle.

In one sentence: Map third-party vendors via [SPF (Sender Policy Framework)](/guides/spf-record-setup-guide), NS, CAA, and TXT records

Maps the third-party dependency graph for a domain derived entirely from public DNS (Domain Name System) records. Parses SPF (Sender Policy Framework) includes (email senders), NS records (DNS hosting), CAA records (certificate authorities), SRV records (advertised services), and TXT verification tokens (SaaS integrations) to produce a vendor dependency inventory with trust grading — explicitly showing which third parties can, in principle, compromise the domain if breached.

Don't worry if some of the words above are still unfamiliar — there's a plain-language glossary at the bottom of this page, and most of the terms link to their own beginner guides if you want to learn more.

Here's what's actually happening behind the scenes when you call this endpoint:

Queries SPF (Sender Policy Framework) (TXT), NS, CAA, SRV, and filtered TXT records in parallel via DoH (DNS over HTTPS). For each record type, classifies terminal hostnames/values into known vendors (Google, Microsoft, AWS, Cloudflare, Akamai, Let's Encrypt, DigiCert, Google Site Verification, etc.) and assigns a trust level based on the attack surface that vendor owns: critical (can send email as the domain, or hijack DNS (Domain Name System) resolution, or issue certs), high (operates HTTPS (secure HyperText Transfer Protocol) infrastructure), medium (advertised service endpoints), low (SaaS integration proof-tokens). Reports risk signals for concentration (single NS provider = single point of failure), excessive vendors, and insecure services.

If you're using an AI assistant through MCP, you don't need to understand any of the technical details — the assistant calls the tool and translates the result for you.

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about the DNS Supply Chain tool? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

Vendor risk management programs typically inventory contracted SaaS vendors — but they miss the silent trust relationships encoded in DNS (Domain Name System): the 20 email services your SPF (Sender Policy Framework) authorizes, the single DNS provider that can redirect all traffic, the four CAs authorized to issue your certs. This endpoint surfaces those DNS-derived trust relationships so the security team can review them against the written vendor inventory.

Picture this in real life. Imagine a GRC / vendor risk manager. Here's the situation they're walking into: Align written vendor inventory with actual DNS-authorized vendors to catch shadow dependencies and stale authorizations. Without the right tool, that person would be stuck copy-pasting between five browser tabs, reading documentation written for engineers, and crossing their fingers that the answer they cobble together is correct. With the DNS Supply Chain tool, the same person gets a clear answer in seconds — no spreadsheets, no guessing, no waiting for someone on the infrastructure team to free up.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, the DNS Supply Chain tool is built for you:

• Is this domain or IP address known for fraud, phishing, or abuse?

• Should my signup form, payment flow, or comment system trust this visitor?

• Is someone out there registering lookalike domains targeting my brand?

You can either click the tool and get the answer yourself, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this. Trust and safety teams, fraud analysts, brand-protection managers, security operations engineers, and product teams running open signup flows. If you see yourself in that list, this is one of the EdgeDNS tools you should bookmark today.

What happens if you skip this entirely. Skip it and you find out a domain or IP was malicious only after it has already cost you money or trust. That's why running this check — even once a month — is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether the DNS Supply Chain tool belongs in your toolbox, this section is for you. Below you'll meet three real people — a GRC / vendor risk manager, a incident responder, and a security architect — facing three real situations where this tool turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: Third-Party Risk Review

Imagine you're a GRC / vendor risk manager. Align written vendor inventory with actual DNS-authorized vendors to catch shadow dependencies and stale authorizations.

Why it matters: Close gaps between contracted vendor list and actual trust surface.

Story 2: Blast-Radius Assessment

Imagine you're an incident responder. During a vendor-industry breach (DNS (Domain Name System) provider, CA, email service), identify all owned domains that depend on that vendor.

Why it matters: Rapid scoping of compromised-vendor impact across the domain portfolio.

Story 3: Single-Point-of-Failure Audit

Imagine you're a security architect. Identify domains with only one NS provider, one CAA issuer, or one email-sender vendor — single points of failure for availability and trust.

Why it matters: Inform DNS (Domain Name System), CA, and email-sender redundancy planning.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for the DNS Supply Chain tool — or one of the tools right next to it in this category. If any of these are on your calendar this month, that's your sign:

• Inside a signup form, payment flow, or comment system, to score risk in real time.

• When investigating a customer complaint about a suspicious link or message.

• On a recurring schedule, to monitor lookalike domains targeting your brand.

• During incident response, to enrich an alert with reputation context.

If you can see yourself in even one of those bullets, the DNS Supply Chain tool will pay for itself the first time you use it.

Still not sure? Here's the easiest test in the world. Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is the DNS Supply Chain tool useful for my job?" The assistant will look at the tool, ask you a couple of follow-up questions about what you're trying to accomplish, and give you a straight answer in plain English. No commitment, no signup forms, no jargon.

If you've connected the EdgeDNS MCP server to Claude, ChatGPT, Gemini, Cursor, or any other AI assistant, you don't need to write any code. Just ask in plain English:

"Use the DNS Supply Chain tool to check example.com and explain anything that looks wrong in plain language."

The AI will figure out which tool to call, fill in the right parameters, run it, and then explain the result back to you. No copy-pasting between tabs. No reading raw JSON. No memorizing endpoint names.

If you're a developer and want to call the endpoint from a script or your own application, here's the simplest possible example. Replace the placeholder API key with the real one from your dashboard.

There's just one piece of information you need to provide. The table below explains exactly what it is and what a real value looks like.

When you call this tool, you'll get back a JSON object with the fields below. If you're talking to it through an AI assistant, the assistant reads these for you and explains them in plain language — you don't need to memorize them.

These tools pair naturally with DNS Supply Chain. If you're already running this check, the related ones often answer the next question that comes up:

• SPF Trust Surface — Map every sender authorized by your SPF include chain

• Nameservers — List nameservers and detect DNS provider

• CAA Records — Check which CAs can issue certificates

• DNS Provider — Identify DNS hosting provider

If you're using an AI assistant through MCP (Model Context Protocol), you can ask it to run several of these in one go: "Check DNS Supply Chain and the related tools for example.com and tell me what looks off."

If any words on this page felt like jargon, here's a plain-language version. Click any linked term to read a full beginner-friendly guide.

DNS (Domain Name System) — The internet's address book. When you type a website name, DNS turns it into the actual numeric address computers use to find each other.

HTTPS (secure HyperText Transfer Protocol) — HTTP with encryption — the little padlock in your browser. It means nobody between you and the website can read what you're sending.

SPF (Sender Policy Framework) — A list, published in your DNS, of which servers are allowed to send email pretending to be you. Helps stop spammers from forging your address.

DoH (DNS over HTTPS) — A modern way of sending DNS queries that hides them inside encrypted HTTPS traffic, so people on the same network can't see which websites you're looking up.