Connecting a Custom Domain to Your Website: DNS Records, Verification and SSL Explained

🌐 Domains · Updated October 2026 · 11 min read · by Jacob Campbell

To connect a custom domain to a website, you add DNS records at whoever hosts your domain’s DNS: usually an A record (or an ALIAS/flattened CNAME) for the bare domain, a CNAME or A record for www, and often a TXT record that proves to the hosting service that you control the domain. Once those records resolve, the host can obtain an SSL certificate automatically through the ACME protocol (usually from Let’s Encrypt), and the site goes live on HTTPS.

Most failed connections come down to a handful of causes: a wrong or leftover record, an AAAA record nobody remembered, a proxy sitting in front of the server, or a CAA record that forbids the certificate authority. This guide explains each record, what “propagation” really is, how automatic certificates are issued, and how to check every step yourself with dig, nslookup and free online tools.

Key facts

RFC 1034 — A CNAME cannot share a name with other records, so it cannot sit at the apex
Port 80 — Where Let’s Encrypt checks an HTTP-01 challenge
90 → 45 days — Let’s Encrypt default certificate lifetime, shrinking by February 2028
CAA — The DNS record that can silently block certificate issuance

A records, CNAMEs and why the apex is special

An A record maps a name directly to an IPv4 address, while a CNAME says “this name is an alias for another name” and makes the resolver look that other name up instead.

A record: example.com. 3600 IN A 203.0.113.10. The AAAA record does the same for an IPv6 address.
CNAME record: www.example.com. 3600 IN CNAME example.com. or www.example.com. CNAME sites.somehost.net.. Useful when the host may change its IP addresses, because you point at a name they control.

A CNAME cannot be used at the bare domain (the “apex” or “root”, such as example.com). The rule comes from RFC 1034, section 3.6.2: “If a CNAME RR is present at a node, no other data should be present.” The apex always carries other data, namely the zone’s SOA and NS records, and usually MX and TXT records too. Most DNS dashboards simply refuse to save an apex CNAME.

DNS providers work around this in three ways, none of which is a formal standard:

ALIAS or ANAME records (names vary by provider): you enter a hostname, and the provider’s nameservers look it up and answer with plain A/AAAA records. An IETF draft to standardise ANAME (draft-ietf-dnsop-aname) expired in 2021 without becoming an RFC, so behaviour differs between providers.
CNAME flattening (Cloudflare’s term): you may enter a CNAME at the apex, and Cloudflare resolves it and returns the final IP addresses instead. See Cloudflare’s CNAME flattening docs.
Plain A records: if your host gives you a stable IP address, an A record at the apex is the simplest and most portable choice.

www vs apex: pick one and redirect the other

A site should answer on both example.com and www.example.com, serve its content on one of them, and send a permanent (301 or 308) redirect from the other.

Which one you choose matters less than being consistent: the canonical tags, sitemap and internal links should all use the same hostname. Practical points:

Both names need DNS records. A redirect cannot happen if www does not resolve at all. Typically the apex has an A record and www has a CNAME to the apex or to the host.
Both names need a certificate. Someone typing https://www.example.com must reach a valid certificate before the redirect can be followed. Make sure both hostnames are on the certificate (or that each has its own).
Redirect in one hop. http://www.example.com should go straight to https://example.com/, not through two or three intermediate redirects.

On Apache, an apex-preferred redirect in .htaccess looks like this:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

If you are moving an existing site to a new domain or host, the redirect plan matters as much as the DNS; see our SEO migration guide.

TXT verification records: proving you control the domain

A TXT verification record is a random token the service gives you to publish in your DNS, which proves you control the domain because only someone with access to its DNS could put it there.

Hosting platforms, search consoles, email services and certificate authorities all use this pattern. Without it, anyone could point their own account at a domain they do not own, or claim a domain that merely happens to resolve to a shared server. A typical record looks like:

example.com.   3600  IN  TXT  "google-site-verification=AbC123..."
_acme-challenge.example.com.  300  IN  TXT  "gfj9Xq...Rg85nM"

Things that commonly go wrong:

The name is doubled. Many dashboards append your domain automatically, so typing _verify.example.com creates _verify.example.com.example.com. Enter only the part before your domain (or @ for the apex) unless the dashboard says otherwise.
Quotes or spaces are pasted in. Copy the value exactly; let the dashboard add quotation marks if it wants them.
The record is deleted afterwards. Many services re-check periodically, so leave verification records in place unless the service says they can go.
It is proxied. On Cloudflare, records used for third-party verification should be set to DNS only, as Cloudflare’s proxy status docs recommend. TXT records cannot be proxied, but CNAME-based verification records can be, and then the check fails.

TTL and “propagation”: what actually takes time

DNS changes do not travel across the internet; your DNS provider’s authoritative servers usually serve a new record within seconds or minutes, and the delay people call “propagation” is resolvers elsewhere still holding an older answer in cache.

