How to Connect a Domain to Netlify: DNS Records, SSL, and Common Fixes

Overview

If you need to connect a domain to Netlify reliably, the job breaks into four parts:

1. Attach the domain to the correct Netlify site.
2. Create the right DNS records at either Netlify DNS or your external DNS provider.
3. Confirm the hostname resolves to Netlify before expecting SSL to finish provisioning.
4. Test the final behavior: canonical host, redirects, HTTPS, and any related email records.

The two most important choices happen early:

• Will Netlify host your DNS zone? If yes, you move nameservers to Netlify and manage records there.
• Will you keep DNS somewhere else? If yes, you only add the specific records Netlify requires and leave the rest of your zone where it is.

Both approaches work. Using Netlify DNS can reduce context switching if the site lives entirely on Netlify. Keeping DNS at Cloudflare, Route 53, or another provider may make more sense if your team already manages multiple services in one zone, uses infrastructure as code, or depends on provider-specific routing and automation. If you use an external DNS provider and want a refresher on record types and common patterns, see Cloudflare DNS Setup Guide for Domains, Subdomains, and Common Record Types.

Before changing anything, gather this short preflight checklist:

• The exact Netlify site you want the domain attached to
• The primary production hostname you want users to see, such as www.example.com or example.com
• Whether the root domain should redirect to www or the reverse
• Access to your DNS provider or registrar
• A list of non-web DNS records you must preserve, especially MX, TXT, SPF, DKIM, and DMARC for email

That last point matters more than many teams expect. Domain changes that look web-only can accidentally break email if you move nameservers without recreating mail-related records. If your domain also handles email, keep this companion reference nearby: SPF, DKIM, and DMARC Setup Guide for Google Workspace, Microsoft 365, and Custom Domains.

Checklist by scenario

Use the scenario that matches your setup instead of mixing instructions from different patterns. Most failed Netlify domain setups come from combining a nameserver-based workflow with a record-only workflow.

Scenario 1: Connect a custom subdomain like www.example.com to Netlify

This is often the cleanest starting point.

1. In Netlify, open the target site and add the custom domain, such as www.example.com.
2. At your DNS provider, create a CNAME record for www pointing to the Netlify target value shown in the site settings.
3. Wait for the new record to resolve publicly.
4. After DNS resolves correctly, let Netlify provision SSL for that hostname.
5. Test https://www.example.com and confirm the certificate is active.

Best use case: You want the least risky path, especially if the root domain is used elsewhere or if you want to keep your current DNS provider.

What to avoid: Do not use an A record for a subdomain if Netlify specifically expects a CNAME for that host.

Scenario 2: Connect the apex domain example.com to Netlify

The root domain is more sensitive because DNS standards and provider features differ.

1. Add example.com as a custom domain in Netlify.
2. At your DNS provider, create the apex records Netlify instructs you to use. Depending on the provider, this may be an A/ALIAS/ANAME-style setup rather than a traditional CNAME.
3. Make sure there are no conflicting apex A, AAAA, URL forwarding, or parking records left in place.
4. Wait for public DNS resolution to match the intended Netlify target.
5. Confirm SSL provisioning after the hostname resolves properly.

Best use case: You want the bare domain to serve the site directly, such as https://example.com.

What to avoid: Do not assume every provider handles apex CNAME behavior the same way. Follow the record type your provider supports for root-level aliasing.

Scenario 3: Use both example.com and www.example.com and choose one canonical hostname

This is the most common production pattern and usually the best one for long-term clarity.

1. Add both hostnames to the same Netlify site.
2. Point each hostname correctly at Netlify using the record pattern required by your DNS provider.
3. Choose a primary domain in Netlify, either example.com or www.example.com.
4. Verify the non-primary hostname redirects to the primary one over HTTPS.
5. Check internal links, sitemap output, and application-level canonical settings if your framework generates them.

Best use case: You want one public hostname for SEO, analytics, and user consistency while still accepting traffic on both forms.

If you also deploy to Vercel across other projects and want a similar comparison point, see How to Connect a Domain to Vercel Without DNS Errors.

Scenario 4: Move the full DNS zone to Netlify DNS

This changes more than the website. Treat it like a zone migration, not just a web deployment step.

1. Export or document all current DNS records: A, AAAA, CNAME, MX, TXT, SRV, verification tokens, and any provider-specific records.
2. Recreate those records in Netlify DNS before changing nameservers.
3. Add the domain to Netlify and note the nameservers Netlify provides.
4. At your registrar, replace the current nameservers with the Netlify nameservers.
5. Wait for nameserver changes to propagate.
6. Verify web resolution, then verify email, third-party verifications, and any service that depends on TXT or CNAME records.

Best use case: You want centralized management for a site-centric domain and are comfortable validating the entire zone after migration.

What to avoid: Never change nameservers first and plan to “add the other records later.” That is how email and verification records get lost.

Scenario 5: Add a staging or preview subdomain

This is useful for teams that want stable non-production URLs outside Netlify preview URLs.

