Domain not working after setup: what to check
The cause is almost always one of three things: the A record points to the wrong place, the TXT record hasn’t propagated yet, or the site has no published version. Let’s go through them in order, and see how to tell one from another without guessing.
First: what the panel says
Site page → Domains tab. Under the domain name you’ll see its state:
- Awaiting verification: the
_tuqo-verifyTXT record isn’t visible yet; - Verified · on: ownership is proven and the domain is being served;
- Verified · off: the domain is yours, but its toggle is off, so the site won’t open on it;
- · A record points elsewhere: the domain is verified, but traffic goes to someone else’s server;
- · HTTPS / · HTTPS not issued / · HTTPS not checked: the certificate state.
The key point is the split: only the TXT record proves ownership. The A record has no effect on the “verified” status at all. It answers a different question: “will the site open?” That’s why you can end up with “domain verified, site doesn’t open”: the TXT is right, the A record has a typo.
Cause 1. The A record doesn’t point to Tuqo
You need an A record with the value 201.51.6.16 and the name @ (the root of the
domain). The exact value is always shown on the domain card in the panel; go by that.
Check from your machine:
dig +short mysite.com A
# should be exactly: 201.51.6.16
On Windows:
nslookup -type=A mysite.com
Two common mistakes:
- an old A record is still there from the previous host. The check treats the setup as working only if all A records point to Tuqo: with “our address plus someone else’s”, browsers hit the other one in about half of visits, and the site “opens every other time”. Delete the extra records; don’t just add ours next to them;
- a CNAME instead of an A record. The DNS standard doesn’t allow a CNAME at the root of a domain, and some DNS panels silently ignore it. For the root, use an A record only.
Once fixed, click Check again on the domain card: the panel resolves the record again and shows what it sees now.
Cause 2. The TXT record hasn’t propagated
The record name is exactly _tuqo-verify (most DNS panels append the domain
themselves), and the value is the token from the domain card. If your provider wants the
full name, enter _tuqo-verify.mysite.com.
dig +short _tuqo-verify.mysite.com TXT
The answer should contain the same token as the panel, in quotes. An empty answer means
the record hasn’t propagated yet or was saved in the wrong place. A common mistake is to
enter _tuqo-verify.mysite.com in the name field of a panel that already appends the
domain, which produces _tuqo-verify.mysite.com.mysite.com.
Cause 3. DNS simply hasn’t updated yet
The usual delay is from a few minutes to an hour. It takes longer in two cases:
- the domain was registered or delegated today. While the new NS records spread across the internet, the records can be correct but invisible. This can take up to a day, longer for some zones;
- the old record had a long TTL. If the previous A record had a TTL of 86400, resolver caches will hold it for a day. Next time you move a site, lower the TTL to 300 seconds a day before changing the records.
You can flush the cache on your own machine, but it makes no difference to the panel, which resolves from its side:
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
Tuqo checks records through a chain of public resolvers: Yandex first, then Cloudflare and Google. So “it already opens in my browser, but the panel doesn’t see it” is a normal difference between caches, not a fault. Wait, then click Check again.
Cause 4. www is a separate domain
mysite.com and www.mysite.com are different names. For both to work, add www as a
separate domain in the panel and create its own records: an A record with the same
address (or a CNAME www → mysite.com) plus a TXT record _tuqo-verify.www with its own
token. Every enabled domain takes a slot on your plan: 10 on Start, 20 on Pro, unlimited
on Business and above.
Cause 5. The domain is fine, but there’s no site
Only verified and enabled domains of a site with a published version are served. If the site exists but no deploy has been activated, nothing opens on the domain: publish a version first. The same goes for a disabled toggle on the domain or on the site itself: then visitors see a placeholder page or a redirect to another of your addresses (see redirect from the subdomain).
One more case is the plan. Custom domains work from the Start plan (590 ₽/month) or with the Custom domain add-on (149 ₽/month per domain, also available on the Free plan). If a payment lapses, domains are not deleted but switched off; after you pay, you turn them back on with the toggle, with no need to verify again. Approximate dollar and euro prices are on the pricing page.
Cause 6. The site opens, but the browser complains about HTTPS
The certificate is issued automatically on the first request to the domain. Usually it takes seconds, sometimes a couple of minutes. While the A record points elsewhere, the certificate can’t be issued at all: the request never reaches Tuqo.
The domain card has a Check HTTPS button: the panel opens your site on your domain itself and shows the result — issued, still being issued, or failed with the reason. SSL is free on every plan and renews on its own; more in the guide on free SSL.
An old AAAA record from the previous host
Tuqo has no IPv6 address, and many hosts keep an AAAA record with theirs on the domain. A browser on an IPv6 connection will follow it, and the site will open every other time with no visible pattern. Check for AAAA records and delete all of them:
dig +short mysite.com AAAA # should be empty
Using Cloudflare?
With the orange cloud (Proxied) on, the panel sees Cloudflare’s addresses instead of ours and the certificate can’t be issued. Switch the records to DNS only; details in the Cloudflare guide.
FAQ
The panel says “verified”, but the site still doesn’t open
Then the TXT record is correct and the A record is not. Look for the “A record points elsewhere” warning and the text below it: it says where the record points now and which value it should have. Fix it at your registrar and click Check again.
How long should I wait before assuming something is broken?
An hour for an existing domain, a day for a freshly registered or delegated one. If dig
on your machine already shows the right values but the panel hasn’t seen them for over an
hour, contact support and attach the dig output.
I fixed everything, but the browser still shows the old site
That’s caching: in DNS, in the browser and sometimes at your ISP. Check in a private window and on another network (mobile data, for example). If it opens correctly there, all that’s left is to wait for the TTL to expire.
Do I need to change anything when the site moves to another account?
No. The domain moves with the site and stays verified, so there’s no need to touch DNS. See how to hand over a site to a client.