Look up every DNS record for any domain — A, AAAA, MX, TXT, CNAME, NS, SOA, CAA, and 18 more types.

A single query returns six independently useful classes of output. Each record type is queried in parallel, so the slowest-responding type (typically a CAA or DNSSEC record on a busy zone) bounds total response time, not the sum.

DNS stopped being only about hostname resolution years ago. It's now the substrate for email authentication, certificate-issuance restrictions, SaaS ownership proofs across dozens of providers, service discovery, and encryption pinning. Reading DNS is reading an organization's infrastructure choices:

• DNS reveals the SaaS stack. Microsoft.com publishes ~50 TXT records — Google, Atlassian, HubSpot, Mixpanel, DocuSign, Zoom, OpenAI, Anthropic, 1Password, Airtable, Sitecore, and a dozen more. Each represents an integration. It's the most honest BOM (bill of materials) you'll get on a public company.
• DNS controls email trust. SPF, DKIM, DMARC, MTA-STS — all live in DNS. Misconfigure any one and your transactional email lands in spam. Forget DMARC and you're inviting impersonation.
• DNS controls who can issue your certs. CAA records restrict which Certificate Authorities can issue for your domain. Absent CAA, any of the ~50 trusted CAs in the WebPKI can issue — a meaningful attack surface.
• DNS is the first thing to misconfigure. Industry incident data consistently shows that 60%+ of "site is down" outages are actually DNS issues — wrong record, missing record, propagation delay, or registrar-vs-authoritative mismatch.
• DNS changes propagate at TTL speed. Set a TTL of 86400 (24 hours) and you've committed for 24 hours. Plan migrations by dropping TTLs first, waiting out the old TTL, then making the actual change. Most outages from "DNS changes haven't propagated" are just impatience with TTL math.

We bypass resolver caches and query the domain's authoritative nameservers directly. Every record type fires in parallel so the total time is the slowest single query, not the sum.

• Stage 1 — Locate authoritative nameservers Walk from the root to the TLD to the domain's NS records. We do this once per request and reuse the result for every record-type query.
• Stage 2 — Fan out 25 parallel queries One query per record type, fired concurrently against the authoritative servers. Total time bounded by the slowest single response (typically CAA or DNSSEC records on a heavily-loaded zone).
• Stage 3 — Parse per-type A records become IP arrays. MX records expose priority and exchange. SOA fields are broken into nsname/hostmaster/serial/refresh/retry/expire/minttl. TXT records get their own decoding pass.
• Stage 4 — TXT-specific analysis Every TXT string is matched against known prefix patterns: SPF, DKIM, DMARC, MTA-STS, and 30+ SaaS verification token formats. The full SPF record is parsed into its mechanisms and qualifier.
• Stage 5 — Return with metadata Each record type gets a `time` field (ms), and either a `result` (records found) or an `error` with `code` (ENODATA, NXDOMAIN, etc.). Missing types are explicit, not silent.

The common types you'll look at most often, then the specialty types in brief. If you're trying to figure out what a specific record means in the wild, this is the reference.

