Check these first
Sixty seconds, no AI. Most people are fixed by one of these and never need the prompt below.
- 1
Look the domain up on ICANN Lookup and read the Domain Status field. This is the registry's view, and it is the only one that counts. Thirty seconds, and it usually ends the investigation.
- 2
If the status says
clientHoldorserverHold, that is your answer. ICANN's own words: the code "tells your domain's registry to not activate your domain in the DNS and as a consequence, it will not resolve." No DNS record, nameserver change or redeploy works around it. - 3
Check the nameservers in that same lookup. If they have been swapped for something that looks like a verification or parking service, the registrar has suspended you — validation failures are often enforced by repointing the nameservers rather than by a hold code.
- 4
Look at the registration date, then count. ICANN gives 15 days from registration, or from any change to the registrant name or email, to validate. A domain that "worked for about two weeks" then stopped is the exact shape of a day-15 suspension.
- 5
Search every mailbox for the verification email — spam and aliases included. It goes to the registrant address on the WHOIS record, which is not necessarily the one you signed up to Base44 with. That mismatch is why people are certain it never arrived.
- 6
Know what the dashboard is telling you. Domains showing Active, and the Verify Domain button, describe Base44's own DNS pointing — not the registry's status. They can read fine while the registry has the domain switched off. Clicking Verify again will not clear a registry hold.
Set this in your dashboard
Nothing on this page is fixed in the Base44 dashboard, and that is the point worth internalising.
Dashboard → Domains tells you whether Base44 believes your domain is pointed at your app. It does not and cannot tell you whether the registry has your domain switched on. When those two disagree, the registry wins every time.
So the order is: fix it at the registrar first, confirm the domain resolves in a browser, and only then come back to the dashboard to check the pointing is still right. Re-clicking Verify Domain while the domain is suspended achieves nothing except making it look like you are making progress.
One thing worth doing in the dashboard once you are back up: confirm the custom domain is still set as the preferred URL, so search engines are pointed at the domain you own rather than the *.base44.app address.
Why this happens on Base44
Two systems are involved and only one of them is Base44's.
The registry and your registrar decide whether the domain exists on the internet at all. Base44 decides where the domain points once it does. A registry-level suspension switches off the first, and the second carries on reporting that everything on its side is configured correctly — which is exactly what you are looking at when the dashboard says Active and the browser says the server cannot be found. Neither is lying; they are answering different questions.
Buying the domain through a platform adds a reseller chain on top. That is why a support agent at one registrar can look up your domain and tell you it "appears to be through" a completely different company: you are several steps down a chain from whoever actually holds the registration. It does not change who the registrant is — that is still you — and it does not move ICANN's validation obligation off you either. It just means the verification email came from a company you have never heard of, which is a very good way to get an email deleted.
What this is not: an app problem. Redeploying, republishing, changing the code, rolling back a checkpoint, buying a plan — none of it touches a registry hold. If you have been trying those for a day, stop.
Then run this
Paste into your Base44 builder chat. The first one only reads — it changes nothing, so it is safe to run on a live app.
Open Base44, opens in a new tabBase44 links on this page are affiliate links. If you sign up through one, Dean may earn a commission at no extra cost to you.The diagnosis prompt — run this in any AI chat, not the builder
I have a domain that has stopped resolving. Help me work out who has to fix it. Here is what I know: DOMAIN: [your domain] BOUGHT THROUGH: [Base44 / registrar name / not sure] REGISTERED ON: [date, from ICANN Lookup] STOPPED WORKING: [date] BROWSER SAYS: [paste the exact error] ICANN LOOKUP SAYS: [paste the Domain Status line(s) verbatim] NAMESERVERS: [paste them from ICANN Lookup] PLATFORM DASHBOARD SAYS: [e.g. Active, Base44 Domain, Verify Domain initiated] VERIFICATION EMAIL: [received and clicked / never received / not sure] RULES Work only from what I pasted. Do not assume a status code I did not give you, and do not guess my registrar from the domain name. If a field above is blank or says "not sure", say what I need to look up and where, and stop there rather than reasoning past the gap. …
29 lines · 1,349 characters
The ticket-drafting prompt — run it once you know who to chase
Using the diagnosis above, draft the message I send. Write TWO versions: A — TO THE REGISTRAR Open with the domain and the exact registry status I read on ICANN Lookup. State the date it stopped resolving and whether I received the registrant validation email. Ask for exactly three things: resend the validation email and confirm which address it goes to; confirm whether a hold is in place and what is required to lift it; confirm the current nameservers on the registry record. B — TO THE PLATFORM'S SUPPORT State that the registry status shows the domain suspended at registrar level, so I am not asking them to fix DNS. Ask only what they can answer: which registrar the domain sits with, which email address the registration was made under, and whether they can escalate to that registrar on my behalf. RULES FOR BOTH …
22 lines · 1,094 characters
Run this only after you have read the audit above, and only when you are happy for it to change files.
The verification prompt — confirm it is actually back
The domain is supposed to be working again. Confirm it, do not take my word for it. CHECK, AND REPORT THE RAW RESULT FOR EACH 1. ICANN Lookup: the Domain Status line now. Is the hold gone? 2. Nameservers on the registry record: are they the ones the platform expects? 3. The domain root over HTTPS: the HTTP status code you receive. 4. www and non-www: do both resolve, and does one redirect to the other? 5. The TLS certificate: valid, and issued for this domain? 6. /robots.txt and /sitemap.xml: status code for each. For each, say PASS or FAIL and show the value you actually saw. If you cannot check something from where you are, say UNVERIFIED and tell me how to check it myself — do not report a PASS you did not observe. THEN If everything passes, tell me the two things to do now that the site is back: re-submit the sitemap in Google Search Console, and request indexing on the homepage. Nothing more — a site that has been down for days comes back on …
21 lines · 1,074 characters
An agent that reports its own work as done is not evidence. This pass re-checks from outside the change.
What this can’t fix
All of it, unfortunately. There is no prompt that clears a registry hold.
1. Get the verification email resent. Ask your registrar to resend the registrant validation email, and ask them which address it is going to. If that address is dead or wrong, updating the registrant email triggers a fresh validation — and a fresh 15-day clock.
2. Ask the registrar directly to remove the hold. Once you have validated, the hold does not always lift itself. Name the domain, the status code you read on ICANN Lookup, and the date it stopped resolving.
3. Do not start a transfer while it is on hold. A domain in clientHold generally cannot be transferred, and trying resets your attention onto the wrong problem. Fix the validation, get it resolving, then move it if you want to.
4. Rule out the boring one. Check the domain has not simply expired or failed a payment — same symptom, different fix, and the ICANN Lookup expiry date tells you in one glance.
5. Then allow for propagation. Once the hold lifts, DNS takes time to come back everywhere. Re-check from a different network before deciding it has not worked.
6. Then, and only then, worry about Google. A site that has been unreachable for days will have dropped out of results. Once it resolves again, that is an indexing job — different page.
Links you’ll need
- ICANN LookupRegistry's own view of your domain: status codes, nameservers, dates. Start here.
- ICANN — EPP status codes explainedWhat clientHold, serverHold and pendingDelete actually mean.
- ICANN domain validation requirementsThe 15-day registrant verification rule, in plain English.
- Base44 — connecting a domain to your appWhat the Domains page is and is not responsible for.
Asked in the Base44 Discord, 13 Sept 2026. Facts on this page verified 14 Sept 2026. v1. Google and Base44 both change things — if something here has gone stale, tell me.