DNS Record Syntax Checker - Online Validate BEFORE Publishing

A DNS Record Syntax Checker is an online tool that validates the format and structure of your DNS records before you publish them to your DNS provider or zone file. It helps catch syntax errors—like invalid IP addresses, malformed domain names, or incorrect field counts—saving you from propagation delays, downtime, and troubleshooting headaches. Think of it as a "spell checker" for your DNS configuration.

Publishing invalid DNS records can lead to service outages, email delivery failures, SSL certificate issuance problems, and website downtime. DNS propagation can take anywhere from a few minutes to 48 hours, so fixing an error after publishing means waiting for propagation twice. Validating beforehand ensures your changes are correct the first time, reducing risk and saving valuable time.

The trailing dot signifies a Fully Qualified Domain Name (FQDN)—an absolute domain name that includes the root zone. Without the trailing dot, many DNS systems treat the name as relative and may append the zone's origin domain. For example, www.example.com. (with dot) is absolute, while www (without dot) would be expanded to www.example.com. if the zone origin is example.com.. For CNAME, MX, NS, and PTR record values, using FQDN with a trailing dot is considered best practice to avoid ambiguity.

An MX record requires two components: a priority (integer from 0 to 65535) and a mail server domain. The format is: priority domain. For example, 10 mail.example.com. is valid. Common mistakes include: forgetting the priority number, using an IP address instead of a domain name, or omitting the trailing dot on the mail server's FQDN. Our tool automatically checks all these aspects and provides specific feedback.

The most common DNS record types include: A (maps hostname to IPv4 address), AAAA (maps hostname to IPv6 address), CNAME (creates an alias to another domain), MX (defines mail servers for a domain), TXT (stores arbitrary text, often used for SPF/DKIM/DMARC), NS (delegates to name servers), SRV (defines service locations like SIP or LDAP), SOA (Start of Authority—zone metadata), CAA (restricts which CAs can issue certificates), and PTR (reverse DNS lookup).

In BIND zone files, TXT record values should be wrapped in double quotes if they contain spaces or special characters. For simple single-word values, quotes are technically optional but highly recommended for consistency. Many DNS providers handle quoting automatically. For SPF records like "v=spf1 include:_spf.google.com ~all", quotes are required. For DMARC records like "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com", quotes are also necessary. Our validator checks whether your TXT value is properly quoted.

No. A CNAME (Canonical Name) record must always point to a domain name, never an IP address. If you need to point a hostname to an IP address, use an A record (for IPv4) or an AAAA record (for IPv6). Pointing a CNAME to an IP address violates the DNS specification (RFC 1034/1035) and will cause resolution failures. Our tool detects and flags this common mistake.

BIND zone format is the industry-standard text representation of DNS zone files used by BIND (Berkeley Internet Name Domain), the most widely deployed DNS server software. A typical line follows the pattern: [name] [TTL] [class] [type] [data]. For example: www 3600 IN A 192.168.1.1. Being able to validate BIND-format records is essential because many DNS providers accept or export zone files in this format, and it's the lingua franca of DNS administration.

The SOA (Start of Authority) record contains 7 fields: MNAME (primary name server), RNAME (admin email with @ replaced by a dot), serial number, refresh time, retry time, expire time, and minimum TTL. Our validator checks that all 7 fields are present, that the MNAME and RNAME are valid domain formats, that the serial is a positive integer, and that the timing values (refresh, retry, expire, minimum) are reasonable positive numbers. A common best practice is to use YYYYMMDDNN format for the serial number to ensure uniqueness and readability.

Publishing a syntactically invalid DNS record can result in: zone file rejection by your DNS provider, partial zone loading (where the entire zone fails to load), silent failures where the broken record is simply ignored, or unpredictable behavior from resolvers. In the worst case, a single malformed record can prevent your entire domain's DNS from loading correctly. Always validate before publishing to avoid these risks.

Yes. AAAA records store 128-bit IPv6 addresses. Our validator supports all valid IPv6 formats, including: full expanded form (2001:0db8:0000:0000:0000:ff00:0042:8329), compressed form (2001:db8::ff00:42:8329), loopback (::1), and unspecified address (::). IPv6 addresses in AAAA records must follow the colon-hexadecimal notation defined in RFC 4291. Mixed IPv4/IPv6 notation (like ::ffff:192.168.1.1) is also supported.

Per DNS specifications (RFC 1035), a single domain name label (the part between dots) can be at most 63 characters long, and the entire FQDN (including all labels and dots) cannot exceed 253 characters (or 255 octets in wire format). Our validator checks these limits and warns you if your domain name exceeds them. Labels must also consist only of letters (a-z), digits (0-9), and hyphens, and cannot start or end with a hyphen.