• A — IPv4 address Maps a hostname to an IPv4 address. The most fundamental record type — every website needs at least one A record (or an AAAA for IPv6-only deployments). Multiple A records create a round-robin set. TTL controls how long resolvers cache the answer before re-querying.
• AAAA — IPv6 address Maps a hostname to an IPv6 address. Adoption is growing but uneven; most sites in 2026 publish both A and AAAA records. AAAA-only sites still exclude a non-trivial share of users on legacy networks.
• CNAME — Canonical name (alias) Aliases one hostname to another. Resolvers chase CNAMEs transparently — a CNAME to example.com is functionally equivalent to whatever example.com resolves to. CNAMEs cannot coexist with other records at the same name (RFC 1034 limitation) and cannot live at the zone apex (use ALIAS or ANAME via your DNS provider's extension if you need root-level aliasing).
• MX — Mail exchange Tells the world where to deliver email for this domain. Each MX record has a priority (lower wins); same-priority records round-robin. microsoft.com's MX is `microsoft-com.mail.protection.outlook.com priority 10` — pointing all inbound mail to Microsoft 365. A domain with no MX record cannot receive email.
• NS — Authoritative nameservers Lists the authoritative nameservers for the zone. The NS record set at the registry must match the set at the authoritative servers themselves — otherwise resolvers can get inconsistent answers. microsoft.com uses azure-dns nameservers spread across .com, .net, .org, and .info — deliberate cross-TLD redundancy.
• SOA — Start of authority Administrative metadata for the zone. Fields: nsname (primary nameserver), hostmaster (admin email with @ replaced by .), serial (zone version, incremented on every change), refresh (secondary nameserver poll interval), retry (poll-after-failure interval), expire (when secondaries stop serving stale data), minttl (negative-cache TTL — how long resolvers cache 'this record does not exist').
• TXT — Free-form text Used for SPF, DKIM, DMARC, MTA-STS, and domain-ownership verification across dozens of SaaS providers. The most semantically overloaded record type — see section 05 for a decoding guide. Microsoft.com publishes around 50 TXT records, a typical Fortune-500 footprint.
• PTR — Reverse DNS Maps an IP back to a hostname. Lives in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zones, managed by the IP block owner rather than the domain owner. Important for mail servers — most receivers require matching forward and reverse DNS for senders, and reject mail otherwise.
• CAA — Certificate Authority Authorization Restricts which CAs are allowed to issue certificates for this domain. Helps prevent rogue or compromised CAs from issuing fraudulent certs. Format: `0 issue "letsencrypt.org"` means only Let's Encrypt can issue. The `iodef` flag specifies where CAs should report unauthorized requests; `contactemail` (which microsoft.com publishes) is purely informational.

• SRV — Service location Specifies where to find a particular service for a domain. Used heavily by Office 365 (`_sip._tcp`, `_sipfederationtls._tcp`), XMPP, Minecraft, and various enterprise protocols. Encodes priority, weight, port, and target host in a single record.
• NAPTR — Naming authority pointer Provides regex-based DNS rewriting. Almost exclusively used by ENUM (mapping phone numbers to SIP URIs) and S-NAPTR-based service discovery. You'll rarely see it on consumer-facing domains.
• DS — Delegation signer (DNSSEC) Lives at the parent zone (e.g., at .com for microsoft.com). It's the cryptographic fingerprint of the child's DNSKEY. Without a DS record at the parent, DNSSEC validation fails even if the child publishes DNSKEYs. microsoft.com has no DS record — DNSSEC is not enabled.
• DNSKEY — DNSSEC public key The public key resolvers use to verify DNSSEC signatures on the zone's records. Two flavors: ZSK (zone signing key, rotated frequently) and KSK (key signing key, rotated less often, fingerprinted in the parent's DS record).
• CDS / CDNSKEY — Child-side DNSSEC bootstrap A way for the child zone to tell the parent which DS record to publish, without manual coordination. Adoption is uneven; most registrars still require the DS record to be set manually.
• TLSA — DANE (TLS authentication) Pins a TLS certificate or public key to a hostname via DNS. Requires DNSSEC. Real-world adoption is mostly limited to mail servers under RFC 7672 (DANE for SMTP); HTTPS-over-DANE remains rare.
• SSHFP — SSH host key fingerprint Lets a client verify an SSH host key via DNS (with DNSSEC) instead of trust-on-first-use. Useful in automation; almost invisible on consumer domains.
• SMIMEA — S/MIME certificate binding DANE for email encryption — pins S/MIME certificates to email addresses. Limited adoption; mostly seen in regulated industries with internal CA infrastructure.
• OPENPGPKEY — OpenPGP public key Publishes a user's OpenPGP public key in DNS, keyed by the local part of their email. An alternative to keyservers; never widely adopted.
• DNAME — Delegate an entire subtree Like CNAME, but for a whole subtree. Used in DNS provider migrations, IPv6 PTR delegation, and internationalized domain handling.
• HINFO — Host info (legacy) CPU and OS strings for a host. Obsolete; modern security guidance is to never publish HINFO. You'll only see it on extremely old zones.
• RP — Responsible person (legacy) A human-readable contact for the domain. Largely replaced by the SOA's hostmaster field. Rarely populated.
• LOC — Geographic location Latitude, longitude, and altitude for a host. Originally for routing optimization; in practice, almost never deployed.
• URI — URI pointer Maps a name to a URI. Used in some service-discovery protocols and for advertising web endpoints; uncommon in everyday DNS.
• AVC — Application visibility and control Used in enterprise networks (e.g., Cisco AVC) for traffic classification. Almost never seen in public DNS.

