DNS Record Builder
Generate DNS record syntax for A, AAAA, CNAME, MX, TXT, and other record types.
A Record Fields
Zone file format
Record value only
Use this in DNS provider dashboards that have separate fields for name, type, and value.
Cloudflare dashboard format
Tips
- Use @ for the apex/root domain
- Fully qualified names should end with a dot (.)
- Common TTLs: 300 (5 min), 3600 (1 hr), 86400 (1 day)
- MX, NS, CNAME targets must be FQDNs (end with a dot)
DNS Record Builder — generate zone file syntax for any record type
DNS records control how your domain resolves across the internet. A records map a hostname to an IPv4 address; AAAA for IPv6. CNAMEcreates an alias pointing to another hostname. MX specifies mail servers with priority. TXT records carry arbitrary text — used for SPF, DKIM, and domain verification. CAA records restrict which certificate authorities may issue SSL certificates for your domain. SRV records publish service endpoints (host + port + priority) for protocols like SIP and XMPP. This builder generates both standard zone file syntax and the simplified value-only format used by Cloudflare, Route 53, and other managed DNS providers.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Getting the exact syntax for a record type you set up rarely, such as SRV or CAA.
- Producing a TXT record for domain verification with the quoting correct.
- Checking the field order for an MX record before pasting it into a provider's form.
- Building a record to compare against what a provider's UI generated.
- Preparing a zone-file snippet for a change request.
Frequently Asked Questions
- What are the record types for?
- A and AAAA map a name to an IPv4 or IPv6 address, CNAME aliases one name to another, MX routes mail, TXT carries arbitrary text including SPF and DKIM, and NS delegates a zone. Those six cover almost every practical change.
- Why can a CNAME not sit at the apex?
- Because a CNAME must be the only record for that name, and the apex necessarily has SOA and NS records. That is why providers invented ALIAS and ANAME — non-standard records that resolve like a CNAME while returning an address.
- What does TTL control?
- How long resolvers may cache the answer. A low TTL makes changes propagate quickly and increases query load; a high one is efficient and slow to change. Lowering the TTL a day BEFORE a migration is what makes the cutover fast.
- Why does my change not take effect?
- Almost always caching at some layer — a resolver, the OS, or the browser's own DNS cache — holding the previous answer until its TTL expires. Checking with `dig` against the authoritative nameserver distinguishes a propagation delay from a mistake.
- How do MX priorities work?
- Lower is preferred. A sender tries the lowest-numbered host first and falls back to higher ones, and equal numbers are load-balanced. The common mistake is assuming higher means more important, which inverts a mail setup entirely.
Common errors and gotchas
- Putting a CNAME at the zone apex, which the specification forbids even though some providers paper over it.
- Omitting the trailing dot on a fully qualified target, so the zone name gets appended to it.
- Splitting a long TXT value incorrectly, which changes the string a verifier reads.
- Setting a very long TTL just before a planned change, which delays the cutover for everyone cached.
- Expecting a record to take effect immediately, when propagation is bounded by the previous TTL.