Instantly check every DNS record type for any domain: A, AAAA, MX, NS, TXT, CNAME, SOA, CAA, plus email configuration (SPF, DMARC, MX) and reverse DNS lookup. Native DNS resolution — no third-party service. Perfect for verifying a new DNS setup or debugging a migration.
DNS is the plumbing that connects domain names to servers, email, and every other online service. When a DNS record is wrong, your website does not load, email bounces, SSL breaks, or worse — an attacker spoofs your email domain because you forgot to set up SPF and DMARC. This tool reads every common DNS record type for any domain in about 200 milliseconds, then checks your email-authentication stack (SPF, DMARC, MX) so you know at a glance whether your domain is healthy.
A records map your domain to an IPv4 address. AAAA records do the same for IPv6. You need at least one A record; AAAA is nice-to-have for future-proofing. If both show "none", your domain resolves nowhere and your site is down.
MX records say which mail server handles email for your domain. Each MX has a priority — lower numbers are preferred. A domain with no MX records cannot receive email. If you use Google Workspace, you should see 5 MX records pointing to Google. Microsoft 365, one pointing to *.mail.protection.outlook.com.
NS records show which DNS servers are authoritative for your domain. These come from your DNS provider (Cloudflare, Route 53, GoDaddy, etc.). You should see 2–4 name servers, all from the same provider. If you see name servers from two different providers, you probably have a broken migration.
TXT records store arbitrary text. The most common uses: SPF (sender-policy framework for email auth), domain verification for Google/Microsoft/Zoom/etc., and DKIM keys for email signing. The tool highlights SPF records specifically.
The summary section below the record list shows whether your domain has MX, SPF, and DMARC configured. If any of these three are missing, your email is at risk of being spoofed or marked as spam by recipients. DMARC is the most commonly missed — it is stored as a TXT record on _dmarc.yourdomain.com, not on the bare domain.
CAA records restrict which certificate authorities can issue SSL certs for your domain (extra protection against cert mis-issuance). SOA contains zone administrative info — the primary name server, admin email, and serial number. Rarely need to look at these unless you are debugging a DNS issue.
Correct. Without MX records, no mail server can be delivered email at your domain. If you thought you had email set up (Google Workspace, Microsoft 365, etc.), the MX records were never actually added to your DNS zone — log into your DNS provider's dashboard and add them. The provider you bought email from will have published the exact MX records to use.
Bad. Without SPF, anyone can spoof email "from" your domain and recipients have no way to detect it. Gmail, Outlook, and Yahoo will also start dropping your legitimate mail into spam because your domain looks unauthenticated. The fix is a single TXT record: "v=spf1 include:_spf.google.com ~all" for Google Workspace, or the equivalent for your mail provider.
It is a starting point but not the destination. "p=none" monitors without enforcing — you can see DMARC reports but spoofed email is still delivered. Once you have confirmed all your legitimate senders are aligned (Google, Mailchimp, Stripe receipts, etc.), tighten to "p=quarantine" (spam folder) and eventually "p=reject" (blocked).
Google Workspace intentionally publishes 5 MX records with different priorities for redundancy. This is normal and healthy — if one Google mail server is offline, the next one takes over. Do not delete any of them.
Yes, that is the correct setup. Your domain is registered at GoDaddy but its DNS is delegated to Cloudflare via the NS records. GoDaddy just handles renewal; Cloudflare handles everything DNS-related. This is a very common (and recommended) configuration.
A CNAME is a DNS-level alias — when someone asks for "www.example.com", DNS says "that is actually example.com, go ask again". The browser never sees the CNAME. A redirect is HTTP-level — the server returns a 301 or 302 with a new URL, and the browser URL bar changes. Use CNAMEs for subdomains that should resolve to the same service; use redirects to send visitors to a different URL.
Reverse DNS (PTR records) is controlled by whoever owns the IP address — usually your hosting provider, not you. A mismatch is normal and only matters for email: some strict mail servers reject mail from IPs whose PTR does not match the sending domain. If you run your own mail server on a VPS, fix this via your VPS provider's control panel.
New DNS records show up within seconds at your authoritative name server, but caching delays how fast the change reaches end users. Typical propagation is 5 minutes to 48 hours depending on the TTL you set. Before making a critical change, lower the TTL on the record to 300 seconds a day in advance — then the change rolls out in 5 minutes instead of 24 hours.
Hand-picked internal pages and external references from sources Google itself considers authoritative on this topic.