TXT records are free-form strings — there's no schema. Conventions emerged where each record carries a prefix that tells you what it's for. Microsoft.com's ~50 TXT records are a perfect cross-section. Decoded by category:

• v=spf1 ... SPF (Sender Policy Framework). Declares which IPs and providers can send mail for this domain. Always ends with `-all` (strict — reject unlisted), `~all` (soft fail — junk unlisted), `?all` (neutral — no judgement), or `+all` (allow all — dangerous, effectively useless).
• v=DMARC1; p=... DMARC policy. Lives at the `_dmarc.<domain>` subdomain, not at the root. Values for `p=`: `none` (monitor only), `quarantine` (junk failures), `reject` (block failures). Plus `pct=` (percentage enforced), `rua=` (aggregate reports), `ruf=` (forensic reports).
• v=DKIM1; k=rsa; p=... DKIM public key for verifying outbound mail signatures. Lives at `<selector>._domainkey.<domain>`. You'll find one per active mail-sending selector — Google uses `google`, Microsoft uses `selector1` and `selector2`, third-party senders use their own.
• v=STSv1; ... MTA-STS — Strict Transport Security for inbound mail. Lives at `_mta-sts.<domain>`. Tells sending servers to enforce TLS when delivering mail to this domain.

• google-site-verification= Google Workspace, Search Console, Tag Manager, and Analytics domain ownership proof. A domain may carry multiple google-site-verification tokens if different Google products were verified separately.
• ms-domain-verification= Microsoft 365, Azure AD, and Power Platform domain verification. Multiple entries per domain are common when different MS tenants or services are bound to the same domain.
• MS=msXXXXXXXX Older Microsoft verification format (predates `ms-domain-verification=`). Still seen on long-established domains that never re-verified under the newer format.
• facebook-domain-verification= Meta (Facebook/Instagram) Business Manager and ad account claim. Required to run ads on a domain or to use domain-based event matching.
• atlassian-domain-verification= Atlassian Cloud (Confluence, Jira, Bitbucket) workspace ownership. Required to enforce Atlassian Access SSO across the domain's users.
• apple-domain-verification= Apple Business, Apple Pay, and Apple ID domain claim. Required for certain payment flows and enterprise SSO.

• SaaS verification tokens (one prefix per service) mixpanel-domain-verify, docusign, zoom-domain-verification, 1password-site-verification, airtable-verification, hubspot-developer-verification, linear-domain-verification, sitecore-domain-verification, liveramp-site-verification, hcp-domain-verification, workplace-domain-verification, openai-domain-verification, anthropic-domain-verification — each is a service-specific ownership proof. The mere presence of these tells you the org uses the corresponding SaaS product.
• d365mktkey= Dynamics 365 Marketing email-sending key. Multiple entries are normal — D365 issues a separate key per region or per environment.
• Unprefixed alphanumeric strings Many domains carry verification tokens with no obvious prefix (e.g., `fg2t0gov9424p2tdcuo94goe9j` on microsoft.com). These are usually legacy or platform-specific formats — they exist because some verification system asked for them. Without knowing the issuing platform, they're effectively opaque.
• Anything starting with v=... By widely-followed convention, `v=<TAG>` indicates a structured record following a published spec. Beyond SPF, DMARC, DKIM, MTA-STS, you'll occasionally see vendor-specific schemes (Microsoft publishes a `v=MCPv1;` format on microsoft.com tied to certificate provisioning).

