How long should custom domain verification actually take?

DNS propagation typically completes in 5–60 minutes globally. Let's Encrypt certificate issuance takes another 30 seconds to 5 minutes. Total expected time from a clean configuration is under 1 hour. Anything past 2 hours indicates a real problem, not propagation. Anything past 24 hours indicates a stuck verifier or a CAA-record block that won't resolve without intervention.

Why does base44 verification fail even when my DNS resolves correctly?

Three common reasons. First, base44's DNS resolver might use a different resolver chain than your validation tool, hitting different cache state. Second, CAA records on your domain may permit only specific certificate authorities, blocking Let's Encrypt. Third, base44's internal verifier itself can hang on a single failed check and never retry, requiring manual support intervention to reset.

How do I check CAA records and why do they matter?

CAA (Certification Authority Authorization) records tell certificate authorities whether they're allowed to issue for your domain. If you have CAA records permitting only DigiCert or another CA, Let's Encrypt cannot issue and base44 silently fails. Check with `dig CAA yourdomain.com`. If results restrict CAs, add a CAA record permitting `letsencrypt.org` or remove the restrictive records entirely.

What if my domain previously hosted a different site and now base44 won't take it?

Cached certificate authority records and DNSSEC state from the prior host can interfere. Run a full DNS audit: A, AAAA, CNAME, CAA, DNSSEC, DS records. Remove anything from the prior host. Wait for TTL expiry (typically 1 hour) before re-attempting. Some registrars cache aggressively and you may need to lower TTL to 300 seconds before changes propagate quickly.

Is this fix base44 will actually deliver if I file a ticket?

Sometimes, eventually. The internal verifier-reset is something only base44 staff can trigger and they can do it within hours when they engage. The catch is the support response time — see the support-nonexistent-tickets-ignored issue. File the ticket, but pursue self-serve diagnosis in parallel because you cannot afford to wait for support on a launch-blocking issue.

Should I just abandon the custom domain and use the base44 subdomain?

Only as a temporary fallback. The .base44.app subdomain hurts SEO, looks unprofessional to customers, and binds you tighter to the platform. Push through to the custom domain even if it takes 48 hours. If you cannot resolve in 72 hours, that's a signal worth treating as a structural reason to evaluate migration off the platform.

Base44 Custom Domain Stuck in DNS-Pending State

What's happening

You added your custom domain in the base44 settings panel. You set the DNS records exactly as base44 instructed: A record pointing to base44's IP or a CNAME pointing to your .base44.app subdomain. The dashboard shows a "pending" status badge. An hour passes. Three hours pass. The next morning the badge still says pending. Your launch is blocked.

Visiting the domain returns either a generic "site not found" error, a base44-branded "domain not yet verified" page, or worse — an SSL error that screams to anyone who clicks the link that the site is broken. Customers, investors, and your launch announcement audience all see something that is not your app.

Base44's documentation suggests "wait a few hours for DNS propagation" but global DNS typically settles in under an hour. If the badge is still pending past two hours, propagation is not your problem. Something deeper is stuck.

Why this happens

Custom domain provisioning on base44 is a multi-step handshake that is not visible to the user. There are five things that have to succeed and any one of them silently fails.

Step 1: DNS records resolve. Base44 looks up the A or CNAME record from its servers' resolver. If the record has not propagated to base44's resolver chain (which may differ from the resolver your validation tool uses), the platform never sees the change.

Step 2: DNS records point at the right target. A and CNAME records must match base44's documented values exactly. A typo, an extra subdomain prefix, or pointing at a stale IP from base44's old infrastructure all fail silently — the domain technically resolves but to nowhere useful.

Step 3: CAA records permit Let's Encrypt. CAA (Certification Authority Authorization) records on your domain tell CAs whether they can issue. If your domain inherited CAA records from a prior provider that restrict issuance to a non-Let's-Encrypt CA, base44's certificate request gets blocked. The base44 UI does not surface this — it just says pending.

Step 4: Let's Encrypt issues the certificate. Once base44 verifies DNS and CAA, it requests a certificate from Let's Encrypt. Issuance is fast (30 seconds typically) but can rate-limit if your domain has triggered too many failed requests in the past week. The rate limit is silent on the base44 side.

Step 5: Certificate is installed and routing activates. Base44 deploys the cert to its edge servers. Cache propagation across edge nodes can take 5–10 minutes. Until it completes, requests hit nodes without the cert and return SSL errors.

