How to Check DNS Records

Enter the bare domain in the WebJi® DNS lookup, pick the record type and read the value and TTL it returns. No account is needed, and the query runs against live DNS, so you see what the internet sees rather than what a control panel claims.

1. Type the domain only, for example example.in, without https:// or a path.
2. Pick the type that matches the symptom from the table above.
3. Read the value and the TTL; the TTL is how many seconds resolvers may cache that answer.
4. Compare it with the record you saved at the DNS host named in the NS result.

For mail problems the MX record lookup shows the mail hosts in priority order, and the DNS propagation checker compares answers from resolvers in several regions after a change.

Run dig example.in A in Terminal, change the type as needed, and add @nameserver to ask the authoritative server directly instead of a cached resolver. dig ships with macOS; on Ubuntu or Debian install it with sudo apt install dnsutils.

dig example.in A +short                     # website IPv4
dig example.in AAAA +short                  # website IPv6
dig example.in MX +short                    # mail hosts and priority
dig example.in NS +short                    # nameservers
dig example.in TXT +short                   # SPF and verification strings
dig _dmarc.example.in TXT +short            # DMARC policy
dig default._domainkey.example.in TXT +short   # DKIM; replace "default" with your selector
dig example.in A @ns1.yourdnshost.com       # authoritative answer, bypasses cache
dig example.in A @8.8.8.8                   # what Google Public DNS currently has
dig example.in +trace                       # full path from the root servers

Without +short, look at the status line: NOERROR with an empty answer means the name exists but has no record of that type; NXDOMAIN means the name itself does not exist. The number before IN in each answer line is the remaining TTL in seconds.

A correct result matches the value your host or mail provider gave you exactly, and for mail the lowest MX number must point to your current provider. Small details in each type cause most misreadings.

A and AAAA

Should equal the server IP in your hosting welcome email. An old AAAA left after a move sends IPv6 visitors to the previous server.

MX

Lower preference is tried first. Each MX host must itself resolve to an address; an MX pointing to an IP or to a CNAME is a misconfiguration. See what an MX record is.

TXT

Only one v=spf1 record is allowed per name; two SPF TXT records make SPF fail. DKIM lives on selector._domainkey and DMARC on _dmarc.

CNAME

Returns a hostname, never an IP. A CNAME cannot sit on the bare domain alongside MX and NS, so the apex uses A or AAAA (or a provider’s flattening).

Save the current A, AAAA, MX, NS, TXT and CNAME values before any hosting or email move, because a live lookup shows only today’s records and there is no built-in history. Third-party archives exist but miss records, so your own copy is the reliable rollback.

A quick way on macOS or Linux is for t in A AAAA MX NS TXT; do dig example.in $t +short; done > dns-before.txt, plus the same for www and any mail subdomains. If you host on WebJi®, support@webji.services can check a zone with you 24/7 in Hindi and English; records on shared hosting are edited in cPanel Zone Editor, as shown in adding a TXT record in cPanel.