DNS Lookup Tool
Free ToolDNS Results
How DNS Resolution Works
When you type a domain into your browser, a lookup begins invisibly. Your operating system checks its local cache first — if it recently resolved the same domain and the TTL hasn't expired, it returns immediately without any network traffic.
If there's no usable cached answer, the query goes to a recursive resolver — a server run by your ISP or a public service like Google (8.8.8.8) or Cloudflare (1.1.1.1). The recursive resolver does the heavy lifting by following the DNS hierarchy from the top down:
- Root servers — don't know the answer but know which servers handle each top-level domain (.com, .net, .org). They return a referral.
- TLD name servers — know which servers are authoritative for each registered domain under their TLD. They return NS delegation records.
- Authoritative name servers — hold the actual records for the domain. They return the definitive answer.
The resolver caches the response for the record's TTL, then delivers it to your browser. The full chain typically completes in under 100 milliseconds. This tool queries the DNS server you select using DNS over HTTPS (DoH) — the same lookup, but sent over an encrypted HTTPS connection directly from your browser.
DNS Record Types Explained
Each record type carries a specific category of information. Understanding what a record does — not just its name — is what allows you to diagnose problems, configure services, and interpret lookup results.
| Type | Full Name | What it does |
|---|---|---|
| A | Address | Maps a domain name to an IPv4 address. Multiple A records at the same name distribute connections across several servers in a round-robin pattern — the simplest form of DNS-based load balancing, requiring no server health awareness. |
| AAAA | Quad-A | Maps a domain to an IPv6 address. The name reflects that IPv6 is four times longer than IPv4 (128 vs 32 bits). Browsers supporting both versions follow RFC 8305 (Happy Eyeballs): they race IPv6 and IPv4 connection attempts simultaneously, completing on whichever succeeds first. |
| CNAME | Canonical Name | Points one domain name at another instead of an IP. The resolver follows the chain until it reaches a non-CNAME record. Useful for aliasing subdomains. A CNAME cannot exist at the zone apex because DNS rules forbid sharing that label with the mandatory SOA and NS records. |
| MX | Mail Exchange | Specifies which server handles incoming email for the domain. Each MX carries a priority number — lower values are tried first. Multiple records with different priorities give redundancy; equal-priority records share traffic proportionally. The right-hand value must be a domain name, not an IP address. |
| TXT | Text | Holds arbitrary text data. Originally intended for human-readable notes, TXT records are now the primary vessel for SPF, DKIM, DMARC, domain ownership verification tokens (Google Search Console, Microsoft 365), and ACME DNS challenges used for TLS certificate issuance. |
| NS | Name Server | Lists the authoritative name servers for the zone. These are the servers with the definitive answers for all records under the domain. NS records here must match the delegation NS records at the parent zone (registrar) — a mismatch causes resolution failures. |
| SOA | Start of Authority | Every zone has exactly one SOA. It names the primary name server, encodes the admin email (first dot replaces @), and carries five timing parameters governing zone synchronisation between primary and secondary servers: Serial, Refresh, Retry, Expire, and Minimum TTL (for negative responses). |
| PTR | Pointer | Maps an IP address back to a hostname — the reverse of an A record. IPv4 PTR records live under .in-addr.arpa; IPv6 under .ip6.arpa. To query 93.184.216.34, enter 34.216.184.93.in-addr.arpa (or enter the IP and this tool converts it automatically). Critical for email deliverability: spam filters often reject mail from IPs whose PTR doesn't match the sending hostname. |
| SRV | Service | Advertises a specific network service at a given host and port. Applications query _service._protocol.domain (e.g. _sip._tcp.example.com). Format: priority weight port target. Allows service relocation without reconfiguring every client — the client simply re-queries DNS. |
| CAA | Certification Authority Authorisation | Restricts which certificate authorities may issue TLS certificates for the domain. A CA must refuse to issue if it isn't named in a CAA record. Tag issue governs standard certificates; issuewild governs wildcards; iodef provides a violation-reporting endpoint. |
| DS | Delegation Signer | Part of the DNSSEC chain of trust. A DS record in the parent zone holds a hash of the child zone's DNSKEY record. Resolvers verify the child zone's signatures are trustworthy by confirming the DNSKEY hash matches the parent's DS. The AD flag in a response indicates DNSSEC validation succeeded. |
Understanding TTL
Every DNS record includes a TTL (Time to Live) value in seconds. This is not how long the record exists — it is a caching instruction telling resolvers how long they may serve a cached copy before they must query the authoritative server again.
A record with TTL 300 can be served from cache for 5 minutes. After that, the next query for it goes back to the authoritative server. This mechanism is what lets DNS operate at global scale without every query hitting the authoritative server directly.
Practical implications:
- Short TTLs (60–300s) — changes propagate quickly. Useful before planned migrations or if you expect to change the record soon. Increases authoritative server query load.
- Long TTLs (3600–86400s) — resolvers cache the record for hours or a day. Reduces query load and improves response speed, but changes take longer to reach clients globally.
- Pre-change strategy — lower the TTL of the record you plan to change well before the change. Once the old high TTL has expired everywhere, make the change and the new short TTL means propagation is fast.
- Negative caching (NXDOMAIN TTL) — the SOA Minimum field governs how long resolvers cache negative responses. A freshly registered domain may still return NXDOMAIN during this window.
Email Authentication: SPF, DKIM, and DMARC
These three standards work as layers. SPF and DKIM each perform independent authentication checks; DMARC coordinates them and specifies enforcement. All three are published as TXT records in DNS.
SPF — Sender Policy Framework (RFC 7208)
SPF addresses the question: is this IP address allowed to send email claiming to be from this domain? The domain owner publishes a TXT record listing authorised mail server IPs. When a receiving server gets an email, it checks the envelope sender domain's SPF record against the connecting IP. If the IP isn't listed, SPF fails.
A typical SPF record looks like: v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all
include:— inherit the SPF authorisations of another domain (useful for third-party senders like Google Workspace or SendGrid)ip4:/ip6:— explicitly authorise an IP address or CIDR rangea/mx— authorise the IPs in the domain's own A or MX records-all— hard fail: reject mail from any IP not matched above~all— soft fail: accept but mark suspicious mail from unmatched IPs?all— neutral: no policy; treat unmatched senders neither favourably nor unfavourably
SPF has one significant limitation: it checks the envelope sender, not the visible From header. Email can pass SPF while still appearing to come from a different address in the inbox. DMARC closes this gap.
DKIM — DomainKeys Identified Mail (RFC 6376)
DKIM adds a cryptographic signature to the email. The sending mail server signs selected headers and a hash of the message body with a private key. The public key counterpart is published in DNS as a TXT record at selector._domainkey.domain — where selector is a short identifier chosen by the sender to allow multiple keys in rotation.
The receiving server retrieves the public key from DNS and verifies the signature. A valid DKIM signature proves two things: the email was sent by someone who holds the private key, and the signed headers and body have not been altered in transit. DKIM survives email forwarding — unlike SPF, which breaks when a server not in the SPF list forwards the message.
A DKIM TXT record contains: v=DKIM1; k=rsa; p=MIGfMA0GCS... where p is the base64-encoded public key.
DMARC — Domain-based Message Authentication, Reporting and Conformance (RFC 7489)
DMARC tells receiving mail servers what to do when SPF and DKIM both fail, and it requires alignment — the domain in the visible From header must match the domain that passed SPF or DKIM. This closes the spoofing gap that SPF alone leaves open.
Published at _dmarc.domain, a DMARC record like v=DMARC1; p=reject; rua=mailto:reports@example.com; adkim=s; aspf=s means:
p=reject— discard messages that fail both SPF and DKIM alignment checksp=quarantine— move failing messages to the spam folderp=none— take no action; monitor only (used during initial deployment)rua=— send daily aggregate reports (which IPs are sending email as your domain) to this addressadkim=s/aspf=s— strict alignment: the From domain must exactly match the DKIM or SPF domainpct=— apply the policy to only this percentage of messages (useful for ramping up enforcement)
When you query TXT records for a domain, this tool detects SPF, DKIM, and DMARC records automatically and shows a breakdown of every tag so you can interpret what the policy is actually doing.
Metadata on This Page — What Each Tag Does
Every page on this site carries a set of machine-readable signals in the <head> element. These tags are invisible to readers but are consumed by search engine crawlers, social platform previewers, and browser engines. The same metadata is present on the IP Converter page and every other tool on this site.