Troubleshooting a custom domain

1. The name does not resolve

Symptom: the browser says the site cannot be reached, or the shortener reports the domain as unverified.

Check: run dig go.example.com or use an online lookup. You should see a CNAME pointing at the shortener's target, or for a root domain an A record with the IP the shortener gave you.

Common causes: the record was added to the wrong zone, for instance at a registrar whose nameservers are no longer authoritative because the domain is hosted elsewhere; the label was typed as go.example.com inside a zone where only go was needed, producing go.example.com.example.com; or the change simply has not propagated yet. Fix the record, then wait ten minutes before retrying verification.

2. The certificate is pending

Symptom: the domain resolves and the shortener shows it as verified, but links open with a certificate warning, or the dashboard shows the certificate as pending.

Check: look at the certificate in the browser's padlock dialog. If it is issued to the shortener's own hostname rather than yours, or has expired, issuance has not completed.

Fix: on ReSlug, Short.io, Dub and Cuttly issuance is automatic and usually finishes within minutes of verification. If it has been pending for more than an hour, the cause is almost always item 3 or item 4 below. On vendors that do not automate issuance, check their documentation for the upload step.

3. A CAA record blocks issuance

Symptom: the certificate stays pending indefinitely and everything else looks correct.

Check: run dig example.com CAA and dig go.example.com CAA. If any CAA record exists and does not list the certificate authority your shortener uses, issuance is being refused. CAA is inherited down the hierarchy, so a record on the parent domain applies to the subdomain unless the subdomain has its own.

Fix: add a CAA record permitting the authority the shortener names in its documentation, or add a CAA record on the short hostname itself that permits it. Allow a few minutes for the change to propagate, then trigger verification again.

4. A CDN proxy is in the way

Symptom: the domain is on a CDN or DNS provider that offers a proxy mode, and verification fails or the certificate chain looks wrong.

What happens: with the proxy enabled, requests for your short hostname go to the CDN, not to the shortener. The shortener's automated verification therefore never sees its own challenge, and the certificate the browser sees is the CDN's, while the leg between the CDN and the shortener may be unencrypted or failing.

Fix: set the record to DNS-only, often shown as a grey cloud, so traffic goes straight to the shortener. Verify and let the certificate issue. If you later want the proxy on for other reasons, set the CDN's origin TLS mode to full with certificate validation so the second leg is encrypted and checked, and confirm the shortener supports being proxied.

5. Apex and www disagree

Symptom: exa.mp/abc works but www.exa.mp/abc does not, or the other way round.

Cause: they are different hostnames and each needs its own record and certificate. Most people only configure one.

Fix: decide which form is canonical, usually the apex for a dedicated short domain. Add a record for the other form and either connect it in the shortener as a second domain if your plan allows, or set a redirect at the DNS host from the www form to the apex. Do not publish both forms on printed material.

If it is none of those

• The domain has expired. Check the registrar; expiry breaks everything at once.
• Two records exist for the same hostname, for example a leftover A record alongside the new CNAME. Remove the stale one.
• Your office network caches DNS aggressively. Test from a phone on mobile data.
• The shortener's domain limit for your plan is reached, so the new domain was never fully added. The allowance table shows each plan's limit.

When the domain works, create one test link, confirm the padlock and the redirect, and only then set it as the default for new links.