This intelligence module profiles your domain itself — nameservers, DNS provider, TLD (top-level domain) reputation, and the SOA record that governs how your DNS zone propagates. Useful context for due diligence, migrations, or simply understanding your own domain's setup at a glance.
🌿 Beginner — Plain English explanations
What your domain's DNS setup reveals
Every domain has a small profile of DNS metadata that's publicly visible to anyone who looks — which nameservers manage it, which DNS provider that implies, the reputation of its top-level domain (TLD), and technical settings that control how DNS changes propagate. None of this requires special access to discover; it's part of the public DNS system by design.
What's reported
- Nameservers — which servers are authoritative for your domain's DNS records, and by extension, which provider manages your DNS.
- DNS provider — identified from the nameserver pattern (e.g. Cloudflare, AWS Route 53, GoDaddy).
- TLD reputation — some top-level domains (like certain free or historically spam-heavy TLDs) carry lower baseline trust with spam filters and some security tools, independent of anything you do.
- SOA record — the Start of Authority record, which defines how DNS changes propagate and how often secondary nameservers refresh.
- DNSSEC — whether your DNS responses are cryptographically signed, protecting against DNS spoofing and cache poisoning.
- Registrar — who the domain is registered through, distinct from the DNS provider above (you can register with one company and point DNS at another).
- Domain status — registry status flags that can indicate a domain is expired, in a grace/redemption period, or otherwise at risk.
- Wildcard DNS — whether any random, non-existent subdomain still resolves, which can be intentional but is also worth knowing about for subdomain-takeover awareness.
- IDN / Punycode — flags if the domain itself is an internationalized (punycode-encoded) domain, a pattern sometimes used in lookalike-domain phishing.
- Other TXT records — any TXT record not already parsed by the SPF/DMARC checks elsewhere, typically verification tokens (
google-site-verification=, facebook-domain-verification=) or other misc configuration.
Why this is useful
This is genuinely useful context rather than a problem to fix — for instance, confirming your DNS is managed where you expect, or understanding why a competitor's domain might carry more baseline email trust than one on a newer or less common TLD.