Your custom domain has said "pending" for 3 days.
Here's what DNS and SSL are actually doing in 2026.

Disclosure: I'm a senior backend tech lead in Paris and I run Belmo, a small European PaaS. This article mentions Belmo once near the end. Everything else is platform-agnostic and works no matter where you deploy.

You bought the domain on Friday. You pasted two DNS records into your registrar, clicked "verify" on your host, and got a grey badge that says "Pending". It is now Monday. The badge still says "Pending". You have re-pasted the records four times, cleared your browser cache twice, and you are starting to wonder if you broke something that cannot be unbroken.

You did not break anything. In almost every case I review, the domain is one small misunderstanding away from working, and the founder has been staring at the wrong layer the whole time. So here is the actual chain, in the order it runs, with the commands to inspect each link yourself.

Why "pending" is almost never your host's fault

Connecting a custom domain is not one action. It is a four-link chain, and "Pending" just means the chain is broken somewhere upstream of your host. The four links are: your registrar holds the records, the public DNS system propagates them, a certificate authority validates that you control the name, and only then does your host flip the domain to "live" and start serving HTTPS.

When people say "the domain is not working", they almost always mean one of two very different things. Either the name does not resolve to the right place yet (a DNS problem), or it resolves fine but the browser shows a scary certificate warning (an SSL problem). These are separate layers with separate failure modes, and the fastest way to stay stuck for three days is to treat them as one thing. The first command you should run is the one that tells you which layer you are actually on:

dig +short yourdomain.com
dig +short www.yourdomain.com

If those return the IP or hostname your host gave you, DNS is done and your problem is SSL. If they return nothing, or an old IP, or your registrar's parking page, your problem is DNS and SSL has not even started yet. Most people skip this step and spend the weekend debugging the wrong half.

DNS in 2026: the apex domain is still the part that trips everyone

The single most common cause of a stuck domain is the apex. Your "apex" or "root" domain is yourdomain.com with nothing in front of it. The www.yourdomain.com version is a subdomain, and subdomains are easy: you point a CNAME record at the hostname your platform gave you and you are done. The apex is harder because the original DNS spec does not allow a CNAME on the root of a domain. A root can only hold an A record (an IPv4 address) or an AAAA record (an IPv6 address), not a pointer to another name.

That rule is why modern hosts hand you a fixed IP for the apex and a CNAME for www, or why some registrars invented non-standard record types called ALIAS, ANAME, or "CNAME flattening" to fake a CNAME at the root. If your registrar supports flattening (Cloudflare and a few others do), use it and point the apex at your host's hostname. If it does not, you use the A record with the IP your host gave you. A typical correct setup looks like this:

Type    Name    Value
A       @       203.0.113.10        ; the apex, "@" means root
CNAME   www     app.yourhost.com.   ; the www subdomain

The @ symbol means "the root of this zone". Some registrars want you to leave the name blank instead, some want the full domain typed out. All three mean the same thing, and getting that field wrong is the second most common reason a domain stays pending. After you save, verify from outside your own network, because your laptop may be caching an old answer:

dig @1.1.1.1 yourdomain.com A +short
dig @8.8.8.8 yourdomain.com A +short

Querying Cloudflare's 1.1.1.1 and Google's 8.8.8.8 directly tells you what the rest of the world sees, not what your ISP's resolver cached an hour ago.

The SSL handshake nobody explains to founders

Say DNS is correct and the name resolves. Now your host needs a certificate so browsers stop screaming. In 2026 almost nobody buys certificates anymore. Your platform requests one automatically from Let's Encrypt (or ZeroSSL, or Google Trust Services) using a protocol called ACME, and the certificate is free and renews itself every 60 to 90 days. The catch is that the certificate authority will not hand over a certificate until it proves you control the domain, and there are two ways it does that.

The first is HTTP-01 validation. The authority asks your server to serve a specific token at http://yourdomain.com/.well-known/acme-challenge/.... For this to work, the domain has to already resolve to your host over plain HTTP on port 80. This is the gotcha that surprises people who proxy everything through Cloudflare with the orange cloud turned on: the proxy intercepts port 80, your host never sees the challenge, and the certificate never issues. The fix is usually to set the Cloudflare record to "DNS only" (grey cloud) during the initial issuance, or to switch the host to DNS-01 validation.

The second method is DNS-01 validation, where the authority asks you to publish a TXT record and checks DNS instead of HTTP. This is what you need for wildcard certificates, and it is more robust behind proxies, but it requires your host to have API access to your DNS or requires you to add the record by hand. You can watch the certificate negotiation happen with openssl:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

That prints who issued the certificate, what name it covers, and when it expires. If the subject line does not match your domain, or the issuer is some self-signed placeholder, your host has not finished issuing yet, and the chain is still stuck at the validation step rather than at DNS.

The six things that actually keep a domain pending

