DNS management: how to configure records for new domains

It is record design: an apex CNAME that collides with SOA and NS data, an SPF policy that exceeds its lookup budget, an MX target pointing at an unresolvable hostname, or a migration performed against a 24-hour cache.

DNS management is not a control-panel exercise. It is the maintenance of a zone file under protocol constraints. The registrar delegates the domain. The authoritative DNS provider serves the zone. Everything after that depends on whether the records are syntactically valid, operationally coherent, and cached on terms we understand.

For a newly registered domain, we begin with the smallest possible working zone. Then we add web routing, mail, verification records, and security controls in that order. The sequence matters. A zone cluttered with copied templates produces indexation failures, mail delivery faults, and diagnostic noise that is expensive to isolate later.

Core DNS record types and RFC compliance

A standard domain DNS setup normally requires fewer records than most registrar dashboards imply. The core types have distinct jobs. Mixing them is how zones become difficult to audit.

The A and AAAA records serve different networks. An A record publishes IPv4. An AAAA record publishes IPv6. They are not substitutes. If a host has both, clients may attempt IPv6 first depending on their resolver and network stack. A stale AAAA record can therefore create an intermittent outage: some visitors reach the site over IPv4, others encounter a timeout over IPv6.

This is a recurring forensic pattern in expired-domain redeployments. The operator changes the A record, tests from a local IPv4 connection, and declares the site live. Our external crawl then sees a dead IPv6 endpoint. Search-engine bots, mail systems, API clients, and users do not necessarily follow the same address family path.

CNAME records require a different level of discipline. A CNAME says that one hostname is an alias for another hostname. It does not point directly to an IP address. For example:

• www may be a CNAME to a hosting platform endpoint.
• shop may be a CNAME to a commerce provider endpoint.
• A verification subdomain may be a CNAME to a SaaS validation host.

The target should be a fully qualified hostname supplied by the destination service. Do not improvise a shortened name. Do not point an MX record to a CNAME target. And do not treat a CNAME as a universal forwarding mechanism. It is DNS aliasing only; it does not create HTTP redirects, preserve URL paths, or resolve application-layer errors.

The protocol limits are rarely reached by ordinary domain investors, but they become relevant in automated provisioning. A single DNS record has a maximum wire-format size of 4,096 bytes. A fully qualified domain name cannot exceed 253 characters, and each label is limited to 63 characters. Long verification strings, deeply nested subdomains, and poorly generated DKIM selectors can approach boundaries that basic dashboard validation does not explain well.

A DNS zone is correct only when every record is valid in isolation and compatible with the records beside it.

For aged-domain acquisitions, preserve nothing by default. Historic DNS residue is not an asset. A legacy A record may lead to a parked server. A forgotten TXT record may disclose a former provider. Old MX entries can accept mail intended for the new operation. Start with a zone export for evidence, then build a clean production zone from the current requirements.

The zone apex is not a normal hostname

The zone apex is the bare domain: example.com, often displayed in a DNS dashboard as @. It already carries mandatory SOA and NS records. This creates the most common configuration error in new-domain deployments.

RFC 1034 and RFC 1912 do not permit a conventional CNAME at the zone apex because a CNAME cannot coexist with other record types at the same name. The apex must retain SOA and NS data. If the domain also receives mail, it will commonly need MX and TXT records there as well.

That means this construction is invalid in standard DNS:

• @ → CNAME → hosting-provider.example
• @ → MX → mail.example
• @ → TXT → SPF policy

A DNS interface may allow the first entry, hide the conflict, or translate it into provider-specific behavior. That does not turn it into portable DNS. It means the provider is applying a proprietary abstraction.

Some managed DNS platforms offer ALIAS, ANAME, or CNAME flattening at the apex. These features can be operationally useful. They are not standard CNAME records, and their implementation differs between vendors. One provider synthesizes A and AAAA answers after resolving the target. Another performs flattening only for certain query types. Another does not export the behavior in a way that survives a DNS migration.

For a domain investor, this has a practical implication: an apex configuration that works at one DNS host may fail during a registrar or nameserver move. Treat proprietary apex aliasing as provider state, not as a portable zone-file primitive.

