Domain, DNS, and Email Setup Guide for a New Website

Overview

Your domain registrar, web host, and email provider may be three different services. DNS is the directory that connects the domain name to those services. When someone visits example.com, DNS helps their browser find the correct web server. When someone sends mail to you@example.com, DNS identifies the mail servers responsible for receiving it.

Before making changes, record the current setup. Note where the domain is registered, which provider hosts the website, which service handles email, and whether DNS is managed at the registrar or through a separate DNS provider. Save existing records or export the DNS zone if the provider supports it. This gives you a recovery reference if a record is removed or entered incorrectly.

There are two common ways to connect a domain to cloud web hosting:

• Change nameservers: You delegate DNS management to the hosting or DNS provider. That provider then manages the domain's DNS zone.
• Keep the current nameservers: You leave DNS at the registrar or existing provider and add the web host's required records manually.

Use one approach consistently. Changing nameservers does not automatically guarantee that every existing record will be copied correctly, so review email, verification, subdomain, and third-party service records before switching.

Checklist by scenario

Scenario 1: Connect the root domain to a website

1. Find the hosting provider's required record. This is commonly an A record pointing the root domain to an IPv4 address, although some platforms provide another method.
2. Open the DNS manager and locate the record for the root or apex domain. It may be shown as @ or as the domain name itself.
3. Replace an old, conflicting A record only when you are certain the old service is no longer required. Multiple A records can produce inconsistent results unless the provider specifically supports that configuration.
4. Set the TTL according to the provider's guidance. A shorter TTL can make planned changes easier to roll back, while a longer TTL may reduce repeated DNS lookups.
5. Confirm that the hosting platform recognizes the domain and has issued or enabled SSL for it.

Scenario 2: Connect the www version

The root domain and www are separate hostnames. Add a CNAME record for www if your hosting provider supplies a target such as a platform hostname. Avoid placing a CNAME and another record type for the same hostname unless your DNS provider explicitly supports it.

Choose a preferred version, such as https://example.com or https://www.example.com, and configure the other version to redirect to it. Test both versions over HTTPS after the DNS change. This prevents visitors and search engines from encountering two competing versions of the same site.

Scenario 3: Set up professional email

1. Obtain the exact MX records from your email provider. MX records identify where incoming mail should be delivered.
2. Remove obsolete MX records only after confirming that the old mailbox service is no longer in use. Leaving old and new providers together can send messages to the wrong destination.
3. Enter each MX record with the provider's hostname and priority. A lower preference value commonly indicates higher priority, but follow the provider's instructions rather than assuming a format.
4. Add the provider's required SPF, DKIM, and DMARC records as TXT records. These help receiving mail systems evaluate whether messages are authorized and whether they appear to have been altered.
5. Send test messages to and from more than one mailbox. Check delivery, replies, attachments, and the message headers if authentication results need investigation.

SPF is usually published as one TXT record for the domain. If more than one service sends mail on your behalf, their authorization mechanisms must be combined carefully rather than published as separate SPF records. DKIM normally requires a provider-specific TXT or CNAME record at a selector hostname. DMARC is published at _dmarc and should be introduced with a policy appropriate to your monitoring and enforcement readiness.

Scenario 4: Add subdomains

Subdomains such as blog.example.com, app.example.com, and staging.example.com need their own DNS records. Use an A record when the subdomain should point to an IP address, or a CNAME when it should point to another hostname. Keep staging and development subdomains protected with access controls; DNS alone does not make a private environment secure.

Scenario 5: Move a website to new cloud hosting

Complete the website migration before changing production DNS. Copy files and databases, test the site on a temporary hostname or preview URL, confirm redirects, and lower the DNS TTL ahead of a planned cutover if appropriate. Keep the old hosting active until the new site is working and traffic is reaching it consistently. For a broader launch sequence, use the complete website launch checklist.

What to double-check

• Nameservers: Verify which provider is authoritative. Editing records in a non-authoritative DNS dashboard will not change the live domain.
• Record names: Providers differ in whether a field expects @, a full domain, or only the hostname portion. Enter the value in the format shown by the DNS interface.
• Trailing dots: Some systems display fully qualified hostnames with a trailing dot. Do not add or remove it unless the interface requires a particular format.
• Conflicts: Check for duplicate A, CNAME, MX, or SPF records. A CNAME generally cannot share the same hostname with other record types.
• SSL coverage: Confirm that both the preferred domain and its alternate, such as the www version, load over HTTPS and redirect correctly.
• Email authentication: Confirm that DKIM uses the correct selector and that your SPF record includes every legitimate sending service. Review DMARC reports or authentication results before tightening enforcement.
• Propagation: DNS changes are cached. Different networks may show old and new answers during the transition, so test from more than one connection and avoid repeated edits before the earlier change can be observed.

After the basic connection works, review performance and technical SEO settings. A useful next step is the website performance and technical SEO checklist for cloud hosting.

Common mistakes

• Changing nameservers without copying email records: The website may work while mail stops arriving because the new DNS zone lacks MX, SPF, DKIM, or verification records.
• Editing DNS at the wrong provider: First identify the authoritative nameservers, then make changes in that provider's zone.
• Using an A record for a hostname that the platform expects as a CNAME: Follow the hosting provider's exact instructions, especially when the destination can change.
• Publishing multiple SPF records: Combine authorized senders into one valid SPF policy rather than adding several separate policies.
• Forgetting the www hostname: A working root domain does not automatically mean that www works.
• Testing only from a familiar network: Local caches can hide an error or make a successful change appear incomplete. Use independent DNS lookup tools and separate networks when possible.
• Deleting records without an inventory: Domain verification, payment, analytics, collaboration, and security services may depend on TXT or CNAME records that are not obvious from the website setup.

When to revisit

Revisit this checklist before a website launch, hosting migration, domain transfer, email provider change, major rebrand, or seasonal planning cycle. It is also worth reviewing after adding a new email-sending tool, marketing platform, support system, subdomain, or third-party verification service.

At each review, confirm the registrar account has current recovery details, document the authoritative nameservers, remove records for retired services, and verify that the website and email tests still pass. Keep a dated copy of the DNS record list and note why unusual records exist. This small maintenance habit makes future troubleshooting faster and reduces the risk of breaking an unrelated service while connecting a domain to a website.

For the final action check, verify these five outcomes: the preferred domain resolves to the intended host, the alternate hostname redirects, HTTPS works, incoming and outgoing email pass authentication checks, and the DNS configuration is documented. Once those results are confirmed, the domain and hosting setup is ready for normal operation.