How to Connect a Domain to Hosting and Set Up Business Email

Overview

Your domain is the public address for your website and email, while DNS is the system that tells browsers and mail servers where those services are located. Hosting supplies the web server or website platform; an email provider supplies mailboxes and mail delivery. They may be purchased from the same company, but they do not have to be.

Before changing anything, create a simple inventory of the services currently attached to the domain. Record the registrar, DNS provider, web host, email provider, subdomains, verification records, and any third-party tools such as payment platforms, analytics services, customer support systems, or email marketing tools. A DNS change can affect more than the website.

You generally have two ways to connect a domain to hosting:

• Change nameservers: Delegate DNS management to the hosting provider. This is usually simpler when the host will manage the entire DNS zone.
• Keep the current nameservers and edit DNS records: Add or update only the records needed for the website. This provides more control when email and other services already use the existing DNS provider.

Neither approach is automatically better. Nameservers can reduce setup work, but they move responsibility for the whole DNS zone. Individual records are more precise, but you must copy the host’s required values correctly and maintain them over time.

If you are moving an existing site, protect the current setup before making changes. The website migration checklist and WordPress migration checklist cover broader preparation steps that should happen alongside DNS work.

Checklist by scenario

Scenario 1: New domain and new hosting account

1. Confirm the domain is registered and that you can access its DNS or nameserver settings.
2. Obtain the hosting provider’s exact connection instructions. These may include nameservers, an IPv4 address for an A record, an IPv6 address for an AAAA record, or a target hostname for a CNAME.
3. Choose whether the host should manage DNS or whether you will keep DNS at the registrar or another provider.
4. Connect the domain in the hosting dashboard. Some hosts require verification before the site can be published.
5. Set the preferred hostname, such as the root domain, the www subdomain, or both. Configure one as the primary address and redirect the other.
6. Enable HTTPS after the domain resolves to the host. See the SSL certificate setup guide for the security portion of this process.

Scenario 2: Existing domain with email already in use

Keep the existing email records intact while connecting the website. If email works today, do not replace the entire DNS zone with a hosting provider’s default zone unless you have first copied every required mail record.

1. Leave the domain’s current MX records unchanged.
2. Add or update only the web records supplied by the host, commonly an A record for the root domain and a CNAME for www.
3. Check that existing SPF, DKIM, and DMARC records remain present.
4. Test both website access and mail delivery after the web records update.

This approach is often the safest for a business that is changing website hosting but not changing its email provider.

Scenario 3: New business email on an existing domain

1. Choose the mailbox provider and verify the domain using the provider’s requested TXT or CNAME record.
2. Replace or update MX records only when you are ready to route new mail to the provider. Copy the priority values exactly.
3. Publish the provider’s SPF record. Use one SPF TXT record for the domain rather than creating separate competing SPF records.
4. Generate or enable DKIM in the email provider, then publish the selector-specific TXT or CNAME record it supplies.
5. Add a DMARC TXT record after SPF and DKIM are working. Start with a monitoring-oriented policy if you need time to review legitimate senders, then tighten the policy according to your provider’s guidance.
6. Send test messages to more than one external mailbox and inspect the message authentication results when available.

Authentication records are provider-specific. Do not copy SPF or DKIM values from another domain, even if the domains use similar services.

Scenario 4: Moving hosting while preserving the same domain

Build and test the new site before changing DNS where possible. Confirm links, forms, redirects, media, login flows, analytics, and any integrations. If the site uses WordPress or another CMS, review the platform-specific migration steps before changing the domain’s records.

When ready, lower the DNS TTL in advance only if your provider supports this and you understand the implications. Then make the planned record change, monitor both old and new environments, and keep the old hosting account available until traffic and application behavior are stable.

What to double-check

• Record type: An A record points to an IPv4 address, an AAAA record points to an IPv6 address, and a CNAME points one hostname to another hostname. Use the type specified by the provider.
• Host or name field: DNS dashboards may represent the root domain as @, a blank field, or the full domain name. Follow that dashboard’s format.
• Trailing domain duplication: Some interfaces append your domain automatically. Entering the full name in such a field can create an unintended hostname.
• MX priorities: Lower numeric values commonly indicate higher delivery priority, but use the values supplied by the email provider rather than guessing.
• One SPF policy: Multiple SPF TXT records can cause authentication problems. Combine authorized senders into the provider-supported syntax instead of publishing separate policies.
• DKIM selector: DKIM records are tied to a selector, so the selector in the DNS record must match the selector configured by the mail provider.
• DMARC alignment: SPF and DKIM can pass while still failing alignment if the authenticated sending domain does not match the visible From domain according to the provider’s configuration.
• Subdomains: A record for example.com does not automatically configure www.example.com, shop.example.com, or another subdomain. Review each hostname separately.
• TTL and propagation: DNS changes are cached. Different networks may show old and new results during the transition, so do not assume one local lookup represents the whole internet.

Use DNS lookup tools or command-line queries to check records from more than one network. For email, test sending and receiving, not just the webmail login. For the website, test the root domain, preferred hostname, HTTPS, redirects, and any important subdomain.

Common mistakes

Replacing nameservers without copying mail records. This can make the website work while business email stops receiving messages. Export or document the existing zone first, and confirm MX, SPF, DKIM, and DMARC records are represented at the new DNS provider.

Changing MX records when only the website is moving. Web hosting and email routing are independent. If the email provider is staying the same, leave MX records alone.

Publishing more than one SPF record. Add authorized services to a single provider-supported SPF policy. If several systems send mail, review their integration instructions before editing the record.

Adding a broad DMARC policy too early. A strict policy can affect legitimate messages from forgotten systems. Monitor first, identify all authorized senders, and then adjust enforcement deliberately.

Testing only from the office network. Local caches, VPN resolvers, and corporate DNS policies can hide the public state of a record. Check from an independent network and allow time for cached responses to expire.

Forgetting account recovery and verification records. SaaS platforms, search tools, newsletters, and security products may rely on TXT or CNAME records. Include them in the inventory before changing nameservers.

When to revisit

Revisit this checklist before a planned hosting migration, email provider change, domain renewal or transfer, website redesign, seasonal campaign, or major change to the systems that send mail. It is also useful after acquiring a domain, merging brands, adding a subdomain, or discovering unexplained delivery failures.

Keep a current DNS record inventory with the record name, type, purpose, provider, and date last reviewed. Do not store mailbox passwords or private DKIM keys in that inventory. Review the list before seasonal planning cycles and whenever workflows or tools change.

Your practical final checklist is:

1. Identify the registrar, DNS provider, host, and email provider.
2. Back up or document the current DNS zone.
3. Choose nameservers or individual records based on who should manage DNS.
4. Change only the records required for the planned service.
5. Confirm website resolution, HTTPS, redirects, and subdomains.
6. Confirm MX, SPF, DKIM, and DMARC records for business email.
7. Test sending, receiving, authentication, and important website functions.
8. Monitor the transition before retiring the old host or email service.

A careful inventory and a staged change are more valuable than making every DNS change at once. When the domain, hosting, and email responsibilities are clearly separated, future migrations and troubleshooting become much easier.