DNS Zone File Checker

It parses a BIND format zone file and reports what a DNS migration would break: missing SPF, DKIM or DMARC records, hostnames that must not be proxied because mail is delivered to them, verification records that need carrying across untouched, TTLs still too long to allow a quick correction, and structural problems such as a CNAME sharing a name with another record type.

A validator answers whether the syntax parses, which named-checkzone and several online tools already do well. That is a different question from whether the migration will succeed. A zone file can be perfectly valid and still take your email offline once migrated, because the damaging failures are missing records rather than malformed ones.

No. Parsing and analysis run entirely in your browser, and the page works offline. This matters more than usual here: a zone file is a map of your infrastructure, listing internal hostnames, mail servers and the third-party services you depend on.

The BIND master file format described in RFC 1035, which is what most providers produce when you export a zone. It handles $ORIGIN and $TTL directives, @ for the apex, relative and absolute names, optional class fields, parenthesised multi-line records such as SOA, semicolon comments, and TTLs written either as seconds or as durations like 1h and 300s.

Before a migration you want short TTLs, so that a record needing correction mid-cutover propagates in minutes rather than hours. Lower them to around 300 seconds at your current provider at least one full old-TTL before the change, then restore normal values once the migration has settled.

Cloudflare’s proxy handles HTTP traffic. Mail does not travel over it, so proxying the hostname your MX records point at stops inbound delivery. The failure is confusing because the MX record itself still looks correct in the dashboard; only the A record behind it has changed behaviour.