The deployment says ready. The custom domain says otherwise.

It works on your laptop, fails on your phone, opens an old site for a customer, or reaches the homepage and breaks at login. “DNS propagation” gets blamed because it sounds patient and technical.

Sometimes waiting is correct. Often it only delays finding the wrong record.

A custom domain is a chain of authorities. Test the chain in order.

The browser must learn who answers for the domain, resolve the intended hostname, reach the correct service, negotiate a valid certificate, follow a sane redirect, and enter an application configured for that exact public origin. One weak link can make the whole launch look random.

Write the intended result first

Choose one canonical public origin before opening a DNS dashboard.

For example:

Canonical origin: https://example.com
http://example.com      -> permanent redirect to https://example.com
http://www.example.com  -> permanent redirect to https://example.com
https://www.example.com -> permanent redirect to https://example.com

You may prefer www. The choice matters less than consistency.

Record every hostname the product actually uses: marketing site, application, API, documentation, status page, asset host, email links, webhook endpoints, and OAuth callbacks. Do not assume fixing the apex repairs every subdomain.

Now capture one precise symptom:

  • hostname that failed;
  • time and location;
  • network and device;
  • browser error or HTTP status;
  • final URL after redirects;
  • whether another hostname worked;
  • whether the same user had visited the old site before.

“Domain broken” is not a reproduction. “https://www.example.com/login redirects twice, then returns to login on mobile data” is.

Find the authoritative nameservers

Your registrar sells or manages the domain. Your DNS provider answers public questions about it. Your hosting platform serves the application. These may be three different companies.

Start by asking the public DNS hierarchy which nameservers are authoritative:

dig NS example.com +short
dig example.com +trace

Compare that answer with the provider where you edited the records. A perfect record in a dashboard that is not authoritative changes nothing.

This commonly happens after a nameserver migration. The founder adds new records at the new provider but never completes the registrar change, or leaves an old nameserver in the delegation. Check all authoritative servers, not merely the first one returned.

Do not paste screenshots of secret tokens or private provider details into public support threads. The DNS answers for a public hostname are already public; account credentials are not.

Inspect the exact record

Query each hostname and each address family:

dig A example.com +short
dig AAAA example.com +short
dig CNAME www.example.com +short
dig TXT example.com +short

Then ask several public resolvers if the symptom differs by location:

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

Look for:

  • an A record pointing to the old IPv4 address;
  • an AAAA record pointing to an unused IPv6 service;
  • a CNAME aimed at the wrong deployment target;
  • duplicate records left by an earlier host;
  • an unexpected wildcard covering a missing subdomain;
  • a verification TXT record placed under the wrong name;
  • an NS delegation inside the zone that hands the hostname elsewhere.

A stale AAAA record deserves special attention when a site works for some users and fails for others. A client with working IPv6 may choose the AAAA answer while your office network silently falls back to IPv4. Do not add or keep IPv6 records unless the destination actually serves the same site over IPv6.

Cloudflare's current certificate validation troubleshooting notes the same boundary: validation may prefer IPv6, so an AAAA record that does not reach the intended dual-stack service can prevent issuance.

Understand what TTL can and cannot explain

Time to live tells recursive resolvers how long they may cache an answer. It does not mean every change always takes that long, and lowering it after a bad answer was cached does not recall the old answer.

Negative answers can be cached too. If you queried a hostname before creating it, a resolver may briefly remember that it did not exist.

Waiting is justified when:

  • the authoritative answer is now correct;
  • different recursive resolvers still show an older cached answer;
  • the remaining time roughly fits the previous TTL or negative-cache policy.

Waiting is not justified when the authoritative nameserver still returns the wrong value, SERVFAIL, or no record. Fix the source.

Avoid repeatedly deleting and recreating correct records while caches expire. Each change moves the investigation.

Check DNSSEC after changing providers

DNSSEC lets resolvers verify that an answer belongs to the signed DNS chain. A stale DS record at the registrar after moving authoritative DNS can make validating resolvers return SERVFAIL, while a non-validating test appears healthy.

Check the normal response and compare it with validation disabled:

dig A example.com @1.1.1.1 +dnssec
dig A example.com @1.1.1.1 +dnssec +cd

If the normal query fails but the checking-disabled query returns the expected answer, investigate the DNSSEC delegation before changing application code.

Cloudflare's DNSSEC troubleshooting guide describes this exact pattern and calls out stale DS records after nameserver changes as a common cause.

Do not toggle DNSSEC casually during an incident. Understand whether the registrar, registry, and authoritative provider agree, then repair the chain deliberately.

Confirm that the hosting platform accepted the hostname

Correct DNS can point to a platform that has not attached the hostname to your project.

Inspect the host's custom-domain state. Look for separate signals such as:

  • ownership verified;
  • hostname active;
  • DNS target correct;
  • certificate active;
  • production deployment assigned;
  • redirect rule enabled.

Some platforms distinguish hostname activation from certificate activation. Both need to finish. Cloudflare's certificate status documentation makes this explicit for custom hostnames: the hostname and its TLS certificate have separate states.

Check whether the platform expects an A record, CNAME, verification TXT value, or delegated setup. Copy the current target from the intended production project. An old target from another account can still resolve and serve a convincing wrong page.