The conservative pattern is straightforward:

1. Use A and, where properly supported, AAAA records at the apex when the origin has fixed addresses.

2. Use www as a CNAME when the platform requires a hostname target.

3. Redirect one web hostname to the canonical hostname at the HTTP layer.

4. If an apex alias service is required, document the provider-specific dependency before moving nameservers.

5. Keep MX, SPF, DMARC, verification TXT records, and DNSSEC material at the apex without attempting to overlay them with a conventional CNAME.

This distinction matters in domain SEO as well. DNS decides whether the host resolves. The web server decides whether www and the apex consolidate through a permanent redirect. A CNAME cannot replace canonicalization. If both hostnames return separate content without a redirect strategy, the issue is at the HTTP layer, not in the zone file.

TTL is a cache-control parameter, not a propagation button

TTL, or time to live, defines how long a recursive resolver may reuse a cached DNS answer. It does not push changes across the internet. No authoritative server broadcasts an update to every resolver. Each resolver refreshes when its locally cached answer expires, subject to its own operating behavior.

This is where migration plans often fail. The operator changes the record, sees the authoritative answer update immediately, and assumes the change is complete. It is not complete. It is merely available for the next cache miss.

For stable production web records, an A or AAAA TTL of 1,800 to 3,600 seconds is usually a defensible baseline. That is 30 to 60 minutes. It limits stale-answer exposure without forcing recursive resolvers to query the authoritative servers unnecessarily often.

MX records change less frequently. TTLs in the 3,600 to 14,400 second range are typical for stable mail routing. Lower values are not automatically safer. They raise authoritative query volume and can conceal a system that is being changed too often.

A planned migration needs a separate TTL regime:

1. Lower the relevant TTLs to 300 seconds approximately 24 to 48 hours before the cutover. This gives existing higher-TTL caches time to expire.

2. Confirm the new origin independently. Test the target server directly, including HTTPS certificates, redirects, application behavior, and IPv6 if an AAAA record will be published.

3. Change the record at the authoritative DNS provider. Do not confuse a registrar panel with the active DNS service. First verify which nameservers are delegated.

4. Observe recursive resolution from multiple networks. Compare responses, but do not mistake a single public DNS result for global convergence.

5. Restore a stable TTL after the migration window. Leaving production records at 300 seconds permanently is rarely justified.

Even a TTL of zero does not guarantee an instant global result. Public resolvers may enforce minimum cache floors. Google Public DNS, for example, can apply a 30-second minimum. Some networks also retain answers longer than the published TTL due to local policies, intermediate systems, or flawed implementations. A realistic migration window is measured in cache expiry, not in dashboard confirmation.

Anycast DNS hosting improves authoritative DNS resilience and query latency by serving the same nameserver identity from multiple locations. It does not repair a bad zone. It does not bypass TTL. It does not make a registrar-level nameserver change instantaneous. Anycast changes where authoritative queries are answered; it does not alter the logic of recursive caching.

For web projects where DNS changes coincide with a platform move, hosting performance should be checked separately from DNS correctness. A review of WordPress hosting providers for performance and speed can help frame the origin-side decision, but it cannot compensate for stale records or a malformed zone.

Lowering TTL after the record change is not migration planning. By then, the old cache lifetime has already been issued.

Email records need an authentication model, not copied strings

Email is usually the first component to fail after a domain changes hands. The website can be live while password resets, contact forms, invoices, and forwarding rules silently fail. The DNS zone may look populated. That is not evidence of a valid mail configuration.

MX records tell other mail systems where to deliver inbound email. They use priority values: lower numeric values have higher preference. The MX target must resolve to an A or AAAA record. It should not be a CNAME. If the domain does not send or receive email, do not publish decorative MX records. An unused mail path is still an attack and abuse surface.

SPF, DKIM, and DMARC are published through TXT records, but they solve different problems:

• SPF authorizes servers permitted to send mail for the envelope sender domain.
• DKIM publishes a public key that lets recipients validate a cryptographic signature applied by the sending system.
• DMARC states how recipients should evaluate SPF and DKIM alignment and where aggregate or forensic reports may be sent.

