How to Connect Your Domain to Your Hosting: DNS Setup Guide

TL;DR

To connect your domain to your hosting, you need to create DNS records that tell the internet where your website and email live. At minimum, add an A record pointing your domain to your server's IP address, a CNAME record for the www subdomain, and MX records if you use email. Changes take anywhere from a few minutes to 48 hours to propagate worldwide. Lower your TTL values before making changes, verify with dig or nslookup, and always double-check that you haven't placed a CNAME at your root domain.

Prerequisites

• A registered domain name (e.g., example.com)
• Access to your domain registrar's control panel (GoDaddy, Namecheap, Cloudflare, etc.)
• Your hosting server's IP address (e.g., 203.0.113.10)
• A terminal with dig and/or nslookup installed (available by default on macOS and most Linux distributions; on Windows, use nslookup or install dig via BIND utilities)
• If using third-party email: the MX record values from your email provider

DNS Basics: Record Types Explained

DNS (Domain Name System) translates human-readable domain names into IP addresses and service endpoints. Here are the record types you will work with most often:

A Record (Address)

Maps a domain name directly to an IPv4 address.

example.com.    3600    IN    A    203.0.113.10

AAAA Record (IPv6 Address)

Same as an A record, but for IPv6.

example.com.    3600    IN    AAAA    2001:db8::1

CNAME Record (Canonical Name)

Creates an alias from one name to another. The DNS resolver follows the chain to the final A/AAAA record.

www.example.com.    3600    IN    CNAME    example.com.

MX Record (Mail Exchange)

Specifies which mail servers accept email for the domain. The number is the priority (lower = higher priority).

example.com.    3600    IN    MX    10    mail.example.com.

TXT Record

Holds arbitrary text data, commonly used for domain verification, SPF, DKIM, and DMARC.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

NS Record (Nameserver)

Delegates a domain (or subdomain) to specific nameservers.

example.com.    86400    IN    NS    ns1.hosting-provider.com.
example.com.    86400    IN    NS    ns2.hosting-provider.com.

Changing Nameservers at Your Registrar

If your hosting provider manages DNS for you, you will need to point your domain's nameservers to theirs. This delegates all DNS resolution to the hosting provider's nameservers.

Generic Steps

1. Log in to your domain registrar's control panel.
2. Navigate to the domain management or DNS settings page.
3. Find the Nameservers section (often under "Advanced DNS" or "Domain Settings").
4. Switch from the default nameservers to Custom Nameservers.
5. Enter the nameservers provided by your hosting company (e.g., ns1.hosting-provider.com and ns2.hosting-provider.com).
6. Save the changes.

Registrar-Specific Notes

• GoDaddy: My Products → Domain Settings → Nameservers → Change → Enter my own nameservers.
• Namecheap: Domain List → Manage → Nameservers dropdown → Custom DNS.
• Cloudflare (as registrar): If you transfer your domain to Cloudflare, nameservers are automatically set to Cloudflare's. If Cloudflare is only your DNS provider, you change the nameservers at your original registrar to the ones Cloudflare assigns you (e.g., ada.ns.cloudflare.com).

Important: Nameserver changes propagate at the registry level and can take up to 24–48 hours, though most complete within 1–2 hours.

Pointing Your Domain to a Server

The most fundamental operation: mapping your domain to your server's IP address.

Step 1: Create an A Record for the Root Domain

In your DNS control panel, create an A record:

Name:   @   (or example.com)
Type:   A
Value:  203.0.113.10
TTL:    3600

The @ symbol represents the root/apex domain.

Step 2: Create a CNAME or A Record for www

Most visitors will type www.example.com, so you must handle it:

Name:   www
Type:   CNAME
Value:  example.com.
TTL:    3600

Alternatively, you can create a second A record for www pointing to the same IP. The CNAME approach is preferred because if you later change your server IP, you only update one record.

Setting Up Subdomains with CNAME

Subdomains let you run different services on different addresses under the same domain.

blog.example.com.      3600    IN    CNAME    example.com.
shop.example.com.      3600    IN    CNAME    myshop.shopify.com.
status.example.com.    3600    IN    CNAME    stats.uptimerobot.com.

Each subdomain can point to a completely different server or service. This is how you can host your blog on one platform and your shop on another, all under the same domain.

MX Records for Email

If you want to receive email at you@example.com, you need MX records pointing to your email provider's mail servers.

Google Workspace

example.com.    3600    IN    MX    1     ASPMX.L.GOOGLE.COM.
example.com.    3600    IN    MX    5     ALT1.ASPMX.L.GOOGLE.COM.
example.com.    3600    IN    MX    5     ALT2.ASPMX.L.GOOGLE.COM.
example.com.    3600    IN    MX    10    ALT3.ASPMX.L.GOOGLE.COM.
example.com.    3600    IN    MX    10    ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365

example.com.    3600    IN    MX    0    example-com.mail.protection.outlook.com.

Replace example-com with your actual domain (hyphens replacing dots), as provided in your Microsoft 365 admin center.

TXT Records for Verification & Security

Google Domain Verification

example.com.    3600    IN    TXT    "google-site-verification=AbCdEfGhIjKlMnOpQrStUvWxYz"

