A DNS record generator removes the two things that make DNS editing stressful: remembering the exact syntax of records you touch twice a year, and getting the trailing dots, priorities, and quoting right the first time. Enter a domain, a server address, and a mail provider, and this page produces a complete zone file fragment covering address records, mail routing, SPF, DMARC, and CAA — the records that a working, deliverable, reasonably secured domain actually needs.
Arb Digital sets up DNS for client sites regularly, and the same three problems account for most of the tickets: a missing SPF record sending mail to spam, a DMARC record published straight at p=reject before anyone checked what it would block, and a CNAME on the apex domain that the provider silently refuses. This tool is built around avoiding those three specifically. Everything runs in your browser; no lookups are performed and no data is sent anywhere.
What This DNS Record Generator Does
It produces a set of records in standard zone file format — name, TTL, class, type, value — which is the notation used by BIND and understood by essentially every DNS control panel, either as a direct import or as an obvious mapping into the panel's own fields. The apex A record points your domain at a server, an optional AAAA record does the same over IPv6, and www is created as a CNAME back to the apex so both hostnames stay in sync when the address changes.
Mail is where most of the value is. Choosing Google Workspace or Microsoft 365 fills in that provider's current MX hosts and the matching SPF include automatically, so the mail routing and the authorisation record cannot drift apart. The DMARC record is built from the policy you select and the reporting address you supply. A CAA record is added to restrict which certificate authorities are allowed to issue certificates for the domain — a genuinely useful record that almost nobody publishes.
The four supporting figures report the number of MX records generated, the number of DNS lookups your SPF record declares, the TTL translated into plain English, and whether your DMARC policy is actually enforcing anything or merely watching.
How to Use It
- Enter the apex domain without
wwwand without a trailing dot. The generator adds trailing dots where the zone format requires them. - Enter your server's IPv4 address, and its IPv6 address too if you have one. Leaving IPv6 blank simply omits the AAAA record.
- Choose your mail provider. Google Workspace and Microsoft 365 are prefilled; pick Custom to supply your own mail host, or None to omit mail records entirely.
- Pick a DMARC policy and reporting address. Start at
noneunless you already know your legitimate senders are fully authenticated. - Click Generate Records, then copy the zone file and paste it into your DNS provider — or map each line into the panel's name, type, and value fields.
How Each Record Is Constructed
The A record maps the apex name @ to your IPv4 address, and AAAA does the same for IPv6. Both are simple mappings with no priority or weight. The www entry is generated as a CNAME to the apex rather than as a second A record, so a future server move requires one edit instead of two.
MX records carry a preference number, and lower numbers are tried first. Microsoft 365 uses a single host derived from your domain name with dots replaced by hyphens, ending in mail.protection.outlook.com. Google Workspace now uses a single smtp.google.com host at preference 1 rather than the five-host set it historically published. Every MX value ends in a trailing dot, which marks it as a fully qualified name — omit that dot in a zone file and the server appends your own domain, producing a host that does not exist.
SPF, DKIM, and DMARC are all published as TXT records. SPF declares which servers may send mail as your domain and ends with a qualifier: ~all means soft fail, -all means hard fail. DMARC lives at the fixed name _dmarc and tells receivers what to do when SPF and DKIM alignment fails, plus where to send reports. The full policy syntax is defined in RFC 7489.
The SPF Ten-Lookup Limit Nobody Warns You About
SPF has a hard ceiling that breaks records quietly. Evaluating a record may trigger at most ten DNS lookups, counting every include, a, mx, ptr, and exists mechanism, plus any redirect. Exceed it and the evaluation returns a permanent error, which most receivers treat as no SPF pass at all — so adding one more service to an already-crowded record can break authentication for every message you send.
The counter above reports the lookups declared directly in the generated record. The trap is that the count does not stop there: an include pulls in another domain's SPF record, and whatever lookup-triggering mechanisms that record contains count against your ten as well. A single include pointing at a large provider can consume four or five of your budget on its own. If you send through a website form, a CRM, a help desk, and a newsletter platform simultaneously, you are much closer to the limit than the number of includes suggests. The mechanism and its limits are specified in RFC 7208.
Two practical notes. First, ip4 and ip6 mechanisms cost zero lookups, so listing an address directly is always cheaper than including a domain. Second, the ptr mechanism is deprecated and should not appear in a modern record at all.
Why the Apex Domain Cannot Take a CNAME
This is the constraint that surprises people migrating to a hosting platform that only gives them a hostname. The apex — example.com with no subdomain — already carries SOA and NS records, and the DNS specification does not allow a CNAME to coexist with other record types at the same name. So example.com cannot be a CNAME, no matter how much your host would prefer it.
The workarounds are provider-specific rather than standard: ALIAS records, ANAME records, or CNAME flattening, all of which resolve the target internally and answer with an A record. They work, but they are features of a particular DNS provider, not part of DNS itself, and moving providers can mean rebuilding them. This generator produces a real A record at the apex and a CNAME only on www, which is portable everywhere.
Choosing a TTL, and the Migration Trick
TTL is how long a resolver may cache a record before asking again. A long TTL such as 86400 seconds reduces query volume and is fine for records that rarely change. A short TTL such as 300 seconds means changes propagate quickly, at the cost of more queries. The default here is 3600 seconds — one hour — which suits most records most of the time.
The trick worth knowing is what to do before a planned migration. Lower the TTL on the records you are about to change to 300 seconds, then wait at least the length of the old TTL before making the actual change. That delay matters: resolvers that already cached the record at 86400 seconds will keep serving it for up to a day regardless of what you publish afterwards. Once the migration is verified, put the TTL back up. Skipping the wait is why a "quick DNS change" sometimes takes a full day to take effect for a subset of users, and it is not something you can force from your end.
CAA Records: Cheap Certificate Protection
A CAA record lists which certificate authorities are permitted to issue certificates for your domain. Certificate authorities are required to check it before issuing, so publishing one closes off a whole class of mis-issuance — a CA that is not listed must refuse the request, even if the requester passes that CA's own validation.
The cost is one record. The catch, and it is a real one, is that it applies to every CA including the ones you use indirectly. If your CDN, your load balancer, or your hosting platform obtains certificates on your behalf from a CA you did not list, renewal will fail — often silently, weeks later, with an expired certificate as the first visible symptom. List every issuer that touches your domain before publishing, and treat adding a new CDN as a reason to revisit the record.
Verifying Records After You Publish Them
Publishing is not the same as working. After the TTL window has passed, check each record type independently rather than assuming the set is correct because the page loads. Query the MX records and confirm the hosts match your provider's current documentation. Query the TXT record at the apex and confirm exactly one SPF record exists — publishing two SPF records is a permanent error under the specification, and it is a common outcome when a provider's setup wizard adds one that you already added by hand.
Then send a message to an external address you control and read the received headers to confirm SPF and DKIM both pass and both align with your domain. DMARC requires alignment, not merely a pass, and a message can pass SPF on a different domain than the one in the visible From address. If you are auditing a live site's response headers and redirects at the same time, our HTTP status code lookup and htaccess redirect generator cover the server side of the same migration.
Arb Digital handles hosting migrations end to end — TTL staging, record cutover, mail authentication, and certificate continuity — so the move happens without a gap in traffic or deliverability.
Web Development Services Talk To Our TeamCommon Mistakes to Avoid
- Publishing two SPF records — the specification allows exactly one per domain, and a second one makes both invalid rather than combining them.
- Omitting the trailing dot on MX and CNAME values in a zone file — the server then appends your domain, producing a hostname that does not resolve.
- Going straight to
p=rejectwithout reading aggregate reports first — legitimate mail from forms, CRMs, and invoicing tools gets rejected before anyone notices. - Trying to CNAME the apex domain — it conflicts with the SOA and NS records that already exist there, and provider-specific flattening is not portable.
- Changing records without lowering the TTL first — resolvers keep serving the old value for the full length of the previous TTL, not the new one.
Related Free Tools From Arb Digital
Plan the address ranges behind those records with the IP subnet calculator or condense a rule list with our CIDR range merger, generate crawler directives with the robots.txt generator, build page metadata with the meta tag generator, set up server redirects with the htaccess redirect generator, or check a response code with the HTTP status code lookup. The free online tools hub has the full set.
Frequently Asked Questions
No. The specification allows exactly one TXT record containing an SPF policy per domain. Publishing a second one causes a permanent error rather than combining them, so multiple senders must be merged into a single record.
Because a CNAME cannot coexist with other record types at the same name, and the apex already carries SOA and NS records. Providers work around this with ALIAS, ANAME, or CNAME flattening, but those are provider features rather than part of DNS.
Start with p=none, which asks receivers to report but not to act. Read aggregate reports for a week or two to find legitimate senders that are failing authentication, then move to quarantine and later reject.
Evaluating an SPF record may trigger at most ten DNS lookups, counting include, a, mx, ptr, exists, and redirect mechanisms. Exceeding it returns a permanent error, which most receivers treat as no SPF pass at all.
Up to the length of the previous TTL, because resolvers keep serving the cached value until it expires. Lower the TTL well in advance of a planned change, then restore it once the change is verified.
It is optional but cheap protection, since certificate authorities must check it before issuing. List every authority that issues for your domain, including ones your CDN or host uses on your behalf, or their renewals will fail.
No. It performs no network requests at all. It generates record syntax from the values you enter, entirely in your browser, so nothing about your domain is transmitted.