Every record has a TTL (time to live) in seconds. A resolver that cached your old A record with a TTL of 3600 may keep handing it out for up to an hour. So:

Lower the TTL in advance. If a record has a TTL of 86400 (one day), drop it to 300 at least a day before the change, wait for the old TTL to run out, then make the change. Raise it again once everything works.
New records are usually fast; changed records wait for the old TTL. There is one exception: negative caching. If someone looked up a name before it existed, their resolver can cache the “does not exist” answer for a period set by your zone’s SOA record (RFC 2308). Add records before you announce the domain.
Nameserver changes are slower. Switching the nameservers at your registrar changes delegation records held by the domain’s registry, whose TTL you do not control, and resolvers may keep using the old nameservers until that expires. Keep the old DNS host serving correct records during the switch.
“Up to 48 hours” is a cautious ceiling, not a typical wait. With sensible TTLs, most changes are visible within minutes to an hour. If a change is still not visible after its old TTL has passed, check that you edited the zone at the provider your domain actually delegates to.

How the SSL certificate is issued automatically

Modern hosts get certificates automatically using ACME (RFC 8555), the protocol Let’s Encrypt created, in which the certificate authority issues a certificate only after a challenge proves you control the domain.

The two challenges you will meet, as described in Let’s Encrypt’s challenge types documentation:

HTTP-01: the CA fetches http://example.com/.well-known/acme-challenge/<TOKEN> on port 80 and expects a specific file. It follows redirects (up to 10, to ports 80 or 443 only). This is what most hosts use: as soon as your A record points at their server, they can answer the challenge themselves. It cannot issue wildcard certificates, and it fails if port 80 is blocked.
DNS-01: the CA looks up a TXT record at _acme-challenge.example.com. It is the only one of the challenges that can issue wildcard certificates (*.example.com), and it works for servers that are not reachable from the internet. The cost is that whatever requests certificates needs API access to your DNS, or you delegate _acme-challenge to another zone with a CNAME.
TLS-ALPN-01 also exists, runs over port 443, and is used mainly by large hosting providers and TLS-terminating proxies.

Certificates are short-lived on purpose and are renewed automatically. Let’s Encrypt certificates currently last 90 days by default. Its announced schedule moves the default to 64 days on February 10, 2027 and to 45 days on February 16, 2028, and recommends renewing using ACME Renewal Information (ARI) or about two-thirds of the way through a certificate’s life. If you run your own server, automate renewal and monitor certificate expiry; a manual reminder will not keep up.

CAA records and HSTS: the two settings that bite later

A CAA record lists which certificate authorities may issue certificates for your domain, and if one exists that does not name your host’s CA, issuance fails even when everything else is correct.

CAA is defined in RFC 8659. With no CAA records, any public CA may issue once it has validated control; once a CAA record exists, only the listed CAs may. The CA checks the exact name first and walks up the tree to the parent domain, stopping at the first CAA record set it finds, and it follows CNAMEs, as Let’s Encrypt’s CAA guide explains. So a CAA record added years ago for one CA can block a new host that uses another. To allow Let’s Encrypt alongside an existing CA:

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "digicert.com"

Ask your host which CA it uses before editing; some use more than one.

HSTS (HTTP Strict Transport Security, RFC 6797) is a response header that tells browsers to use HTTPS only for your domain for a set time:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Browsers ignore the header when it arrives over plain HTTP, so it only takes effect once HTTPS works. Start with a short max-age (for example 300) while you confirm everything works, then raise it. Be careful with includeSubDomains if any subdomain still serves plain HTTP, and treat the preload list as a long-term commitment: hstspreload.org requires a max-age of at least 31536000, includeSubDomains and preload, and warns that removal “cannot easily be undone”.

Common failures and how to fix them

Almost every domain that “will not connect” fails for one of a small number of reasons, and each one can be confirmed from the outside in a minute.

Wrong or duplicate A record. An old A record for the previous host is still there alongside the new one, so visitors and the CA land on either server at random. Remove every A record at that name except the one your host gave you.
Leftover AAAA record. An IPv6 record still points at the old host or a parking page. Let’s Encrypt connects over IPv6 first when an AAAA record exists and only falls back to IPv4 on a timeout, not on a wrong answer (see its IPv6 support page), so a stale AAAA record can fail validation even when the A record is right. Delete it unless your new host gave you an IPv6 address.
Cloudflare proxy turned on. With the orange cloud on, lookups return Cloudflare’s addresses, not your host’s, so a host that checks “does your A record point to us?” reports a mismatch. Set the record to DNS only until the host has verified the domain and issued its certificate, or follow the host’s specific Cloudflare instructions.
Cloudflare SSL mode mismatch. In Flexible mode Cloudflare talks to your server over plain HTTP; if the server redirects HTTP to HTTPS, you get a redirect loop (ERR_TOO_MANY_REDIRECTS). Use Full (strict) once the origin has a valid certificate; in that mode an invalid or expired origin certificate gives Error 526. Cloudflare documents both in its redirect-loop guide.
CAA record excludes the CA. Look for CAA at the name and every parent; add the host’s CA.
Records edited at the wrong provider. The registrar shows a DNS editor, but the domain’s nameservers point somewhere else (an old host, Cloudflare), so the edits never take effect. Check the NS records first.
Port 80 blocked or redirected wrongly. HTTP-01 needs port 80 to answer, and any redirect has to keep the /.well-known/acme-challenge/ path intact.

