Knowing the DNS records needed for a new website prevents a common setup mistake: changing records until something appears to work. DNS, or the Domain Name System, tells browsers and email systems where to find services for your domain. A new website usually needs only a few records, but the exact values come from your hosting provider.
The difficult part begins when your website, email, domain registration, and security services use different companies. Planning the DNS records needed for a new website helps you separate those responsibilities. Each provider may request a record at the same domain name. Some records can coexist, while others conflict. This guide explains what each record does and how to plan the change safely.
Start with DNS authority and provider responsibilities
Before adding anything, identify which provider hosts the authoritative DNS zone. The authoritative provider stores the records that answer public DNS queries. It may be your registrar, your web host, a DNS security provider, or another service.
Your registrar controls domain registration. That does not always mean it controls DNS. Nameservers published at the registrar identify the provider that answers DNS questions for the domain. Cloudflare provides a useful overview of DNS resolution and records.
Make a written inventory before editing the zone:
- Domain registrar and renewal account
- Authoritative DNS provider and nameservers
- Website hosting provider
- Email provider
- SSL, analytics, payment, and verification services
- Existing records that must remain unchanged
This inventory matters because changing nameservers can replace the visible DNS zone. If you move DNS authority without copying required records, the website, email, or other services may stop working. See our guide to what happens when you change domain nameservers before making that type of change.
The core website records
Most websites use an address record at the root domain and another record for the www hostname. Your host may use different instructions, so treat examples as concepts rather than universal settings.
A records point to IPv4 addresses
An A record maps a hostname to an IPv4 address. For example, the root domain might point to a web server address supplied by the host. A browser uses that result to begin connecting to the website.
The root, sometimes shown as @, is commonly configured with an A record. Some DNS systems require the full domain name instead. Follow the field labels in your DNS control panel.
Do not add an A record simply because another tutorial shows one. Use the address provided for your account. Two A records can provide intentional distribution, but an accidental second address can send visitors to the wrong server.
AAAA records point to IPv6 addresses
An AAAA record maps a hostname to an IPv6 address. IPv6 is a newer Internet addressing system. A hosting provider may give you an AAAA value in addition to an A value.
Only publish an AAAA record when the website host supports IPv6 correctly. If the AAAA address is wrong or incomplete, some visitors may fail while others reach the site through IPv4. That split can make the problem difficult to recognize.
CNAME records create aliases
A CNAME record makes one hostname an alias of another hostname. The usual example is www pointing to a host-provided name such as a platform domain. The target must be a hostname, not an IPv4 address.
A CNAME is useful when the provider manages changing server addresses behind the target name. However, a standard DNS zone cannot normally have a CNAME and another record at the same hostname. Therefore, do not place a CNAME and A record together at www unless your provider documents special behavior.
The root domain creates an extra complication. Traditional DNS does not allow a normal CNAME at the zone root because the root also needs essential zone records. Some providers offer an ALIAS, ANAME, or CNAME-flattening feature. These names describe provider-specific behavior, not identical standards.
TXT records and verification records
TXT records store text used by many systems. Website platforms often request a TXT record to prove domain ownership. Search tools, certificate services, security platforms, and email systems may also use TXT records.
A verification record usually contains a provider-specific name and value. The name might be the root domain or a label such as _verify. Copy the value exactly. Extra spaces, quotation marks, or an incorrect hostname can cause verification to fail.
Several TXT records can exist at the same name. Do not overwrite an existing TXT record without checking its purpose. The existing entry might support email authentication, another verification process, or a security policy.
SPF is also published as a TXT record. It identifies servers allowed to send email for the domain. SPF is not a website record, but it often appears during a website launch because teams configure email at the same time. Our article on SPF, DKIM, DMARC, and PTR records covers the email side in more detail.
MX records belong to email, not website hosting
MX records tell receiving mail servers where to deliver email for your domain. They do not direct website visitors. A new website can use one provider while email remains with Microsoft 365, Google Workspace, an email host, or a private mail server.
That separation is important. Pointing the domain’s A record to a website host does not move email. Likewise, changing MX records does not normally change where the website loads.
Each MX record includes a mail server hostname and a priority number. Lower numbers generally receive preference. Keep all required MX records from the email provider. Removing or replacing them during a website launch can interrupt inbound mail.
Email providers may also require TXT records for SPF, DKIM, and DMARC. DKIM commonly uses a selector hostname, while DMARC uses the _dmarc label. Google and Microsoft both publish guidance on email authentication and sender requirements, including Google’s Email Sender Guidelines.
How hosting and email providers create conflicts
The most common conflict occurs when a website host gives instructions that appear to replace all DNS records. A website normally needs only specific web records. Email records should remain with the email provider unless you are intentionally moving mail.
Another conflict occurs when two services both request the root domain. One may request an A record, while another requests a CNAME at the root. Standard DNS cannot satisfy both in the same way. Ask the providers which service should control the root and whether the platform supports an ALIAS or similar feature.
Subdomains can reduce conflicts. You might use the root domain for the main website, www as a web alias, shop for an ecommerce platform, and app for a hosted application. Each hostname can point to a different service when the records do not overlap.
Never create multiple MX records from unrelated email providers as a test. Receiving systems may deliver mail to the wrong service or create confusing fallback behavior. Plan an email migration separately, using an inventory and a cutover checklist.
A safe record-planning checklist
Use this sequence before publishing changes. Reviewing the DNS records needed for a new website against the current zone helps prevent accidental deletions:
- Confirm the authoritative nameservers.
- Export or record the current DNS zone.
- Ask the website host for exact A, AAAA, or CNAME values.
- Confirm whether the root domain or
wwwshould point to the host. - List every current MX, SPF, DKIM, DMARC, and verification record.
- Add only the website records required for the launch.
- Check for duplicate or conflicting records at the same hostname.
- Test the root domain,
www, key subdomains, and email. - Record what changed, when, and why.
Before editing, check the provider’s time-to-live, or TTL, guidance. TTL tells DNS resolvers how long they may cache an answer. A lower TTL can help during a planned change, but cached results may still appear for a period. DNS troubleshooting should compare answers from more than one resolver, not just one computer.
What to verify after publishing records
First, test both the root domain and www. Confirm that each reaches the intended website and that HTTPS works. If the site redirects one hostname to another, verify that the redirect matches your preferred public address.
Next, test email in both directions. Send a message to the domain and send one from the domain. Review the headers when possible. They can show which servers handled the message and whether authentication passed.
Finally, check important subdomains and third-party services. A booking system, payment page, VPN portal, or hosted application may depend on records that are easy to overlook. If the site itself loads but a service fails, compare the affected hostname with the provider’s requested record.
For more layered diagnosis, use our guide to separating DNS, network, and application faults. A correct DNS answer does not prove that the web server, firewall, application, or SSL configuration works.
Keep the DNS zone understandable
Good DNS management is less about having many records and more about knowing why each record exists. Label records in internal documentation, note their provider, and record renewal or verification dependencies.
Do not delete an unfamiliar record during a website launch. Investigate it first. A short review can prevent an unrelated outage involving email, a security service, or a business application.
The DNS records needed for a new website usually include an A record, an AAAA record when IPv6 is supported, or a CNAME for a hosted alias. TXT records may prove ownership, while MX records keep email pointed at its existing provider. The right answer depends on your domain’s current services and your host’s instructions.
When providers disagree, records conflict, or email and website changes must happen together, professional help can reduce risk. Tech Rescue Ops LLC can review the zone, document dependencies, and validate the result remotely before a launch.