DNS error responses look cryptic but each one has a specific meaning. Reading them correctly tells you whether you're looking at a missing record, a missing domain, a slow nameserver, or a misconfigured zone:

• ENODATA The domain exists, but there's no record of the type you requested. microsoft.com returns ENODATA for SRV, NAPTR, PTR, TLSA — meaning Microsoft simply doesn't publish those record types at the apex. This is not an error; it's an absence.
• NXDOMAIN The domain itself does not exist at all. Different from ENODATA — NXDOMAIN means "no such name in any record type." If you see NXDOMAIN for a domain you just registered, give the registry's NS records a few minutes to propagate.
• SERVFAIL The authoritative nameserver returned a server failure. Usually means a DNSSEC validation failure (key rotation skipped a beat) or an internal nameserver error. Re-query in a few minutes; if it persists, the zone has a real configuration issue.
• Timeout (no response) The nameserver didn't reply within the resolver's timeout. Could be transient network, an overloaded resolver, or a firewalled nameserver. Re-query before drawing conclusions.
• Inconsistent answers across servers If different authoritative nameservers in the same zone return different records, the zone hasn't fully propagated from the primary to the secondaries — or someone updated one nameserver and forgot the others. Wait, or escalate to your DNS provider.
• Records resolve, site still down DNS is doing its job — the failure is downstream. Check the IPs returned for the A/AAAA records: are they reachable? Is the cert valid? Is the application running? DNS is the first layer to suspect, but not always the actual culprit.
• Old IP still showing up Resolver-side caching. The TTL on the old record hasn't expired yet at the resolver you're querying through. Either wait out the TTL or flush the resolver cache (`sudo systemctl restart systemd-resolved` on Linux; `ipconfig /flushdns` on Windows; `sudo dscacheutil -flushcache` on macOS).

Every record type returned by this tool is available as JSON. By default the API queries all 25 types; pass `types=` to limit to specific ones. Rate-limited per IP for free use; API keys available for high-volume monitoring.

curl https://api.domainscan.in/v1/dns?domain=microsoft.com

curl "https://api.domainscan.in/v1/dns?domain=microsoft.com&types=A,AAAA,MX,TXT,CAA"

const res = await fetch(
  'https://api.domainscan.in/v1/dns?' +
  new URLSearchParams({
    domain: 'microsoft.com',
    types:  'A,MX,TXT'
  })
);
const records = await res.json();

// Extract the MX record
const mx = records.find(r => r.type === 'MX');
console.log(mx.result);
// [{ exchange: 'microsoft-com.mail.protection.outlook.com', priority: 10 }]

// Extract the parsed SPF (lives alongside TXT records)
const spf = records.find(r => r.spf);
console.log(spf.parsed.qualifier);  // '-all'

import requests

r = requests.get(
    'https://api.domainscan.in/v1/dns',
    params={
        'domain': 'microsoft.com',
        'types':  'A,MX,TXT,CAA'
    }
)
records = r.json()

# Find the MX record
mx = next((r for r in records if r.get('type') == 'MX'), None)
print(mx['result'])
# [{'exchange': 'microsoft-com.mail.protection.outlook.com', 'priority': 10}]

# Check whether DNSSEC is enabled (DS record present)
ds = next((r for r in records if r.get('type') == 'DS'), None)
dnssec_enabled = ds and 'result' in ds
print('DNSSEC enabled:', bool(dnssec_enabled))

// Returns an array of record-type objects.
// Each object follows one of two shapes:

// Shape 1 — records found
{
  "type":   "A | AAAA | CNAME | MX | NS | SOA | TXT | ...",
  "result": [/* array or object — varies by record type */],
  "time":   "number (milliseconds)",
  "host":   "string (the queried domain)"
}

// Shape 2 — no records of that type
{
  "type":  "...",
  "error": "No <TYPE> records found | Error resolving <TYPE>",
  "code":  "ENODATA | NXDOMAIN | SERVFAIL",
  "time":  "number",
  "host":  "string"
}

