Connect a Domain to Hosting: DNS Records, SSL, and Email Setup

Overview

Your domain registrar manages the domain registration, while DNS tells browsers and other services where that domain should go. Your hosting provider stores and serves the website. An email provider handles mail delivery. These services can be purchased from the same company, but they do not have to be.

Before changing anything, record the current setup. Sign in to the registrar and note the existing nameservers and DNS records. Pay particular attention to any A, AAAA, CNAME, MX, TXT, and NS records. A website may be moved without moving email, so deleting mail records during a hosting change can interrupt business communication.

There are two common ways to connect a domain and hosting:

• Change nameservers: Point the domain to the hosting provider's DNS service. The provider then manages the zone and supplies records for the website, SSL validation, subdomains, and sometimes email.
• Edit DNS records: Keep the current DNS provider and add or update only the records required by the hosting provider. This is useful when email, verification records, or other services already depend on the existing DNS zone.

Neither approach is automatically better. Changing nameservers can simplify management, while editing individual records offers more control and reduces the scope of a change. Use the method documented by your hosting provider, and confirm which service should remain authoritative for DNS.

For broader hosting decisions, see How to Choose Cloud Hosting for a Small Business Website. If the domain connection is part of a larger move, the website migration checklist provides additional preparation steps.

Checklist by scenario

Scenario 1: You are launching a new website

1. Confirm the domain spelling, registration status, and renewal access.
2. In the hosting control panel, add the domain as the primary domain, an addon domain, or the appropriate site address.
3. Copy the hosting provider's required target: an IP address for an A record, an IPv6 address for an AAAA record, or a hostname for a CNAME record.
4. At the DNS provider, point the root domain, such as example.com, to the specified target. Some DNS interfaces display the root as @.
5. Point www to the root domain or to the hostname supplied by the host. Do not create conflicting records for the same name.
6. Save the changes and allow time for caches to update. Continue building the site on the hosting provider's temporary URL if one is available.
7. Request or enable an SSL certificate after the domain resolves to the correct server. Then test both https://example.com and https://www.example.com.

Scenario 2: You are moving an existing site to cloud hosting

1. Build or restore the website on the new host before changing DNS.
2. Test pages, forms, media, redirects, login areas, scheduled tasks, and integrations using a staging address or temporary host URL.
3. Lowering DNS TTL before the change may help some resolvers refresh sooner, but it does not guarantee immediate global updates.
4. Copy the final content and database, then change only the website records required by the new host.
5. Keep the old hosting account available until the new site is working and traffic is reaching it consistently.
6. Recheck email records. Website migration should not require changing MX, SPF, DKIM, or DMARC records unless the email provider is also changing.

For WordPress-specific steps, use the WordPress cloud hosting migration checklist.

Scenario 3: You need a subdomain

A subdomain such as app.example.com, blog.example.com, or staging.example.com is normally created with a separate A or CNAME record. Use an A record when the subdomain should point directly to an IP address. Use a CNAME when it should follow another hostname, such as a platform-provided endpoint. Add the subdomain in the hosting control panel as well; a DNS record alone may not configure the web server or application.

Decide whether the subdomain should be publicly indexed. A staging environment should be protected with authentication and appropriate search-engine controls, not merely placed on an obscure address. For structural considerations, see Subdomain vs. Subdirectory.

Scenario 4: You are setting up business email

1. Choose the email provider and create the required mailboxes or aliases.
2. Add the provider's MX records exactly as documented. The priority value determines preference when multiple records exist.
3. Add the provider's SPF instruction as a single TXT record. If an SPF record already exists, update it rather than creating a second SPF record.
4. Generate and publish the provider's DKIM record, often a TXT or CNAME record under a selector such as selector1._domainkey.
5. Add a DMARC TXT record at _dmarc. Begin with a monitoring-oriented policy if you need to observe legitimate senders before enforcing stricter handling.
6. Send test messages to and from more than one mailbox. Check delivery, replies, attachments, and the message authentication results where available.

Do not guess email record values. Providers can use different hostnames, priorities, selectors, and verification methods. Follow the current instructions from the provider responsible for mail.

What to double-check

• Nameserver authority: Make changes at the DNS provider identified by the domain's active nameservers. Editing records at the registrar will have no effect if another provider is authoritative.
• Root and www behavior: Confirm that both versions of the domain resolve and that one redirects consistently to the preferred version.
• Record conflicts: A hostname should not have incompatible record types. A CNAME generally cannot coexist with other records at the same hostname.
• Trailing dots and host fields: DNS dashboards interpret names differently. A field containing www may automatically append the domain, while a fully qualified hostname may need a trailing dot.
• SSL coverage: Confirm that the certificate includes every public hostname you use. Test HTTPS, redirects, mixed-content warnings, forms, and assets.
• Propagation: Check the domain from more than one network or DNS lookup tool. Cached answers can differ by resolver and record.
• Email continuity: Verify MX, SPF, DKIM, and DMARC after every nameserver change, even when email was not part of the original project.

Once the site is live, review loading behavior and redirects as well as DNS. The website speed optimization checklist can help separate hosting, page, and configuration issues.

Common mistakes

Changing nameservers without copying essential records

A new DNS zone may contain only the records needed for the website. Before switching nameservers, recreate email, verification, API, and subdomain records at the new provider.

Adding a second SPF record

SPF should be published as one TXT policy for a domain. If several services send mail, combine their authorized mechanisms according to each provider's instructions instead of publishing separate SPF policies.

Expecting propagation to be instant

DNS changes are cached. A successful lookup from one location does not prove that every user sees the same answer. Keep the old site and relevant services available during a planned transition.

Activating HTTPS before DNS is correct

Many certificate systems need to verify control of the domain. If the domain still points to the old host, certificate issuance or validation may fail. Point DNS first, then complete SSL setup and test the final URLs.

Forgetting application-level settings

DNS only directs traffic. The website platform may still need the domain added, the canonical URL updated, trusted host settings configured, or redirect rules enabled. A WordPress installation, for example, may require its site URL and home URL to match the intended HTTPS address.

When to revisit

Keep this checklist with the domain and hosting records, and revisit it whenever an underlying input changes. Useful review points include:

• Before migrating to a different cloud hosting provider or changing the website platform.
• Before a seasonal launch, campaign, product release, or other period when downtime or missed email would be costly.
• When changing business email providers, adding a transactional email service, or introducing a new application that sends mail.
• When adding subdomains for staging, customer portals, APIs, documentation, or ecommerce.
• When a domain, SSL certificate, hosting account, or email service is renewed, transferred, or administered by a new team member.
• When users report certificate warnings, redirect loops, missing pages, slow DNS resolution, or undelivered messages.

For a final practical pass, write down the registrar, authoritative DNS provider, hosting provider, email provider, preferred canonical domain, and renewal contacts. Export or record the DNS zone where your provider permits it. After every change, verify website resolution, HTTPS, subdomains, and test email. This small operating record makes future domain and hosting setup safer, especially when workflows or tools change.