A failure at any step leaves the UI in pending state. Base44 does not surface which step failed. The verifier itself sometimes hangs on a single failed check and stops retrying — only support staff can trigger a manual reset, which is where the support-nonexistent-tickets-ignored problem becomes a launch-blocker.

The deeper cause is that base44's domain UX was built for the happy path and not for failure-state diagnosis. Compare to Vercel or Netlify, both of which surface specific error messages per step (DNS not found, CAA blocking, rate limit) so users self-diagnose. Base44 returns one badge, "pending."

Source: docs.base44.com Custom Domains section; Let's Encrypt rate-limit documentation; feedback.base44.com domain-related threads; multiple G2 reviews citing stuck verification.

How to reproduce

You are reading this because it failed for you. To verify the failure is real and not transient propagation:

Run dig +short A yourdomain.com and dig +short CNAME yourdomain.com from your local machine. Confirm the records match base44's documented target.
Run dig +short A yourdomain.com @8.8.8.8 (Google DNS) and dig +short A yourdomain.com @1.1.1.1 (Cloudflare DNS). Confirm consistency.
Visit https://www.whatsmydns.net/ and check propagation across global locations. Confirm at least 80% green.
Run dig CAA yourdomain.com. Confirm there are no restrictive CAA records, or that Let's Encrypt is permitted.
Visit your domain in an incognito window. Note the exact error message.
If steps 1–4 all look healthy and step 5 still errors, the failure is on base44's side.

Step-by-step fix

Six diagnostic and remediation steps in order.

1. Validate DNS from multiple resolvers

Run dig against your default resolver, Google (8.8.8.8), and Cloudflare (1.1.1.1). All three should return the same target. If they disagree, propagation is incomplete — wait 30 minutes and retry.

2. Check CAA records

dig CAA yourdomain.com

If output is empty, you are fine — any CA can issue. If output restricts to specific CAs that do not include Let's Encrypt, you must either add a permissive record or remove the restrictive ones.

To explicitly permit Let's Encrypt, add a CAA record at your DNS provider:

yourdomain.com. CAA 0 issue "letsencrypt.org"

3. Check Let's Encrypt rate-limit status

If you have been re-attempting verification many times in the past week, you may have triggered Let's Encrypt's per-domain or per-account rate limit. Visit https://crt.sh/?q=yourdomain.com and count recent issuance attempts. If you see 5+ in 7 days, you need to wait out the rate limit (typically 1 week from the first failure).

4. Re-trigger base44 verification

In base44's domain settings, remove the domain entirely. Wait 5 minutes. Re-add the domain. This forces base44's verifier to start from a clean state. About 50% of "stuck pending" cases resolve here.

5. File a base44 support ticket and escalate publicly

If steps 1–4 all check out and the domain is still pending after 24 hours, base44's verifier is stuck on its end. File a ticket with:

Your domain name
Timestamps of all your verification attempts
Output of dig commands proving DNS is correct
Output of CAA check proving Let's Encrypt is permitted

In parallel, post a clear summary on feedback.base44.com and tag base44 on Twitter/X. Public escalation accelerates triage — see support-nonexistent-tickets-ignored for the full playbook.

6. Use the .base44.app subdomain temporarily

While verification is stuck, point your traffic at the base44 subdomain. Update any external references — analytics, ad pixels, Stripe webhook URLs — to use the temporary subdomain. Switch back when the custom domain activates. Plan for ~2 hours of update work on each side of the cutover.

DIY vs hire decision

DIY is realistic for most builders. The diagnostic skills required are basic DNS and command-line tools — dig, reading CAA output, navigating registrar UIs. If your team has shipped a custom domain on any other platform before, you can run this playbook.

Hire if any of these apply:

The domain is critical for a launch happening this week and you cannot afford guessing.
You inherited a domain with complex prior DNS state (DNSSEC, multi-CAA, custom NS) and do not know what to remove.
The base44 ticket has been open more than 48 hours and you need someone to coordinate the public escalation.

For most teams this is a 1–3 hour DIY exercise.

Need this fix shipped this week?

We treat domain-stuck-pending as a fix-sprint emergency for launch-blocked teams. Standard scope: full DNS audit, CAA cleanup, base44 verifier reset request with escalation, plus a fallback subdomain plan if verification cannot be unblocked in 24 hours.

Book a fix sprint — fastest turnaround when launch is on the line.

CSR makes apps invisible to Google — once the domain works, you still need to fix SEO before the domain has any value.
No schema markup or dynamic meta tags — same root SEO concern, different layer.
Support tickets sit ignored — the official escalation path you cannot rely on alone.