DNS Records Lookup (A, AAAA, MX, TXT, NS, CNAME, SOA, CAA)

DNS is the directory service of the internet, mapping human-readable domain names to the IP addresses, mail servers, and policy records that systems actually use. This WhatIP lookup tool queries Cloudflare's public resolver via DNS-over-HTTPS, the same modern protocol your browser uses when DoH is enabled. You can ask for A records (IPv4), AAAA (IPv6), MX (mail servers), TXT (verification and policy strings including SPF and DKIM), NS (authoritative name servers), CNAME (aliases), SOA (zone authority), and CAA (which certificate authorities are allowed to issue TLS certificates for the domain). All queries are encrypted and travel directly from your browser to the resolver. A DNS lookup is the fastest way to see why an email is bouncing, to confirm that a new website has finished pointing at the right server, to verify a domain ownership record, or to check which certificate authorities a domain trusts. Because the resolver answers from cache, the data reflects what most of the internet currently sees, which may be slightly behind your authoritative records.

How to Use This Tool

1. Enter a domain name without the protocol, for example whatip.xyz rather than https://whatip.xyz. Subdomains like mail.whatip.xyz work too.
2. Choose the record type you need. Start with A or AAAA to see the IP a name resolves to, or MX if you are chasing an email problem.
3. Run the lookup. WhatIP sends an encrypted DNS-over-HTTPS query to Cloudflare's resolver and lists every matching record.
4. Read the values and their TTL, the number of seconds a resolver may cache each record before checking again.
5. For email diagnostics, pull the MX records to confirm where mail is delivered, then read the TXT records to inspect SPF, DKIM, and DMARC policy.
6. For a site that just moved hosts, compare the A record against the IP your new host gave you. A match means the change has propagated to this resolver.
7. Check NS records when a whole zone behaves oddly; they reveal which name servers are authoritative and whether a registrar change has taken effect.
8. Switch record types and look up again as needed. Each query is independent, and nothing you enter is stored.

A Real-World Example

Priya launched a new newsletter for her bakery and sent the first issue to two hundred subscribers, but a third of the messages bounced. The bounce notice mentioned an authentication failure, which she did not understand. She opens the WhatIP DNS lookup and starts with her domain, sweetcrumb.example.

First she checks the MX records and finds they correctly point at her email provider, so inbound mail is fine. The problem is outbound, so she switches to TXT records. There she sees an SPF entry, but it lists only her old website host and not the new email service she signed up for last week. That is the gap: receiving servers checked her SPF policy, saw that the sending service was not authorized, and rejected the mail. She also notices there is no DMARC record at all, which is why some providers were strict.

Priya updates the SPF record at her DNS provider to include her email service, then adds a basic DMARC policy. She returns to WhatIP, looks up the TXT records again, and confirms the new values appear, though she remembers the TTL means older resolvers may take an hour to catch up. To be thorough she also checks the DKIM record her email provider asked her to add, looking up the selector subdomain it lives under, and sees that the long public key is present and unbroken. The next morning she sends a test to a few accounts and watches them all arrive in the inbox, this time passing authentication cleanly. One lookup turned a vague bounce message into a precise, fixable cause, and a couple of follow-up checks gave her confidence the fix was complete rather than partial.

Tips & Best Practices

• Look up the bare domain and the www version separately; they can resolve differently and surprise you.
• Read the TTL before expecting a change to appear everywhere. A long TTL means older cached answers linger until it expires.
• For email trouble, check MX, then SPF and DMARC in the TXT records, in that order, and confirm the DKIM selector your provider gave you.
• If an A record points somewhere unexpected, a CDN may sit in front of your origin; confirm with a reverse DNS or WHOIS lookup.
• Keep TTLs low for a day before a planned migration so changes spread quickly, then raise them again afterward.
• Remember that a DoH resolver answers from its cache, so a change you just made may show here before or after it appears elsewhere; check the SOA serial if you need to confirm the authoritative zone version.