How to check it yourself: dig, nslookup and online tools

The fastest way to diagnose a domain is to ask public DNS what it actually returns, rather than trusting what the dashboard shows.

With dig (macOS, Linux, or WSL on Windows):

# Which nameservers is the domain delegated to?
dig +short NS example.com

# What does the apex resolve to? Check IPv4 AND IPv6.
dig +short A example.com
dig +short AAAA example.com

# Ask a specific public resolver, bypassing your local cache
dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8

# What does www point to?
dig +short CNAME www.example.com

# Verification and CAA records, and the remaining TTL
dig TXT example.com
dig CAA example.com

# Follow the delegation from the root down
dig +trace example.com

On Windows without WSL, nslookup does the same job:

nslookup -type=A example.com 1.1.1.1
nslookup -type=AAAA example.com 1.1.1.1
nslookup -type=TXT example.com 8.8.8.8
nslookup -type=NS example.com

Then check the certificate and HTTPS behaviour:

# Status codes and redirects for each variant
curl -sI http://example.com
curl -sI https://www.example.com

# Certificate subject, issuer and dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Free online tools give the same answers from outside your network: Google Admin Toolbox Dig for records, SSL Labs for the certificate chain and TLS settings, and crt.sh to see every certificate issued for your domain through Certificate Transparency logs.

Product facts: AIWebBuilding domains and the AI Indexing Pack

Stated plainly, so it can be checked against the product pages:

Custom domains on AIWebBuilding: AIWebBuilding gives customers two records to add (an A record and a TXT verification record), then sets up the domain and its certificate and checks it from the outside before switching it on.
What the AI Indexing Pack is: the AI Indexing Pack is a set of files you upload to your own website. It is sold by Built2WinWeb as a one-time purchase, with no subscription.
What it ships: (1) a working MCP server using the Streamable HTTP transport, with typed output schemas and tool annotations; (2) Markdown content negotiation, so agents can request a clean text version of each page; (3) llms.txt, agents.txt and agent cards; (4) the full /.well-known/ discovery tree; (5) OAuth protected-resource metadata; (6) bot access control that verifies crawler identity; (7) a README with a verification checklist.
Requirements: PHP 7.4 or newer, Apache or LiteSpeed with .htaccess support, FTP access, and a domain you control. Installation takes about 30 minutes.
What it is not: it is not a WordPress plugin (that is the separate WordPress edition, which needs WordPress 6.0+ and PHP 8.0+), it does not write content for you, it does not guarantee rankings or citations, and it is not a managed service.
Free routes in: sites built on AIWebBuilding get the core built in, and a 50-day streak on FreeAIBoost unlocks the pack for one domain. Current prices are on the product pages.

Frequently asked questions

Why can’t I put a CNAME record on my root domain?

RFC 1034 says no other data may exist at a name that has a CNAME, and the root (apex) of a domain always has SOA and NS records. Use an A record, or your DNS provider’s ALIAS, ANAME or CNAME-flattening feature instead.

How long does DNS propagation take?

New records are usually visible within minutes, and changed records within the old record’s TTL, because the delay is resolver caching rather than slow transmission. Nameserver changes can take longer because the registry’s delegation records are cached too.

Why does a website host ask me to add a TXT record?

A TXT verification record proves you control the domain’s DNS, so nobody can attach a domain they do not own to their account. Leave it in place unless the service says it can be removed, because many services re-check it.

What is the difference between HTTP-01 and DNS-01 certificate challenges?

HTTP-01 proves control by serving a file at /.well-known/acme-challenge/ on port 80, while DNS-01 proves it with a TXT record at _acme-challenge. With Let’s Encrypt, only DNS-01 can be used for wildcard certificates.

Why is my SSL certificate not being issued even though DNS is correct?

The usual causes are a leftover AAAA record pointing at another server, a CAA record that does not list your host’s certificate authority, a CDN proxy hiding your server, or port 80 being blocked. Check each with dig or an online DNS tool.

Want your domain connected properly?

We set up DNS, redirects, certificates and HSTS for client sites, and check them from the outside before launch.

Get a free quote