1. Create or identify the Netlify site or branch-based deployment you want the subdomain to represent.
2. Add the staging hostname, such as staging.example.com, to the correct site.
3. Create a CNAME at your DNS provider for staging using the value Netlify expects.
4. Confirm SSL and any password protection or access controls you use for non-production environments.
5. Make sure search indexing rules are appropriate if the environment should remain private or non-canonical.

Best use case: Marketing sites, docs sites, or static front ends that need a memorable QA URL.

What to double-check

When Netlify DNS setup does not work, the fix is usually found in one of these checks. Work through them in order instead of changing several things at once.

1. The domain is attached to the correct Netlify site

This sounds obvious, but it is a frequent problem in teams with multiple environments. Confirm the domain is added to the right site, not a retired project, sandbox, or personal workspace copy.

2. The DNS record type matches the hostname type

• Subdomain: usually CNAME
• Apex/root: often A, ALIAS, or ANAME depending on provider support

If you use the wrong record type, SSL may remain pending because the hostname never resolves where Netlify expects.

3. There are no conflicting records

Look for duplicate or outdated entries for the same host:

• Old A records left behind at the apex
• An AAAA record pointing somewhere else
• A CNAME coexisting with incompatible records on the same name
• Registrar forwarding rules still active
• Parking or default provider records not removed

4. DNS is actually public, not just saved in the dashboard

A record existing in your provider UI does not guarantee the world sees it yet. Query the hostname from outside your network and check the current public answer. If you need a workflow for that, use DNS Propagation Checker Guide: How to Verify Record Changes and Troubleshoot Delays.

5. CDN or proxy features are not masking the real target

If your DNS provider supports proxying, acceleration, or edge masking, temporarily confirm whether Netlify can still validate the hostname properly through that layer. In many setups, DNS-only mode is the safer choice during initial verification.

6. The primary domain setting matches your intended canonical host

If both example.com and www.example.com are attached, make sure the preferred one is selected as primary in Netlify. Then test redirects in a browser and with a command-line request to confirm behavior is consistent.

7. SSL is waiting on DNS, not broken by itself

In most cases, SSL provisioning problems are downstream of DNS problems. If the hostname does not resolve correctly, certificate issuance cannot complete. Fix resolution first, then recheck SSL status.

8. Email records were preserved during any DNS move

If you switched nameservers to Netlify DNS, test email flow and confirm that your MX and TXT records still exist. Teams often notice broken web traffic quickly, but missed mail records may go unnoticed until messages start bouncing or authentication fails.

Common mistakes

This section is the short list to scan when you are under time pressure.

Changing nameservers when you only meant to add one record

If your goal is just to connect a site, you may only need to add a CNAME or apex alias at your current provider. A nameserver migration is larger and riskier.

Forgetting that apex and subdomain setups are different

The root domain and www do not always use the same record logic. A clean www setup does not automatically imply a clean apex setup.

Leaving old records active

Old hosting records are one of the biggest causes of inconsistent behavior. A browser may hit one answer while another resolver gets something else. Remove stale records once you know the new target is correct.

Testing too early and assuming failure

DNS changes can take time to appear globally, and local caches can make the picture look worse. Check public resolution before cycling through more changes.

Mixing redirect logic across too many layers

You might have redirects in Netlify, your framework, your DNS provider, or the registrar. Pick the layer intentionally. If the browser is bouncing between hosts or protocols, simplify until one layer clearly owns the redirect behavior.

Ignoring non-web records during DNS migration

MX, TXT verification records, SPF, DKIM, DMARC, and service-specific CNAMEs are easy to overlook during a move to Netlify DNS. Make a full record inventory first.

Attaching the same hostname to multiple platforms

If a domain is still configured at a previous host, or if another platform expects to control the same hostname, verification can become confusing. Retire old attachments once the cutover is complete.

When to revisit

The best time to revisit your Netlify custom domain setup is before something changes, not after. Keep this checklist in your release or launch process and return to it in these situations:

• Before launching a new marketing site or docs site on an existing domain
• Before seasonal campaigns when temporary subdomains, redirects, or microsites are added
• When moving DNS providers such as from registrar DNS to Cloudflare or Route 53
• When changing the canonical host from apex to www or the reverse
• When splitting production and staging onto separate subdomains
• When email or third-party verification records are added and the zone becomes more crowded
• When workflows or ownership change and the team needs a documented, repeatable process

For a practical recurring process, save this action list in your deployment runbook:

1. Decide whether DNS stays external or moves to Netlify DNS.
2. List every hostname you need: apex, www, staging, redirects.
3. Choose the canonical hostname and write it down.
4. Inventory existing DNS records before touching nameservers.
5. Add the custom domain in the correct Netlify site first.
6. Create only the required DNS records for that scenario.
7. Confirm public resolution before troubleshooting SSL.
8. Test HTTPS, redirects, and the final canonical URL.
9. Recheck email and TXT-based service integrations if the zone changed.
10. Remove stale records and document the final state for the next launch.

If you keep that sequence consistent, most Netlify domain troubleshooting becomes faster because you can isolate whether the problem is attachment, DNS, propagation, SSL, or redirect logic. That is what makes this a useful checklist to revisit: the domain names may change, but the failure patterns are usually the same.