📡 Tool

DNS Lookup — A, AAAA, MX, TXT, NS, CNAME, SOA Records

Query all DNS record types for any domain — A and AAAA addresses, MX mail servers, TXT records (SPF, DKIM, DMARC, verification tokens), NS authoritative nameservers, CNAME aliases, and SOA zone metadata. Server-side authoritative resolution, no JavaScript required.

Popular Lookups

What this tool does

The DNS Lookup tool queries seven record types for any domain in a single request: A (IPv4 address), AAAA (IPv6 address), MX (mail exchange), TXT (text records used for SPF, DKIM, DMARC, and various verification tokens), NS (authoritative nameservers), CNAME (alias to another hostname), and SOA (Start of Authority — zone metadata including the primary nameserver and the responsible-party email). Each record type renders in its own table with the host, TTL, and value columns. The check uses PHP's native dns_get_record() function which talks to your server's configured resolvers — no third-party API, no rate limits.

What is different about this tool: all seven record types in one query. Most free DNS lookups make you select a single record type and submit again for each one — you're three submissions in before you have the basic picture (A + MX + NS). This tool returns everything at once so you see the full DNS posture of a domain in two seconds. Useful for migration audits, mail-deliverability debugging, and incident-response triage where you need to understand what a domain is configured to do.

How it works under the hood

When you submit a domain, the tool extracts the registrable hostname (stripping protocol and path) and runs dns_get_record() seven times with each of the requested record-type constants — DNS_A, DNS_AAAA, DNS_MX, DNS_TXT, DNS_NS, DNS_CNAME, DNS_SOA. Each call queries the server's configured DNS resolver chain (typically the upstream resolver of our hosting provider) which in turn walks the DNS hierarchy from the root servers down to the domain's authoritative nameservers.

Per-record-type rendering. Records that exist render as tables; record types with no entries are silently skipped (most domains don't have CNAME at the apex, for example, so those tables won't appear). Each row shows the host (the FQDN being resolved), the TTL (how long the resolver caches the answer in seconds), and the value field — IP for A/AAAA, target hostname for CNAME/NS, priority+target for MX, full text for TXT, mname+rname for SOA.

TTL is information, not noise. The TTL field shows how long resolvers cache the answer. Low TTLs (under 60 seconds) signal high-availability infrastructure or fast-flux DNS used by attacker infrastructure. Standard TTLs (3600 = 1 hour, 86400 = 24 hours) signal stable infrastructure.

TXT records are the most information-dense. TXT records store free-form text and have become the standard way to attest various things about a domain. Look for SPF (v=spf1 ... — authorises which servers can send mail for the domain), DMARC (v=DMARC1 ..., lives at _dmarc.domain.com — declares how recipient mail servers should handle SPF/DKIM failures), DKIM keys (live at selector._domainkey.domain.com), domain-verification tokens (Google Workspace, Microsoft 365, Atlassian, Notion, etc. all drop verification TXT records), and BIMI records for branded inbox logos. The presence and configuration of these records tells you a lot about the operational maturity of the domain.

What this tool does NOT do. It queries through your server's configured resolver, not directly against the domain's authoritative nameservers — so the answer can occasionally be cached-stale during DNS migrations. For authoritative-direct queries, use dig +trace or dnschecker.org. The tool also doesn't query CAA, DS, DNSKEY, or other less-common record types. Results cache for one hour via WordPress transients keyed by domain.

Five real-world use cases

Audit email security posture (SPF, DKIM, DMARC, BIMI)

Run the lookup against your own domain and look at the TXT records. You should see SPF (<code>v=spf1 ...</code>), DMARC at <code>_dmarc.yourdomain.com</code> (<code>v=DMARC1 ...</code>), DKIM keys at known selectors (<code>google._domainkey</code> for Workspace, <code>selector1._domainkey</code> for Microsoft 365), and ideally BIMI at <code>default._bimi.yourdomain.com</code>. Missing SPF is the most common gap; missing DMARC is the second; weak DMARC policy (<code>p=none</code>) is the third. Each of these takes about half a day to fix and pays back permanently in reduced phishing impersonation.

yourdomain.com

Trace the mail-flow path of a domain

