DNS Record Builder
Build correctly formatted DNS zone file records from simple form inputs.
Reviewed by the ToolNestr Editorial Team — July 2026
Build a DNS record
Select a record type, fill in the fields, and click Generate record.
DNS zone file format
A DNS zone file is a plain-text file that contains the mapping between domain names and IP addresses and other resources for a particular DNS zone. Every line in the file defines one resource record (RR) using a standard five-field format: name, TTL, class, type, and value. The file is read by a DNS server software such as BIND, PowerDNS, or Knot DNS, which serves the records to DNS resolvers across the internet.
The name field specifies the domain or subdomain that the record applies to. A fully qualified domain name (FQDN) must end with a trailing dot (e.g., example.com.). Names without a trailing dot are considered relative to the zone origin (the domain defined in the $ORIGIN directive). The special name @ is shorthand for the zone origin itself.
The TTL (Time to Live) field tells recursive resolvers how many seconds to cache the record before querying the authoritative server again. The class is almost always IN (Internet). The type indicates what kind of record it is (A, AAAA, CNAME, MX, TXT, etc.), and the value contains the record data whose format depends on the type. Understanding this structure is essential for anyone managing DNS for a domain, whether through a control panel, a DNS provider's API, or directly editing zone files on a nameserver.
Record types explained
A record (address)
Maps a domain name to an IPv4 address. This is the most fundamental DNS record type — every website needs at least one A record pointing to its web server's IP address. Multiple A records can be used for round-robin load balancing.
AAAA record (quad-A)
Maps a domain name to an IPv6 address. Functionally identical to an A record but for the 128-bit IPv6 address space. As IPv6 adoption grows, every domain should have both A and AAAA records for dual-stack connectivity.
CNAME record (canonical name)
Aliases one domain name to another. For example, www.example.com can be a CNAME pointing to example.com. When the target IP changes, only the A record needs updating. CNAMEs cannot coexist with other record types at the same name.
MX record (mail exchange)
Specifies the mail server that handles email for the domain. Each MX record has a priority number — lower values are tried first. If the primary server is unavailable, the mail is routed to the backup server with the next highest priority. MX records must point to an A or AAAA record, not a CNAME.
TXT record (text)
Stores arbitrary text data, typically used for machine-readable policies. Common uses include SPF records (email sender authorisation), DKIM keys (email signing verification), DMARC policies (email authentication reporting), and domain ownership verification strings for Google Workspace, AWS, and other services.
SPF (Sender Policy Framework)
Despite having its own DNS record type number (type 99, now deprecated), SPF data is stored in a TXT record. The value starts with v=spf1 followed by mechanisms like ip4:, include:, and a:, ending with a qualifier like ~all (soft fail) or -all (hard fail).
DKIM (DomainKeys Identified Mail)
Also stored as a TXT record, DKIM provides cryptographic email signing. The record name follows the format selector._domainkey.example.com.. The value contains v=DKIM1; p= followed by the base64-encoded public key. Receiving mail servers use this key to verify that the email was genuinely signed by the sending domain.
Worked example
example.com. 3600 IN A 192.0.2.1
Visitors who type example.com into their browser are directed to the server at 192.0.2.1. The trailing dot tells the DNS parser that this is a fully qualified domain name.
Use cases for this builder
Managing DNS for a domain
Whether you use a control panel like cPanel, a cloud provider like AWS Route 53 or Cloudflare, or manage BIND zone files directly, correctly formatted DNS records are essential. A single misplaced character can break email delivery, take a website offline, or create a redirect loop. This builder helps you construct each record with the correct syntax before deploying it.
Setting up email (SPF, DKIM, MX)
Configuring email for a domain requires three types of DNS records: MX records to route incoming mail to your mail server, SPF records to authorise outgoing mail servers, and DKIM records to cryptographically sign messages. Misconfiguring any of these leads to email being rejected, marked as spam, or failing authentication checks (DMARC).
CDN and reverse proxy setup
CDN providers like Cloudflare, Akamai, and Fastly require specific DNS configurations. You typically point your domain's A or AAAA records to the CDN's anycast IPs, or set up a CNAME to the CDN's proxy domain. Many CDNs also require TXT records for domain ownership verification and CAA records (Certificate Authority Authorization) for SSL/TLS certificate issuance.
DNS migration and auditing
When migrating a domain from one DNS provider to another, you need to export all existing records and recreate them in the new provider's zone file format. Using a builder ensures each record is syntactically correct and matches the original. This is especially important for complex records like SPF and DKIM where incorrect syntax can break email authentication.
Tips for DNS record management
Always use the trailing dot for FQDN
In a zone file, example.com (without trailing dot) is interpreted as relative to the current zone origin. If the origin is example.com., a bare example.com becomes example.com.example.com. — a completely different domain. Always append a trailing dot to fully qualified domain names in the name, target, and MX target fields.
Choose TTL values strategically
Short TTLs (300 seconds / 5 minutes) ensure changes propagate quickly, which is useful before a planned DNS migration or IP change. However, short TTLs increase the query load on your authoritative DNS servers. Long TTLs (86400 seconds / 24 hours) improve performance through aggressive caching but delay the visibility of changes. A common strategy is to lower the TTL to 300 seconds a few days before a planned change, then increase it again after the change is confirmed working.
Understand DNS propagation
DNS propagation is the time it takes for a record change to be picked up by recursive resolvers worldwide. Propagation depends on the TTL of the old record, not the new one — resolvers will continue serving the cached value until the old TTL expires. Even after TTL expiry, some resolvers ignore the TTL and cache for longer periods. Most changes propagate within a few hours, but some resolvers can hold stale data for up to 48 hours. Use a DNS propagation checker to verify the change is visible globally.
Avoid CNAME at the zone apex
Per the DNS specification (RFC 1912), a CNAME record cannot coexist with any other record type at the same node. Since the zone apex (bare domain like example.com) must have SOA and NS records, you cannot place a CNAME at the apex. If you need to point the apex to a service that provides only a CNAME target (like some CDNs), use a CNAME flattening service (Cloudflare) or an ALIAS / ANAME record if your provider supports it.
What is a DNS zone file?
A DNS zone file, also called a master file or a BIND zone file following the RFC 1035 standard, is a text file that describes a DNS zone. It contains all the resource records for a domain, starting with SOA (Start of Authority) and NS (Name Server) records that establish the zone's authority delegation, followed by the individual records for subdomains, mail servers, and other services. The zone file is loaded by an authoritative name server and served to recursive resolvers that query for records within the zone.
The $ORIGIN directive at the top of the file sets the default domain that relative names are appended to. For example, with $ORIGIN example.com., a record named www becomes www.example.com.. The $TTL directive sets the default TTL for all records that follow, though individual records can override it. Modern zone files use $INCLUDE directives to split large zones into multiple files, and $GENERATE directives to create numbered records in a single line.
While most domain owners today manage DNS through a web-based control panel or a DNS provider's API rather than editing zone files directly, understanding the zone file format is valuable for troubleshooting, debugging differences between providers, and working with authoritative DNS servers directly. Tools like this builder bridge the gap between the raw zone file syntax and the need to construct correct records quickly without memorising the syntax rules.
References and further reading
- RFC 1035 — Domain Names — Implementation and Specification — the foundational DNS specification defining zone file format and all standard record types
- RFC 7208 — Sender Policy Framework (SPF) — the current SPF specification
- RFC 6376 — DomainKeys Identified Mail (DKIM) — DKIM signature and verification specification
- DNS Flag Day — information about EDNS compliance and DNS resolver requirements
- ISC BIND — the most widely used DNS server software, reference implementation for zone files
Related tools
Frequently asked questions
What is a DNS zone file?
A text file containing DNS records for a domain, with each line defining one resource record in the format: name TTL class type value (e.g. example.com. 3600 IN A 192.0.2.1).
What is the format of a DNS record?
Standard format: name TTL class type value. The name is the domain or subdomain (FQDN with trailing dot), TTL is the caching duration in seconds, class is almost always IN (Internet), type is the record type (A, AAAA, CNAME, etc.), and the value is the record data.
What is SPF?
Sender Policy Framework — a TXT record listing which servers are authorized to send email for your domain. Helps prevent email spoofing and improves deliverability.
What is DKIM?
DomainKeys Identified Mail — a TXT record containing a public key for verifying email signatures. Receiving servers use it to confirm that an email was genuinely sent by the domain and was not tampered with in transit.
What does the trailing dot mean?
In DNS zone files, a trailing dot (e.g. example.com.) indicates a fully qualified domain name (FQDN). Names without a trailing dot are relative to the zone origin. This is a critical syntax detail — omitting the dot can cause incorrect DNS lookups.
What is a good TTL value?
3600 seconds (1 hour) is a good default. Use 300 (5 minutes) before planned changes so updates propagate quickly. Use 86400 (24 hours) or longer for stable records to improve caching and reduce resolver load.