// Plus one extra entry alongside the TXT block: parsed SPF
{
  "spf":    "v=spf1 include:...  -all",
  "parsed": {
    "version":    "v=spf1",
    "mechanisms": { "ip4": [], "include": ["..."] },
    "modifiers":  [],
    "qualifier":  "-all | ~all | ?all | +all",
    "directives": ["include:...", "-all"]
  }
}

// Example per-type result shapes:
// A:    [{ "address": "1.2.3.4",  "ttl": 1724 }]
// AAAA: [{ "address": "2603::1", "ttl": 1622 }]
// MX:   [{ "exchange": "...",    "priority": 10 }]
// NS:   ["ns1.example.com", "ns2.example.com"]
// SOA:  { "nsname": "...", "hostmaster": "...", "serial": 1, "refresh": 3600, "retry": 300, "expire": 2419200, "minttl": 300 }
// TXT:  [["v=spf1 ... -all"], ["google-site-verification=..."]]
// CAA:  [{ "flags": 0, "tag": "issue", "value": "letsencrypt.org", "ttl": 3600 }]

Six patterns we see most often:

• What's the difference between an A record and a CNAME? An A record maps a hostname directly to an IPv4 address. A CNAME aliases one hostname to another — the resolver then chases the alias to find an A record. CNAMEs are useful for pointing subdomains at SaaS providers (e.g., `www → cdn.shopify.com`) but can't be used at the zone apex (the root domain). Most DNS providers offer ALIAS or ANAME records to work around that limitation.
• Why are my new DNS records not resolving? Almost always TTL caching at intermediate resolvers. The records exist; resolvers between you and the authoritative server are still serving the cached old answer until the previous TTL expires. Either wait it out (the TTL value tells you how long), flush your local resolver cache, or query the authoritative nameserver directly (which is what this tool does — bypassing resolver caches entirely).
• What is TTL and how does it affect DNS changes? Time-To-Live, in seconds. It tells caching resolvers how long to keep an answer before re-querying. A TTL of 3600 means "cache for one hour." When planning a DNS change, drop the TTL to 300 (5 min) a day in advance, then wait the original TTL out before making the change. This minimizes the window during which mixed answers are served.
• Why do I see so many TXT records? Each SaaS service that wants to verify domain ownership publishes its own TXT record. Microsoft.com has around 50: SPF, multiple Google verifications (one per Google product), Microsoft's own verification entries, plus tokens for Atlassian, Mixpanel, Zoom, OpenAI, Anthropic, and a dozen others. It's a typical large-enterprise footprint.
• Can I have a CNAME at the root domain (apex)? No — strictly speaking, RFC 1034 prohibits it because CNAMEs can't coexist with the SOA and NS records that must live at the apex. Most managed DNS providers (Route 53, Cloudflare, DNSimple) offer non-standard ALIAS or ANAME records to simulate root-level aliasing — they look like CNAMEs to you but resolve to A records internally.
• What does ENODATA mean vs NXDOMAIN? ENODATA: the domain exists, but no records of that type are published. NXDOMAIN: the domain itself doesn't exist at all. They look similar but mean very different things. ENODATA on MX means "this domain doesn't receive email here." NXDOMAIN on the same query means "this domain doesn't exist anywhere."
• Is DNSSEC mandatory? No — and most domains still don't use it. Adoption is below 10% across .com. It's mandatory for some regulated zones (.gov, .bank), strongly recommended for any domain handling auth or payments, and nice-to-have everywhere else. The cost is operational complexity (key rotation, DS-at-parent coordination); the benefit is cryptographic protection against DNS spoofing.
• How long does DNS propagation actually take? Not as long as people think. Authoritative nameservers see changes within seconds — that's instant. The thing called "propagation" is just resolvers between you and the authoritative server waiting for their cached old answers to expire. If your TTL was 300 seconds, propagation is 5 minutes worst case. If your TTL was 86400, it's 24 hours worst case. "DNS takes 48 hours to propagate" is folklore — it's just whatever TTL was set when the old record was published.