Step-by-step diagnosis for the most common custom domain problems in UniLink — from "domain not connected" errors to SSL not provisioning — with tools and fixes for each scenario.
You followed the steps, added the DNS record, and came back to UniLink — but the Dashboard still shows "Domain not connected" or the SSL badge is missing. This is one of the most common frustrations when setting up a custom domain, and the good news is that almost every case has a clear root cause and a straightforward fix. This guide walks through every likely cause in order of frequency, with exact commands to diagnose what is happening on your end.
What Happens When You Connect a Domain in UniLink
When you enter a custom domain in UniLink's settings, the platform begins polling your DNS records to verify that you have pointed the domain at UniLink's servers. UniLink looks for a specific CNAME or A record matching the value it displayed to you. Only after it detects the correct DNS record does it begin provisioning the SSL certificate for your domain.
SSL provisioning requires a domain validation challenge — UniLink's SSL provider (typically Let's Encrypt) makes an HTTP request to your domain to verify ownership. If your DNS is still propagating, if the wrong record type is set, or if a proxy layer intercepts the validation request, the certificate cannot be issued. This is why "domain not connected" and "SSL not provisioned" are often the same underlying problem seen at different stages.
UniLink re-checks your DNS approximately every 15 minutes. You do not need to manually trigger a recheck — but you can use the "Retry" button in the Dashboard if you want to force an immediate check after making a DNS change.
How to Diagnose Your Domain Issue Step by Step
- Copy the exact DNS values UniLink gave you — go to Settings → Custom Domain and note the record type (CNAME or A), the host name (e.g., "www" or "@"), and the value (e.g., "your-handle.unil.ink" or an IP address).
- Log in to your DNS provider and verify the record — compare what is currently saved with what UniLink specified. Check for typos, extra spaces, or a missing trailing dot if your provider requires one.
- Use dig to check current resolution from outside your network — run
dig www.yourdomain.com CNAMEin a terminal (Mac/Linux) or use an online tool like dnschecker.org to see what DNS resolvers worldwide currently see. - Check if propagation is still in progress — if dig returns the correct value from most locations but a few still show the old record, propagation is still in progress. Wait and check again in 30 minutes.
- Check for conflicting records — in your DNS provider, look for any existing A, CNAME, or AAAA records on the same hostname. A CNAME cannot coexist with any other record type on the same host.
- Check Cloudflare proxy status — if your domain is on Cloudflare, verify whether the DNS record has the orange cloud (proxied) or grey cloud (DNS only) icon. Switch to grey cloud temporarily if SSL is not provisioning.
- Return to UniLink and click Retry — after confirming DNS is correct and propagated, click the retry/recheck button in the Dashboard to trigger an immediate verification attempt.
How to Use dig and nslookup to Verify DNS
- On Mac or Linux, open Terminal — the dig command is built in. On Windows, use Command Prompt with nslookup, or install the Windows Subsystem for Linux to use dig.
- Check a CNAME record — run
dig www.yourdomain.com CNAME +short. The output should match the CNAME target UniLink gave you exactly. - Check an A record — run
dig yourdomain.com A +short. The output should be the IP address UniLink specified. - Use nslookup on Windows — run
nslookup -type=CNAME www.yourdomain.comornslookup -type=A yourdomain.com. Look for the "canonical name" or "Address" line in the output. - Use dnschecker.org for a global view — paste your domain into the site and select the record type to see resolution status from 30+ global locations simultaneously. This shows whether propagation is complete worldwide or only partially done.
- Compare dig output to UniLink's required value — if dig returns nothing, the record is not set or is using the wrong record type. If it returns a different value, there is a conflicting or old record still active.
- Test SSL certificate issuance — once DNS looks correct, run
curl -I https://www.yourdomain.comto check whether HTTPS is responding. A successful response with a 200 or 301 status means SSL is working.
Key Settings Explained
| Setting | What it controls | Best practice |
|---|---|---|
| CNAME record value | The hostname your subdomain resolves to. Must match exactly what UniLink provided — including whether a trailing dot is expected. | Copy-paste from UniLink's Dashboard rather than typing manually. Some DNS providers require or prohibit a trailing dot — follow your provider's convention. |
| A record value | The IP address your root domain resolves to. Used when CNAME is not available for the apex domain. | Use only the IP UniLink specifies. Do not use a generic hosting IP or a previous registrar's parking IP. |
| TTL (Time to Live) | How long DNS resolvers cache your record before checking for updates. Lower TTL = faster propagation of future changes. | Set TTL to 300 (5 minutes) before making DNS changes so propagation is faster. After changes are confirmed, you can raise it back to 3600. |
| Cloudflare proxy mode | When enabled (orange cloud), Cloudflare intercepts all traffic before it reaches UniLink. This can prevent domain verification and SSL provisioning. | Disable proxy (set to grey cloud / DNS only) until UniLink confirms the domain is connected and SSL is provisioned. Re-enable proxy afterward if desired. |
| Conflicting records | Multiple records on the same hostname — e.g., an old A record that still exists when you try to add a CNAME. DNS does not allow CNAME to coexist with other record types. | Delete all existing records on the target hostname before adding the new record UniLink requires. Check for A, AAAA, and CNAME records on the same host. |
How to Resolve Each Common Problem
The "domain not connected" message usually means one of two things: either propagation is still in progress and you need to wait, or the record is incorrect. Before assuming it is a propagation delay, always verify the record in your DNS provider's control panel first. A wrong host name (typing "www.yourdomain.com" instead of just "www" in the host field, for example) will never propagate correctly — because the record itself is wrong.
SSL not provisioning almost always means that UniLink's domain verification step failed. The SSL provider sends an HTTP request to your domain as part of issuing the certificate. If your domain is pointing to Cloudflare's proxy, that request gets intercepted before reaching UniLink's infrastructure, which prevents UniLink from completing the challenge. The fix is to temporarily set the Cloudflare record to DNS-only mode. Once UniLink shows "Connected" and the SSL badge appears, you can safely re-enable Cloudflare's proxy — the certificate will remain valid.
Conflicting records are a common issue when migrating from an existing hosting provider. Your old host likely set an A record on your www subdomain pointing to their servers. If you try to add a CNAME on www without deleting the old A record first, the CNAME will either fail silently or your DNS provider will show a conflict error. Always audit the existing records on your target hostname and remove them before adding the new one.
If propagation seems stuck past 24 hours, check whether your registrar's "nameservers" still point to your DNS provider. Sometimes people change DNS providers but forget that the registrar's nameserver setting must be updated to delegate to the new provider. If your registrar is still using old nameservers, none of the records you add at the new DNS provider will ever be visible to the outside world.
Troubleshooting Common Issues
| Problem | Likely cause | Fix |
|---|---|---|
| "Domain not connected" after 48+ hours | Wrong record type, wrong host value, or nameservers at the registrar are not delegating to the DNS provider where you made the change. | Run dig to confirm what is actually resolving. Check registrar nameserver settings. Compare every field against UniLink's exact instructions and correct any mismatch. |
| SSL certificate pending indefinitely | Cloudflare proxy intercepting the SSL validation challenge, or DNS not yet fully propagated when UniLink first attempted validation. | Set Cloudflare record to DNS-only (grey cloud). Click Retry in UniLink's domain settings. Wait for UniLink to confirm connection, then re-enable proxy. |
| Domain connects but shows wrong UniLink page | The domain was previously connected to a different UniLink account or a cached DNS response is pointing to old infrastructure. | Verify the CNAME target matches your current UniLink account's provided value. Clear your local DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on Mac) and test again. |
| HTTPS shows a certificate warning | SSL was provisioned for www but you are visiting the root domain (or vice versa) without a redirect in place, or the certificate is still being issued. | Ensure you visit the exact hostname UniLink connected (e.g., www.yourdomain.com). Set up a redirect from the other version. If the certificate is still issuing, wait up to 15 minutes after DNS confirmation. |
When DNS is Correctly Configured
- UniLink shows "Connected" status within minutes of propagation completing
- SSL certificate is provisioned automatically at no extra cost
- Your UniLink page loads under your brand's domain with full HTTPS
- No ongoing maintenance required unless you change DNS providers
Common Configuration Pitfalls
- Forgetting to delete old records before adding new ones creates silent conflicts
- Cloudflare's proxy mode must be temporarily disabled during initial SSL provisioning
- Propagation can take up to 48 hours — there is no way to force it to complete faster
Frequently Asked Questions
How do I know if my DNS has finished propagating?
Use dnschecker.org or run dig www.yourdomain.com CNAME +short from a terminal. If the output matches the CNAME target UniLink gave you across all or most global locations, propagation is complete. UniLink also checks automatically every 15 minutes and updates the Dashboard status as soon as it detects the correct record.
Does UniLink support domains managed through Cloudflare?
Yes. Add your CNAME or A record in Cloudflare's DNS panel as normal. The important step is to set the record to DNS-only mode (grey cloud icon) initially, not proxied (orange cloud). Once UniLink confirms the domain is connected and SSL is issued, you can enable Cloudflare's proxy again if you want CDN and DDoS protection on top of UniLink's hosting.
I deleted the old record and added the new one — why is DNS still returning the old value?
DNS resolvers cache records based on the TTL of the record at the time it was last fetched. If the old record had a TTL of 86400 (24 hours), resolvers will continue serving the cached old value for up to 24 hours even after you delete it. There is no way to force a cache flush on external resolvers — you must wait for the TTL to expire. Lowering TTL before making future changes prevents this problem.
My domain connected successfully but now shows "Disconnected" after a few weeks — what happened?
The most common causes are: the CNAME record was accidentally deleted, the DNS provider account expired or the domain renewal lapsed, or Cloudflare's proxy was re-enabled in a way that broke UniLink's periodic health check. Log in to your DNS provider and verify the record still exists and still points to the correct value UniLink originally specified.
When should I contact UniLink support instead of troubleshooting myself?
Escalate to support if: DNS is verified as correct via dig and dnschecker.org (matching the expected value from all global locations), 48+ hours have passed since the correct record was in place, and the Dashboard still shows "Not Connected" or SSL is still pending. At that point the issue is likely on UniLink's infrastructure side rather than your DNS configuration, and the support team can investigate the specific domain.
Key Takeaways
- Always verify your DNS record matches UniLink's exact specification before assuming the issue is propagation delay — a wrong record will never propagate correctly.
- Use dig or dnschecker.org to see what your domain actually resolves to from the outside world, not just what is saved in your DNS provider's panel.
- Cloudflare's proxy (orange cloud) must be set to DNS-only during initial SSL provisioning — re-enable it after UniLink confirms the domain is connected.
- Delete all existing records on the target hostname before adding a new CNAME — conflicting records prevent correct resolution.
- If DNS is fully propagated and verified but UniLink still shows the domain as not connected after 48 hours, contact UniLink support with your domain name and a screenshot of your DNS records.
Ready to connect your custom domain to UniLink?
Follow this guide and your domain will be live with HTTPS in a matter of hours. Still stuck? Our support team is available to help.
Get Started Free