Third-party services in your DNS

1 Introduction

When you sign up for Google Workspace, Microsoft 365, Atlassian or a hundred other cloud tools, the provider asks you to prove you own your domain. The usual way is to add a short text record to your DNS, something like atlassian-domain-verification=.... The provider checks it, and the record usually stays there for years.

Those records are public. Anyone can read them in one command, and together they form a list of the software vendors your company uses. The "Third-party services" block of a domain scan reads that list for you, and the "Raw TXT records" block shows every TXT value as published. This page explains what the list reveals, why it helps phishers, and how to keep it short and current.

DNS signals the report reads to name a vendor: TXT verification tokens, SPF includes, MX servers

Command is enough for anyone to list your TXT records: dig TXT

Public

DNS has no access control: what you publish there, every attacker can read

2 How It Works

Domain verification is a simple handshake. Only the person who controls a domain's DNS can add records to it, so a record with a random value proves control. The report then recognises each vendor from three places in your DNS:

TXT

A verification token: you proved to this vendor that you own the domain, so you have (or had) an account there.

SPF

An include: in your SPF record: this vendor is allowed to send email as your domain.

Your mail servers: this vendor receives every email sent to your domain.

Why a vendor list helps an attacker

Generic phishing ("your mailbox is full") is easy to spot. Targeted phishing uses a pretext the victim expects. If your DNS says you use Atlassian, an attacker sends your staff a perfect copy of a Jira or Confluence notification, with a link to a fake Atlassian login page. If it says DocuSign, the pretext is a contract to sign. Your employees receive real emails from these tools every day, so the fake one does not stand out. This is social engineering made cheap: the reconnaissance is already done.

3 Detailed Analysis

Verification tokens: what each one says

The "Third-party services" block groups recognised vendors by category, and tags each one with where it was seen (TXT, SPF, MX). Some common tokens and what they reveal:

google-site-verification=...         ; Google (Search Console, Workspace)
MS=ms12345678                        ; Microsoft 365
atlassian-domain-verification=...    ; Atlassian (Jira, Confluence)
facebook-domain-verification=...     ; Meta business account
apple-domain-verification=...        ; Apple services
docusign=...                         ; DocuSign

A token proves an account existed, not that it is in use

Nobody removes a token when they stop paying for a tool. A long list often means a mix of current vendors, trials from years ago and tools someone tested once. You are the only one who can tell which is which.

A token is tied to the account that created it

With some vendors (Google Search Console is the classic example), whoever created the token stays a verified owner of your domain as long as it is published. A token created by a former employee's personal account or a past agency keeps that access alive.

SPF and MX vendors carry more weight

A vendor in your SPF can send mail that passes as yours; your MX provider reads all inbound mail. These are the vendors whose security matters most. See SPF, DKIM and DMARC for how to keep the SPF list tight.

Raw TXT records

This folded block shows every TXT value on your domain exactly as DNS returns it, including the ones the report does not recognise. You can get the same list yourself:

dig +short TXT example.com
nslookup -type=TXT example.com      # on Windows

What you should expect to see

One SPF record (v=spf1 ...) and the verification tokens of the tools you actively use. DMARC and DKIM live on other names (_dmarc. and selector._domainkey.), so they do not appear on the apex.

What should never be there

TXT records are sometimes used as a note pad: an internal IP, a contact name, a password, an API key, a license string. Anything secret in a TXT record is published to the world. Remove it and rotate the secret, since DNS history services may already have a copy.

Unrecognised values

A value the report does not name is not suspicious in itself: there are thousands of vendors. Search the prefix (the part before =) to find who it belongs to.

Cleaning up, in order

Urgent: remove any secret (key, password, token for an API) found in a TXT record, and rotate it at the source.

Soon: remove the SPF include of every vendor that no longer sends mail for you. This is a real permission, not just information.

Hygiene: list every token, match it to a vendor and an owner, and delete the ones for tools you left. Before deleting a token for a tool you still use, check that vendor's documentation: some re-check the record regularly (Google Search Console does) and drop your verification if it disappears, others only need it once.

Process: make "remove the DNS records" a step of vendor offboarding, next to cancelling the contract and closing accounts.

From vendor list to vendor risk

The block is also a good starting point for a third-party risk review: it is the list of companies that hold your data or act in your name.

Protect the accounts, not just the DNS

For each vendor still in use, enforce SSO or two-factor authentication on the admin accounts. Hiding the token would not stop phishing; strong login does.

Warn your staff with the real list

Phishing training is more useful when it names your actual tools: "attackers know we use Atlassian and DocuSign; check the address bar before you log in".

Follow vendor incidents

When one of your listed vendors announces a breach, you already know you are concerned. Subscribe to their security or status pages.

See what your DNS says about you on mlab.sh

A domain scan recognises the vendors named by your verification tokens, SPF includes and mail servers, and shows every raw TXT record you publish.

Scan your domain on mlab.sh

4 Red Flags

A secret in a TXT record

An API key, a password or an internal address published in DNS is public. Remove it and rotate it today.

An SPF include for a vendor you left

That vendor's platform can still send mail that passes as yours. Remove the include.

Tokens nobody can explain

A verification for a tool no team admits using may be shadow IT, or an account that outlived its owner. Find out who created it.

Several tokens for the same vendor

Two google-site-verification values can mean two separate accounts verified the domain. Make sure both belong to the company.

Emails "from" a listed vendor asking you to log in

Expect them: your vendor list is public. Open the tool from a bookmark rather than from the link, and report the message.

Related Modules

SPF, DKIM and DMARC for your domain

Stop attackers from sending email as your domain: what SPF, DKIM and DMARC do, how to read a scan result and how to reach p=reject safely.

What is DNS?

The Internet's phone book: how DNS translates domain names into IP addresses.

What is social engineering?

Social engineering attacks: how scammers hack humans instead of systems, and what to watch for.