MX records tell you where mail for the domain is delivered. <code>aspmx.l.google.com</code> means Google Workspace; <code>*.protection.outlook.com</code> means Microsoft 365; <code>route1.mx.cloudflare.net</code> means Cloudflare Email Routing. The MX target plus its priority (lower number = higher priority) maps the mail-flow chain. For a domain that claims to be a real business, the absence of any MX records is a strong fraud signal — legitimate operations have email infrastructure.

Identify infrastructure dependencies via NS and CNAME

NS records show which nameservers are authoritative for the domain. <code>*.cloudflare.com</code> means the domain uses Cloudflare DNS (and probably Cloudflare's broader stack). <code>*.awsdns-*.com</code> means Route 53. <code>ns1.your-managed-dns-provider.com</code> means whoever that provider is. CNAME records show alias relationships — many SaaS integrations require a CNAME (<code>support.yourdomain.com → yourcompany.zendesk.com</code>, for example). Map both for any domain you're auditing to understand what third-party infrastructure it depends on.

Bug bounty: discover SaaS subdomains via CNAME enumeration

When recon discovers subdomains, the CNAME values tell you which SaaS the target uses. A subdomain CNAME'd to <code>*.heroku.com</code> means a Heroku app; <code>*.cloudfront.net</code> means CloudFront-fronted; <code>*.netlify.app</code> means a Netlify deploy. SaaS-hosted endpoints are interesting bug-bounty surface — they often have less-tested integration code, and many have known classes of misconfiguration (S3 takeover, Fastly host-header bypass, etc.). The CNAME field is your fastest signal for what platform to test for.

subdomain.target.com

Verify a DNS migration completed correctly

You changed nameservers, updated A records, or reconfigured email routing. Run the lookup against the changed domain to verify the new records are visible. Check the TTLs — if they match your new low TTL settings rather than the old high ones, propagation is in progress correctly. If the old values are still showing, you're either still in the propagation window (TTL hasn't expired in our resolver's cache) or the change didn't apply. Wait the TTL window and re-query.

Common mistakes & edge cases

Confusing the resolver\u2019s cached answer with the authoritative truth

dns_get_record() queries through the system resolver, which caches answers based on TTL. A domain that just changed records may still return the old values from a cached intermediate resolver. For authoritative-direct queries that bypass caching, use dig @8.8.8.8 +trace yourdomain.com or a multi-region checker like dnschecker.org. The cached answer is normally correct — but during DNS migrations or incident response, always verify against the authoritative nameservers directly.

Reading TXT records as just text without parsing the structure

TXT records look like free-form text but most have specific structures. SPF starts with v=spf1; DMARC starts with v=DMARC1; DKIM keys start with v=DKIM1; BIMI starts with v=BIMI1. Verification tokens (google-site-verification=..., MS=ms..., atlassian-domain-verification=...) follow vendor-specific formats. Reading them as plain text misses the structured data — use a dedicated SPF/DMARC checker (mxtoolbox.com, easydmarc.com) for validation against the spec.

Querying the wrong subdomain for DMARC

DMARC lives at _dmarc.yourdomain.com, NOT at yourdomain.com. If you query the apex domain and don't see DMARC, it doesn't necessarily mean DMARC is missing — it just means you queried the wrong host. Always query _dmarc.yourdomain.com explicitly to check DMARC status. The same pattern applies to DKIM (selector._domainkey.yourdomain.com) and BIMI (default._bimi.yourdomain.com).

Ignoring AAAA records because IPv4 still works

If your domain has only A records (IPv4) and no AAAA (IPv6), users on IPv6-only networks can't reach you. Mobile carriers, large enterprise networks, and many ISPs are increasingly IPv6-first. A missing AAAA record isn't a security failure but it is a reachability gap — and the fix (add an AAAA record pointing to your server's IPv6 address) is a one-line change in your DNS provider's UI.

Treating CNAME at the apex as supported

DNS standards prohibit CNAME records at the apex (yourdomain.com with no subdomain) because CNAME conflicts with the SOA and NS records that must exist there. Some DNS providers offer "ALIAS" or "ANAME" pseudo-records that simulate apex CNAMEs by resolving the target at query time and returning A/AAAA records. If you see what looks like an apex CNAME in this tool, it's actually one of these pseudo-records being resolved on the provider's side.

Assuming an empty result means no DNS configured

If the tool returns no records for a domain, the domain might genuinely have no records — or your query might be hitting a temporary resolver issue, the cache might be poisoned, or you might have typed the domain wrong. Re-query, try from a different network if possible, and verify the domain spelling. Genuinely no-DNS domains are rare for live websites; if a domain has a working website but returns no DNS, you've almost certainly hit a transient resolver problem.

Frequently Asked Questions

Paste the domain into the lookup above. The tool returns A and AAAA addresses, MX mail servers, TXT records, NS authoritative nameservers, CNAME aliases, and SOA zone metadata in a single query. Each record type renders as its own table — record types with no entries are silently omitted. The query takes about 2 seconds.
A records map a domain to an IPv4 address (32-bit, like 192.0.2.1). AAAA records map a domain to an IPv6 address (128-bit, like 2606:4700:4700::1111). Modern websites typically have both — A for legacy IPv4-only clients, AAAA for IPv6-capable clients. Lacking AAAA isn't a security issue but it does limit reachability for IPv6-only networks.
MX (Mail Exchange) records tell sending mail servers where to deliver mail addressed to the domain. Each MX record has a priority (lower number = tried first) and a target hostname. Common patterns include aspmx.l.google.com for Google Workspace, *.protection.outlook.com for Microsoft 365, and route*.mx.cloudflare.net for Cloudflare Email Routing. A domain with no MX records typically means it doesn't accept inbound email.
SPF lives in TXT records at the domain apex (look for v=spf1 ...). DKIM lives at selector subdomains (query selector._domainkey.yourdomain.com — common selectors are google, selector1, k1). DMARC lives at _dmarc.yourdomain.com. For full validation against the spec, use a dedicated DMARC checker like easydmarc.com.
TTL (Time To Live) is the number of seconds a resolver caches a DNS answer before re-querying. Low TTL (60s) lets you change records quickly; high TTL (86400s = 24h) reduces query load but means changes take up to 24 hours to propagate. Lower the TTL ahead of any planned DNS change, wait one TTL cycle, then make the change so users pick it up quickly.
CNAME (Canonical Name) records create an alias from one hostname to another. www.example.com CNAME example.com means "when someone asks for www.example.com, give them the same answer as for example.com". CNAMEs are common for SaaS integrations (support.yourdomain.com CNAME yourcompany.zendesk.com). DNS standards prohibit CNAMEs at the apex domain — for that, providers offer ALIAS/ANAME pseudo-records.
SOA (Start of Authority) is the metadata record for the DNS zone. It lists the primary authoritative nameserver, the responsible-party email (with @ replaced by a dot — hostmaster.example.com means hostmaster@example.com), the serial number (incremented when the zone changes), and various refresh/retry/expire/minimum TTL values. Mostly relevant for DNS administrators.
DNS standards (RFC 2181) prohibit CNAME records at the apex of a zone because CNAME would conflict with the SOA and NS records that must exist there. To achieve apex-CNAME-like behaviour, DNS providers offer pseudo-records called ALIAS or ANAME that resolve the target hostname on the provider's side and return its A/AAAA records to the client. From a query perspective they look like A/AAAA records, not CNAME.
An authoritative DNS server holds the actual records for a domain (the truth). A recursive resolver looks up records on behalf of clients — it queries the root, then the TLD nameservers, then the domain's authoritative nameservers, then returns the answer to the client and caches it. This tool queries through our server's recursive resolver, so the answer reflects what that resolver has cached. For direct authoritative queries, use dig +trace from your own machine.
DNS changes propagate at the speed of TTL expiry on cached answers in resolvers worldwide. To minimise propagation pain for planned changes: lower the TTL to 60-300 seconds at least one full TTL cycle before the change, make the change, then raise the TTL back to its production value once you've confirmed the change is everywhere.

Related Security Tools

🔍 WHOIS Lookup Identify the registrar and registrant of the domain 🌐 IP Address Lookup Geolocate the IP that the A record points to 🔒 SSL Certificate Verify the cert served on the resolved IP 📧 Email Header Analyzer Validate how SPF/DKIM/DMARC actually behave on inbound mail

Learn More

📚 Identity Based Attacks 2026 Email spoofing in the broader identity attack chain 🧭 OSINT Fundamentals DNS data as an OSINT primitive 🏹 Bug Bounty Reconnaissance Subdomain enumeration techniques and pivoting