SPF (Sender Policy Framework)

SPF tells receiving mail servers which servers are authorized to send email on behalf of your domain.

; Google Workspace SPF
example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

; Microsoft 365 SPF
example.com.    3600    IN    TXT    "v=spf1 include:spf.protection.outlook.com ~all"

; Combined (if using both a hosting server and Google Workspace)
example.com.    3600    IN    TXT    "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"

Important: You can only have one SPF record per domain. If you need multiple senders, combine them into a single record using multiple include: or ip4: directives.

Understanding TTL

TTL (Time To Live) is a value in seconds that tells DNS resolvers how long to cache a record before checking again.

• 300 (5 minutes) — Good for records you change frequently, or before a migration.
• 3600 (1 hour) — A sensible default for most records.
• 86400 (24 hours) — Appropriate for stable records like NS records.

Migration Strategy

Before migrating to a new server, lower your TTL well in advance:

1. 48 hours before migration: Lower TTL to 300 on all records you plan to change.
2. Wait for the old TTL to expire (if it was 86400, wait at least 24 hours).
3. Perform the migration: Update the A record to the new IP address.
4. After confirming everything works: Raise TTL back to 3600 or higher.

DNS Propagation

When you change a DNS record, the new value does not appear instantly worldwide. DNS resolvers around the world cache records according to the TTL value.

• Typical propagation: 5 minutes to 4 hours for records with low TTLs.
• Worst case: Up to 48 hours if old records had high TTLs and are cached by stubborn resolvers.

Checking Propagation with dig +trace

dig +trace example.com A

This follows the full resolution chain from root servers down to authoritative nameservers, bypassing your local cache. You see exactly what the authoritative answer is right now.

Checking Against Specific DNS Servers

# Check against Google's public DNS
dig @8.8.8.8 example.com A

# Check against Cloudflare's public DNS
dig @1.1.1.1 example.com A

# Check against your authoritative nameserver directly
dig @ns1.hosting-provider.com example.com A

Verifying Your DNS Setup

Using dig

$ dig example.com A +short
203.0.113.10

$ dig www.example.com CNAME +short
example.com.

$ dig example.com MX +short
1 ASPMX.L.GOOGLE.COM.
5 ALT1.ASPMX.L.GOOGLE.COM.

$ dig example.com TXT +short
"v=spf1 include:_spf.google.com ~all"

Using nslookup

$ nslookup example.com
Server:   1.1.1.1
Address:  1.1.1.1#53

Non-authoritative answer:
Name:     example.com
Address:  203.0.113.10

$ nslookup -type=MX example.com
Server:   1.1.1.1
Address:  1.1.1.1#53

Non-authoritative answer:
example.com   mail exchanger = 1 ASPMX.L.GOOGLE.COM.

Full Diagnostic Check

# Check all common record types at once
for type in A AAAA CNAME MX TXT NS; do
  echo "=== $type ==="
  dig example.com $type +short
  echo
done

Troubleshooting

Domain not resolving at all

• Verify nameservers are set correctly: dig example.com NS +short
• If you recently changed nameservers, wait up to 48 hours.
• Check if the domain has expired at your registrar.

Website works without www but not with www (or vice versa)

• You likely forgot to create the www CNAME or A record. Add it.

CNAME at root domain causes issues

The DNS specification (RFC 1034) forbids CNAME records at the zone apex. A CNAME at example.com (without a subdomain) will break MX and TXT records. Use an A record for the root domain. Some providers offer a workaround called ALIAS or ANAME records (Cloudflare calls it "CNAME flattening"), which behave like CNAME but resolve to an A record at query time.

Email not working after DNS changes

• Check MX records: dig example.com MX +short
• Ensure there is no CNAME at the root domain (it would override MX records).
• Verify SPF/DKIM/DMARC TXT records are in place.

Old IP still showing up

• Check the TTL of the old record. You may need to wait for caches to expire.
• Verify the authoritative server returns the correct IP: dig @ns1.your-provider.com example.com A +short
• Flush your local DNS cache:

  # macOS
  sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  
  # Windows
  ipconfig /flushdns
  
  # Linux (systemd-resolved)
  sudo systemd-resolve --flush-caches

Conflicting records

If you have both an A record and a CNAME for the same name, behavior is undefined and most providers will reject this. Remove one.

Prevention: Avoiding Common Mistakes

1. Never place a CNAME at the root domain. Use an A record (or ALIAS/ANAME if your provider supports it).
2. Always set up both example.com and www.example.com. Users type both.
3. Lower TTL before making changes. This ensures faster propagation when you actually update the record.
4. Keep only one SPF record. Multiple TXT records with v=spf1 will cause SPF validation to fail.
5. Do not mix CNAME with other record types on the same name. A CNAME must be the only record for that name (except for DNSSEC-related records).
6. Document your DNS records. Keep a spreadsheet or text file listing all records. When something breaks at 2 AM, you will be grateful.
7. Test changes with dig before and after. Always verify the authoritative nameserver returns the expected result before assuming the change is live.
8. Use a secondary/backup MX record. If your primary mail server is down, a secondary MX ensures email is queued rather than bounced.