The vendor list hiding in a DNS record

Nobody writes a press release about switching help desks. But the DNS record changes the same week, it is public, and anyone with a terminal can read it.

DNS is the least curated surface a company has. Marketing owns the homepage. Legal owns the terms. Nobody owns the zone file — it gets edited by whoever is standing up a tool, and the edits stay there long after the launch post is forgotten. That makes it unusually honest. A pricing page tells you what a competitor wants you to believe about their business. Their SPF record tells you which vendors they are actually paying.

This is not a growth-hacking trick. It is one of the cheapest structural reads available, it takes about ten minutes per competitor, and the output is a list of names you can check again in ninety days.

Start with the SPF record

An SPF record is a TXT entry that lists every service permitted to send email as that domain. Any tool that sends mail on their behalf has to be in it, or the mail lands in spam. Which means the record is a self-maintained, compliance-enforced list of their email-adjacent vendor stack.

dig +short TXT competitor.com | grep spf

Read the include: entries. include:_spf.google.com and you know their workplace. include:mailgun.org, include:sendgrid.net, or include:amazonses.com tells you how transactional mail leaves the product. include:spf.mandrillapp.com usually means Mailchimp somewhere in the marketing stack. include:mktomail.com is Marketo, _spf.salesforce.com is Salesforce, spf.hubspotemail.net is HubSpot.

The composition matters more than any single entry. A company with Google Workspace, SES, and nothing else is running lean and building in-house. A company carrying Marketo, Salesforce, Outreach, and a dedicated deliverability vendor has a revenue org with headcount behind it. You are reading a budget, not a config file.

MX and DMARC tell you the operating maturity

MX records are duller but faster to read: dig +short MX competitor.com. Google or Microsoft covers almost everyone. The interesting case is a company that moved — Google to Microsoft usually follows an enterprise push or a new CFO, and the direction of travel is worth noting.

DMARC is the better maturity tell. dig +short TXT _dmarc.competitor.com returns a policy. p=none means they set it up and never finished. p=quarantine or p=reject means somebody did the work of inventorying every sender and enforcing it — which is a security-program signal, and usually a sign they are answering enterprise questionnaires. It is the same read as a trust page or a subprocessor list, just three years earlier in the maturity curve and without the marketing polish.

CNAMEs name the customer-facing tools

Subdomains that point somewhere else give up the vendor immediately. help.competitor.com resolving to Zendesk, Intercom, or HelpScout. status.competitor.com to Statuspage or Better Stack. docs. to ReadMe, Mintlify, or GitBook. careers. to Ashby, Greenhouse, or Lever. go. or info. to a marketing automation platform.

If you already ran a subdomain sweep, you have the hostnames. This is the second pass: resolve each one and write down what it points at. Ten minutes, and you have their customer-facing tooling with no guessing.

dig +short CNAME help.competitor.com

Two caveats. A CNAME proves a tool is configured, not that it is used well — a Zendesk instance can be a ghost town. And a subdomain that resolves to nothing may be an abandoned experiment rather than a signal.

Read the deltas, not the snapshot

A single DNS read is trivia. The same read repeated is intelligence.

The changes worth noticing:

• A new include: appears. They bought something. If it is a sales-engagement tool, an outbound motion is starting. If it is a support vendor, a support team is forming.
• An include: disappears. They churned off a tool, or consolidated. Vendor removals are rarer than additions and usually mean a budget decision, not a preference.
• A CNAME repoints. help. moving from one help desk to another is a migration somebody had to justify internally. That project consumed a quarter of somebody's roadmap.
• DMARC tightens. Enterprise pressure. Expect a security page, a SOC 2 badge, and an enterprise tier to follow within a few quarters.
• A new subdomain appears with a vendor CNAME. academy., community., partners. — a new go-to-market surface being staged before launch, same way a sitemap leaks unannounced pages.

The delta gives you something the snapshot never does: a date. "They added an outbound tool" is a guess. "They added it in the second week of March" is a timeline you can line up against their hiring and their pricing changes.

Where this read goes wrong

Three failure modes, all common.

DNS records go stale. Companies leave dead include: entries in SPF for years because removing them risks breaking something nobody remembers. An entry's presence proves it was true once, not that it is true now. Treat additions as strong signal and long-standing entries as weak.

Agencies pollute the record. If a competitor outsources demand gen, the agency's platform shows up in their SPF and tells you about the agency's stack, not theirs. Cross-check against job postings — if nobody in-house touches that tool, it probably belongs to a contractor.

And resolvers disagree. Records propagate unevenly and some providers return partial results. If a change looks dramatic, check from a second resolver before you act on it.

How Seeto handles this

Seeto monitors a competitor's public surfaces continuously and reports what changed as discrete, dated events — so a vendor swap surfaces as a change with a timestamp rather than something you notice six months late.

What it does not do: Seeto will not tell you why they switched help desks, or whether the new tool is working. It does not read intent. The diff is the raw material; the interpretation in the sections above is still yours to do, and it is the part that actually matters. A tool that told you it knew why Marketo left the record would be guessing.

The two-minute version

1. dig +short TXT competitor.com | grep spf — write down every include: entry and name the vendor behind each.
2. dig +short MX competitor.com — Google, Microsoft, or something that raises a question.
3. dig +short TXT _dmarc.competitor.com — p=none is unfinished, p=reject is a security program.
4. Resolve help., status., docs., careers., and go. — record what each points at.
5. Save the raw output with today's date. The snapshot is worth little; the diff in ninety days is worth the whole exercise.

The best competitive signals are the ones nobody thought to sanitize. DNS is near the top of that list, and it will stay there precisely because it is too boring to guard.