If the platform reports that the domain belongs to another project or account, resolve ownership there. Adding more DNS records cannot attach the hostname twice.

Inspect the certificate, not the padlock icon

DNS only gets the browser to a server. HTTPS also requires a certificate valid for the exact hostname.

Test the handshake with Server Name Indication:

openssl s_client -connect example.com:443 -servername example.com </dev/null

Inspect:

  • the Subject Alternative Names include the requested hostname;
  • the certificate is within its validity period;
  • the chain is complete and trusted;
  • the server presents the same certificate consistently;
  • apex and www are both covered when both accept HTTPS;
  • deeper subdomains are actually included.

A wildcard for *.example.com does not normally cover the apex example.com. A certificate for example.com does not automatically cover www.example.com. Multi-level names may fall outside a platform's default coverage.

If issuance is stuck, check domain-control validation, CAA, DNSSEC, and validation-path redirects. Certificate authorities must respect applicable CAA records; Let's Encrypt documents that requirement in its certificate policy.

Do not solve a certificate error by turning off HTTPS for launch. Fix ownership and issuance, or use the platform hostname temporarily and state it clearly.

Read every redirect hop

Once HTTPS connects, inspect the response chain:

curl -I http://example.com
curl -I https://example.com
curl -I https://www.example.com
curl -IL https://www.example.com/some-real-page

Look for loops, hops to preview deployments, lost paths, and temporary redirects that should be permanent. A request for /pricing should normally arrive at the canonical /pricing, not the homepage.

Choose one layer to own each redirect. A CDN rule, hosting rule, framework middleware, and application handler can each make a sensible redirect alone and a loop together.

Google recommends permanent server-side redirects such as 301 or 308 for lasting moves and advises keeping redirect chains short in its site-move documentation. That is good for users too. Every extra hop adds another place to fail.

Test query strings when campaigns or verification links depend on them. Test a real nested page. Test both a GET and any callback route that should not be redirected unexpectedly.

Reconfigure the application for the public origin

A homepage that loads does not prove the app knows its new address.

Search production configuration for the old preview or localhost origin:

  • site or base URL;
  • cookie domain and secure setting;
  • OAuth redirect URI;
  • allowed origin and CORS list;
  • email verification and password-reset links;
  • payment success and cancel URLs;
  • webhook endpoint;
  • asset and API base URLs;
  • Content Security Policy sources;
  • canonical and Open Graph URLs.

Identity providers often require an exact callback match. Cookies set for the preview hostname do not belong to the custom domain. A redirect between apex and www can lose a session if cookie scope and application origin disagree.

Test with a fresh browser profile. Your old cookies, service worker, HSTS state, and cached redirects can make the founder's browser uniquely misleading.

The broader local-versus-production guide helps trace configuration, runtime, database, and third-party boundaries after the domain itself is sound.

Test from outside your own network

Use at least two paths you do not control:

  • mobile data;
  • a different public resolver;
  • a colleague in another region;
  • a clean browser or device;
  • a command-line request with no stored cookies.

Verify all four public variants, a nested route, signup or login, one email link, one asset, and the important product action.

If only one network fails, capture its DNS answer and connection result. Do not tell the user to clear every cache before recording the evidence. Their stale or divergent view may identify the broken branch.

If a failure exposes users to the wrong site, invalid certificate, or unsafe transaction, pause the launch link and communicate the stable URL. Reliability matters more than preserving the announcement schedule.

Repair search signals after the domain works

Choose the canonical HTTPS hostname and make every public signal agree:

  • permanent redirects from alternatives;
  • self-referencing canonical tags;
  • sitemap URLs;
  • internal links;
  • structured-data URLs;
  • robots and indexing directives;
  • social profiles and campaign links;
  • Search Console properties.

Google describes redirects, canonical annotations, and sitemap inclusion as signals in canonical selection. Do not ask those signals to vote for different hosts.

For a real domain migration, map old paths to their equivalent new paths instead of sending everything to the homepage. Keep the old domain and redirects operating. Then use the startup indexing guide to confirm that discovery, crawling, indexing, and ranking are not being confused.

Use this twenty-minute domain diagnosis

Record the answer at each boundary:

  1. What exact hostname and path failed?
  2. What is the intended canonical origin?
  3. Which nameservers are authoritative?
  4. What do those servers return for A, AAAA, CNAME, and relevant TXT records?
  5. Do public resolvers agree?
  6. Is DNSSEC valid?
  7. Has the hosting platform verified and activated the hostname?
  8. Is the certificate active and valid for the exact name?
  9. Where does each HTTP variant redirect?
  10. Does the path survive the redirect?
  11. Does the application use the public origin for cookies, OAuth, email, payments, and APIs?
  12. Does the whole journey work from a clean device on another network?
  13. Do canonical tags, internal links, and the sitemap use the final origin?

Change one boundary at a time. Record the previous value and keep a rollback where the provider permits it.

Do not say “DNS has propagated” when you mean “the homepage opened for me.” A custom domain is ready when strangers resolve the intended answer, receive the right certificate, reach one canonical URL, and complete the product journey under that origin.

That is the launch test.