dns records leak your whole org's footprint
dig +short MX example.com; dig +short TXT example.com | head -2dns is basically a public org chart, if you know how to read it
your domain's dns records are public by design. anyone on earth can query them without touching your network, logging in, or triggering any alert. that's the point of dns. but it also means every txt record, mx entry, and subdomain you've ever created is sitting out there describing your organization to whoever bothers to look. attackers use this for recon before they ever send a phishing email. you can use the exact same lookups to see what you're exposing.
breaking down the command
the reel showed this one liner:
dig +short MX example.com; dig +short TXT example.com | head -2dig is a dns query tool that ships with most linux and mac systems. +short strips out the verbose header junk and just gives you the answer. MX asks "what mail servers handle email for this domain." TXT pulls text records, which is the junk drawer of dns where orgs stuff spf policies, dkim keys, domain verification strings, and sometimes stuff that never should have been public. piping to head -2 just limits the output so you're not scrolling forever on domains with a lot of txt entries.
what your mx records actually reveal
mx records tell you exactly who hosts your email. is it google workspace, microsoft 365, or a self hosted mail server? that single answer narrows down an attacker's entire playbook. it tells them which login portal to spoof, which known vulnerabilities might apply if you're self hosting, and whether your org is a big enough target to justify the effort. as a defender, run this against your own domain and ask: does this match what i expect? if you migrated providers two years ago and old mx records are still floating around, that's a sign of stale dns hygiene, not just an eyesore.
txt records are where the real leaks hide
this is the section people skip and shouldn't. txt records commonly contain:
spf records that list every third party service allowed to send mail as your domain, which is basically a vendor list for free. domain verification strings from services like google, stripe, salesforce, or slack, confirming exactly which saas tools your org uses. dkim selectors that, combined with other lookups, can help map your email infrastructure in more detail than most companies realize they've published.
none of this is a "hack." it's all sitting in public dns. but stacked together, it builds a surprisingly complete picture of your tech stack, which is exactly what recon is.
check your own footprint right now
run the same two commands against your own domain and any subdomains you manage:
dig +short MX yourdomain.com
dig +short TXT yourdomain.comthen go one step further and check for forgotten subdomains, since those often carry their own dns baggage:
dig +short A old.yourdomain.com
dig +short CNAME staging.yourdomain.comlook for anything you don't recognize, old vendor verification strings for tools you stopped using years ago, or spf entries pointing at services you decommissioned. every one of those is a small clue an attacker doesn't have to work for.
the takeaway
you can't make dns private, and you shouldn't try. the fix isn't hiding, it's hygiene. audit your mx and txt records on a schedule, kill off verification strings and spf entries for tools you no longer use, and keep a running doc of what should be there so anything new stands out immediately. the five minutes it takes to run these two dig commands against your own domain is cheaper than finding out what's leaking after someone else already mapped it for you.