SPF is the record most often damaged by convenience. A domain must have one effective SPF policy. Multiple TXT entries beginning with v=spf1 do not merge into a larger permission set. They create a PermError condition in many evaluations.

The other hard limit is DNS lookup count. SPF evaluation permits no more than 10 DNS lookups. Includes, redirects, a, mx, exists, and some ptr mechanisms can consume that budget. A policy assembled from a mailbox provider, a CRM, a newsletter platform, a support desk, and a transactional sender can exceed the limit without appearing unusually long.

The audit method is mechanical:

• Identify every service that sends as the domain, including web forms and billing software.
• Obtain the provider’s current SPF inclusion mechanism rather than relying on an old setup guide.
• Count the recursive lookup paths, not merely the visible include statements.
• Remove services that no longer send mail.
• Publish one SPF TXT policy at the sending domain.
• Test alignment after a real message is sent.

DKIM records can be long and may be split into quoted segments by DNS interfaces. That is normal if the published content reassembles into the intended key. The selector is part of the lookup path. A DKIM record under selector._domainkey.example.com cannot validate mail signed with a different selector.

DMARC should not begin at a reject policy simply because a template says so. First confirm that legitimate sources pass SPF or DKIM with domain alignment. A monitoring policy can expose unknown senders and alignment failures. Once the sending inventory is complete, enforcement becomes a policy decision rather than an experiment conducted against production mail.

For acquired domains, inspect historical reputation separately from current DNS. Clean SPF syntax does not erase past abuse signals, and a newly published DMARC record does not repair a damaged sending reputation overnight. DNS authentication proves control and alignment. It is not a reputation reset mechanism.

DNSSEC validates DNS data; it does not encrypt it

DNSSEC adds cryptographic authentication and integrity to DNS responses. It is designed to help resolvers detect forged data. It does not encrypt DNS traffic. It does not hide queries. It does not protect a domain from DDoS by itself.

The core DNSSEC record types are:

• DNSKEY, which publishes public keys for a signed zone.
• RRSIG, which contains signatures over DNS record sets.
• DS, which connects a child zone’s key material to its parent in the DNS hierarchy.
• NSEC, which provides authenticated denial of existence within the signed zone.

The operational risk is the chain of trust. DNSSEC is not finished when a provider toggles “enable signing.” The DS record must be correctly published at the registrar or registry layer for the delegated domain. If the DNS provider changes and the DS record remains tied to old key material, validating resolvers can treat the domain as bogus. The domain may resolve for some users and fail for others, depending on validation behavior.

This is not a minor availability concern. A broken DNSSEC chain can make a technically live website unreachable to security-validating resolvers. It can also disrupt mail and API services that rely on the same domain.

Before enabling DNSSEC, establish who owns each operational step:

DNSSEC is appropriate when the registrar and DNS provider support a documented DS workflow and the team can manage key rollover and provider migration. It is not appropriate as a checkbox enabled without an exit plan. A domain portfolio with frequent nameserver moves requires especially careful control of DS records. The operational burden is real.

The minimum viable zone is usually the safest zone

The correct DNS configuration for a new domain is not the largest one. It is the smallest zone that resolves the intended web hosts, routes mail only where needed, authenticates legitimate senders, and carries security controls that the operator can maintain.

Our baseline deployment order is strict:

1. Confirm registrar delegation and authoritative nameservers.

2. Create the apex and www web routing records.

3. Test A and AAAA answers independently.

4. Configure MX only if the domain receives mail.

5. Publish one SPF policy, then DKIM and DMARC for actual senders.

6. Set production TTLs after the infrastructure is stable.

7. Enable DNSSEC only when the DS lifecycle is understood.

8. Re-crawl the zone after every registrar, DNS host, or mail-provider change.

There is a binary decision at the end of the audit. If the apex uses a conflicting CNAME, SPF exceeds ten lookups, stale AAAA data remains live, or DNSSEC delegation is broken, the zone fails. Do not bid on the explanation. Fix it or pass the domain into a non-production holding state.

DNS management is infrastructure control. A clean zone has no decorative records, no unexplained legacy endpoints, and no assumptions about propagation. That is the standard.