DNS Check
Purpose
Run DNS lookups (A, AAAA, MX, NS, TXT) for a domain to detect DNS misconfigurations, nameserver problems, mail routing issues, or missing records. Useful for troubleshooting email delivery, site reachability, CDN misrouting, and domain verification.
🧭 What this feature shows
Record sets — per-record-type results (A, AAAA, MX, NS, TXT) with full record details.
Counts — number of records returned per type.
Raw output — structured raw data and a human-friendly table of each record’s fields.
Summary & notes — short summary describing notable findings (e.g., no MX records, mismatched NS).
Errors — DNS timeouts, NXDOMAIN, SERVFAIL, or other lookup errors captured with messages.
Checked At — timestamp of when the lookup was performed.
PDF export — download a shareable report of the check.
👥 Who should use this
Shop owners and admins validating domain setup and mail routing (MX).
DevOps and ops teams diagnosing DNS propagation or authoritative nameserver problems.
Support staff investigating domain-related incidents (downtime, email issues, SSL issuance failures).
Developers and integrators verifying TXT records for verification, SPF, DKIM, or other ownership checks.
⚙️ How it works (high level)
Input domain — operator supplies the domain to query (e.g.,
example.com).Server-side lookup — the backend performs DNS queries for standard types (A, AAAA, MX, NS, TXT) using system resolvers or configured DNS servers.
Collect results — each record type’s answers are normalized into structured records with fields (address, priority, host, value, TTL, etc.).
Detect errors/absences — capture NXDOMAIN, no-response, or empty results and include them in the summary.
Store & present — results are saved as a DNS check object and displayed in a detail view with per-type tables and raw info; PDF export is available.
🪜 How to use — step-by-step
Open Dashboard → DNS Checks → Run DNS Check.
Enter the domain you want to inspect (e.g.,
yourshop.com).Click Run DNS Check.
After completion, open the Details view to review per-type record tables (A, AAAA, MX, NS, TXT).
Use Download PDF to export the findings for stakeholders or external support.
Repeat the check if you change nameservers, DNS records, or after propagation windows.
📊 How to interpret results (actionable guidance)
A / AAAA records — should point to the correct public IPv4/IPv6 address of your server or load balancer. Missing A/AAAA for a public website means it can’t be reached by that protocol.
MX records — required for email delivery. Ensure MX records point to valid mail servers and that their priorities are correct. If absent, mail will not be delivered to that domain.
NS records — show authoritative nameservers. Verify they match the registrar configuration and respond authoritatively. Multiple NS entries should be consistent across registrars and DNS zones.
TXT records — commonly used for SPF, DKIM, DMARC, and domain verification. Ensure SPF strings are valid and not contradictory; DKIM selector records should exist for mail signing; TXT ownership tokens must match provider expectations.
TTL — long TTLs delay propagation; low TTLs increase change responsiveness but increase lookup frequency.
No records found — can be intentional (e.g., no AAAA) or indicate misconfiguration (e.g., no MX when mail is expected).
Errors (NXDOMAIN/SERVFAIL) — NXDOMAIN means the domain does not exist or zone not published; SERVFAIL suggests authoritative server errors or zone misconfiguration.
✅ Recommended actions (prioritised)
Fix missing MX — add MX records if you expect mail for the domain. Also add SPF (
v=spf1 ...) and DKIM records for deliverability.Align NS at registrar and zone — ensure nameservers configured at the registrar match the authoritative NS records and that each NS responds.
Correct A/AAAA — update A/AAAA to the correct server IPs or CDN endpoints; verify propagation with repeated checks.
Validate TXT records — confirm SPF length and syntax, DKIM selector presence, and DMARC policy format. Use TXT parser tools when necessary.
Investigate SERVFAIL / timeouts — check authoritative DNS server health, glue records, and firewall rules blocking DNS queries.
Lower risk during changes — reduce TTL before changes to speed propagation, then raise it back after stabilization.
📤 Exporting & reporting
Download PDF — available from the details page to create a shareable report with record tables and raw info.
Copy raw JSON — if implemented, copy the structured results (records, timestamps, errors) for support tickets.
Bulk export — for many domains, provide CSV/JSON exports summarizing key fields (domain, A count, MX count, NS list, error).
🗓️ Recommended cadence
After registrar or DNS changes — immediately, then again after TTL propagation (typically up to 48 hours).
After moving hosting or email providers — verify records point to the new endpoints.
Periodic audits — quarterly or during security reviews to ensure SPF/DKIM/DMARC remain valid.
When troubleshooting email delivery or CDN issues — run on-demand checks.
🔒 Privacy & safety notes
DNS queries are for publicly available records only. No private keys or secret contents should be exposed in DNS checks.
TXT records may contain tokens/keys for verification; treat these as sensitive and avoid publishing them in public reports without redaction.
If you implement server-side logging of DNS checks, ensure retention policies and access controls are in place.
🧩 Troubleshooting & FAQs
Q: I see different answers from different checks or locations. A: DNS is distributed. Authoritative nameservers may be inconsistent, or caching/propagation may cause differences. Check authoritative NS directly and compare responses.
Q: MX exists but mail still fails. A: Verify MX targets resolve (A/AAAA), ports are open (25/587), and SPF/DKIM/DMARC are configured correctly. Check mail server logs for delivery errors.
Q: NS records show provider but registrar lists others. A: Update the registrar to match your authoritative nameservers or move the zone to the registrar’s DNS service; mismatches cause resolution failures.
Q: TXT SPF too long or returns multiple records.
A: SPF should be a single TXT record and under size limits; split mechanisms with include: or use subdomains if necessary. Multiple SPF TXT records can cause mail rejection.
Q: SERVFAIL or timeouts for lookups. A: Check authoritative DNS server status, firewall rules blocking DNS (port 53), DNSSEC misconfigurations, and glue records at the registrar.
✅ Quick checklist
Last updated