After enough of these, the same six causes account for nearly all of them. A CAA record is the sneaky one: if your domain has a Certificate Authority Authorization record that names a different authority, Let's Encrypt is contractually forbidden from issuing, and the failure is silent. Check with dig yourdomain.com CAA +short. If it returns a line naming, say, digicert.com and your host uses Let's Encrypt, that is your three-day mystery. Either remove the record or add 0 issue "letsencrypt.org".

The second is a stale AAAA record. If you set an IPv6 AAAA record pointing at an old server but your A record points at the new one, IPv6-capable clients (most phones) hit the dead address while your laptop on IPv4 sees the working one. The domain looks fine to you and broken to half your users. Delete orphan AAAA records unless you are deliberately serving IPv6.

The third is the proxied-Cloudflare port 80 problem above. The fourth is TTL: if your old records had a 24-hour TTL, the world keeps serving the cached old answer for up to a full day after you change them, and there is nothing you or your host can do but wait. Lower the TTL to 300 seconds before a planned migration, not after. The fifth is a registrar lock or an unverified domain, where the registrar has paused DNS changes pending an email confirmation you never clicked. The sixth is the boring one: a typo in the record value, a trailing dot that should or should not be there, or the record saved under the wrong subdomain. Re-read the value character by character before you assume the system is broken.

I have lost real hours to the CAA one specifically. On a migration for a fintech client (the kind where downtime is measured in angry compliance emails), a domain refused certificates for an afternoon because a CAA record set years earlier still pinned the old authority. Nothing in any dashboard surfaced it. One dig CAA would have saved the afternoon, which is exactly why it is now the first thing I check.

Wildcards, www, and the redirect you forgot

Two smaller decisions cause a long tail of support tickets. First, decide whether your canonical home is yourdomain.com or www.yourdomain.com and redirect the other one to it with a 301. Serving both as live, separate origins splits your SEO and your cookies and will eventually confuse an OAuth callback. Pick one, redirect the other, move on.

Second, if you really do need many subdomains (app., api., docs., staging.), do not issue a separate certificate per subdomain by hand. Get a wildcard certificate for *.yourdomain.com via DNS-01 validation, which covers all current and future subdomains at once. A wildcard does not cover the apex itself, so the standard production setup is a wildcard for *.yourdomain.com plus a normal certificate for the bare yourdomain.com. Most managed platforms do this for you, but it is worth knowing why two certificates show up instead of one.

What I built, and why

I kept solving this same chain by hand for clients, every migration, the same six checks in the same order, so I eventually baked it into the platform I run. Belmo issues and renews certificates automatically through ACME, detects the proxied-port-80 and CAA cases during domain setup and tells you which one is blocking you instead of showing a silent grey "Pending", and runs apex domains without making you understand the CNAME-at-root problem first. The free Starter tier includes a custom domain with automatic HTTPS and does not sleep, which matters here because a certificate cannot renew on a server that is asleep when the authority comes knocking.

Honest about the limits: if your registrar does not support CNAME flattening, you still have to paste an A record by hand, and if your DNS lives somewhere we cannot reach by API, wildcard issuance still needs you to add one TXT record yourself. The chain has links that no platform owns, and pretending otherwise is how founders end up confused about whose fault "pending" is.

What to do tonight, regardless of which platform you use

Seven checks, in order, none of them more than a couple of minutes.

1. Run dig +short yourdomain.com and decide which layer you are debugging: empty result means DNS, a scary browser warning means SSL. Stop debugging both at once.
2. Query an external resolver with dig @1.1.1.1 yourdomain.com A +short so you see what the world sees, not your cached copy.
3. Run dig yourdomain.com CAA +short and confirm it is either empty or names the authority your host actually uses. This one check resolves more silent failures than any other.
4. Check for orphan AAAA records with dig yourdomain.com AAAA +short and delete any that point somewhere your A record does not.
5. If you proxy through Cloudflare, set the record to grey-cloud "DNS only" until the first certificate issues, then turn the proxy back on if you want it.
6. Inspect the live certificate with the openssl s_client command above and confirm the subject matches your domain and the dates are current.
7. Lower your TTL to 300 seconds now, before any future migration, so the next change propagates in five minutes instead of a day.

The honest closing

None of this is hard once you can see the layers, and all of it is invisible until something breaks. The trap is that "Pending" is a single word covering at least six unrelated failures, and the dashboards rarely tell you which one you are looking at. The commands above turn that one grey word into a specific, fixable answer in about ninety seconds.

The question I want to leave you with: when your last domain got stuck, which of the six was it, and how long did it take you to find out? I suspect CAA records and proxied port 80 are far more common than anyone admits, but I only see the projects that land on my desk.

Related reads on this blog: I migrated 12 client projects off Heroku — here's the playbook. · Your indie SaaS has no staging environment — the 30-minute setup. · The Claude Code → production checklist: 15 things that aren't obvious.