DNS Settings Guide: How to Connect a Domain to Your Website and Fix Common Errors

Overview

DNS, or the Domain Name System, tells browsers and other services where to find your domain. Your registrar manages the domain registration, a DNS provider publishes the records, and your hosting provider serves the website. These services may be supplied by one company or several different companies.

Before changing anything, identify where DNS is managed. Sign in to the company that controls your domain and look for a section named DNS, DNS records, Zone editor, or Nameservers. If the domain uses custom nameservers, the active records may be managed by a separate DNS provider rather than the registrar.

You will normally need the following information from your hosting or website platform:

• The IPv4 address for the website, if you are adding an A record.
• The hostname supplied for a CNAME record, such as a platform-specific address.
• The required records for email, often MX records plus SPF, DKIM, or other TXT records.
• The instructions for enabling HTTPS or requesting an SSL certificate.

DNS changes do not instantly appear everywhere. A DNS propagation checker can help you compare results from different locations, but local browser, operating system, and network caches can still show an older result for a while. Avoid repeatedly changing records while waiting; first confirm that the values are correct and then allow time for caches to update.

Checklist by scenario

Connecting a domain to a traditional web host

1. Record the existing DNS settings before editing them. A screenshot or exported zone file can help you restore a value if needed.
2. Find the host's destination IP address. Add or edit the root record, usually shown as @, with type A and that IP address.
3. Point the www hostname to the same site. In many setups, this is a CNAME with host or name www and a target provided by the host. Some providers instead request a second A record.
4. Remove only obsolete records that conflict with the new setup. Do not delete email records simply because you are changing web hosting.
5. Add the domain inside the hosting control panel. A DNS record alone may not tell the host which site should respond to the domain.
6. Open both the bare domain and the www version after propagation. Confirm that they reach the intended site rather than a default hosting page.

Connecting a domain to a hosted website platform

1. Add the domain to the platform first, if its instructions require domain verification.
2. Copy the exact A, CNAME, or TXT values shown by the platform. Do not add the protocol, such as https://, to a DNS hostname or target.
3. Pay attention to whether the platform expects the root domain, www, or a generated subdomain. A CNAME for www does not automatically configure the root domain.
4. Complete any verification step, then set the preferred domain version in the platform settings.
5. Enable SSL only after the platform recognizes the domain. Visit the HTTPS version and check that the certificate covers the hostname you are using.

Keeping email working during a website change

Website records and email records serve different purposes. MX records direct incoming mail and must remain pointed at your email provider. TXT records may verify ownership or authorize sending services. Before changing web DNS, copy every MX and TXT record, including its host, value, priority, and any required quotation marks or formatting.

If email stops after a DNS change, check the MX records first. An A record change normally does not redirect mail, but replacing nameservers or deleting a DNS zone can remove mail records entirely. For a related symptom, see the guide to fixing a website contact form that is not sending emails.

Using nameservers instead of individual records

Some hosts ask you to replace your domain's nameservers with theirs. This transfers DNS management to the new provider. It can be a straightforward setup, but it also means the new DNS zone must contain all records you still need, including email, verification, subdomains, and third-party services. If you choose this route, recreate or import the old records before switching, then verify them after the change.

What to double-check

The distinction between an A record and a CNAME is central to most domain and hosting setup tasks:

• A record: points a hostname directly to an IPv4 address. Use the exact IP supplied by the host.
• AAAA record: points a hostname to an IPv6 address when the provider supplies one.
• CNAME record: points one hostname to another hostname. It is commonly used for www or hosted platforms.
• MX record: identifies the servers that receive email. The priority number matters when multiple records are present.
• TXT record: stores text used for verification and email-related configuration, among other purposes.

Check the host or name field carefully. Many DNS panels automatically append your domain name. Entering www.example.com in a panel that expects only a host label can create an unintended name such as www.example.com.example.com. Follow the panel's format and inspect the resulting fully qualified hostname.

Also check for conflicts. A hostname should not normally have both a CNAME and other record types at the same name. An old A record can keep sending visitors to the previous server even after you add a new CNAME. Look for duplicate A records, old forwarding records, wildcard records, and parked-domain settings.

After saving, test in this order:

1. Use a DNS lookup tool to confirm the expected record is published.
2. Check the root domain and www separately.
3. Open the site in a private browser window or a different network.
4. Confirm redirects, the canonical domain, and HTTPS behavior.
5. Test an important page, a form, and email if any records were changed.

If HTTPS produces warnings after the DNS change, the certificate may still be pending, may cover a different hostname, or the site may contain insecure resource URLs. Use the guide to fix mixed content errors after enabling HTTPS once the certificate itself is valid.

Common mistakes

Changing nameservers and records at the same time

Nameservers determine which DNS provider is authoritative. Records entered at an inactive provider will have no effect. Establish which nameservers are active before editing a zone, and avoid making unrelated changes during a migration.

Using the wrong record for the root domain

Many DNS systems do not support a normal CNAME at the root domain. If your platform provides an A record, use it as instructed. If it provides a special flattened or alias record, follow that provider's terminology rather than substituting a standard CNAME.

Forgetting the hosting-side domain setting

DNS can point visitors to a server without configuring that server to serve the correct website. Add the domain or virtual host in the hosting panel, select the correct document root, and check whether the platform requires domain verification.

Deleting records that belong to other services

Verification records, email records, analytics integrations, subdomains, and payment or support tools may all depend on DNS. Make a record inventory before cleanup. If a record is unfamiliar, identify its purpose before deleting it.

Assuming propagation is the only cause

If the site still shows an old destination after a reasonable waiting period, compare authoritative lookup results with your local result. A typo, duplicate record, inactive nameserver, proxy setting, or incorrect host configuration may be responsible. For broader service visibility, pair DNS checks with an uptime monitoring checklist.

When to revisit

Keep this DNS settings guide with your website documentation and revisit it whenever a related input changes. The most important occasions are moving to a new host, changing email providers, adding a subdomain, replacing a website platform, renewing or reorganizing SSL, or transferring domain management to another registrar or DNS provider.

Before a planned migration, lower the relevant record's TTL if your current provider and migration plan support that approach, document the existing zone, and prepare the new destination. Lower TTL values do not remove every cache immediately, so plan for overlap and verify the result from more than one network.

Use this final checklist before closing a DNS task:

• Domain ownership and renewal access are confirmed.
• Active nameservers are known.
• Existing A, AAAA, CNAME, MX, and TXT records are documented.
• Root and www records point to the intended destination.
• The domain is added in the hosting or website platform.
• Email records remain intact and mail sending and receiving have been tested.
• SSL covers the preferred hostname and redirects behave as intended.
• DNS lookups work from multiple locations after the change.
• Old hosting access, backups, and rollback information are retained until the migration is confirmed.

For related website changes, document redirects before a domain move using the 301 versus 302 redirect guide, and keep a current backup before editing production settings. A clear record inventory turns future DNS work from guesswork into a repeatable setup process.