Set up a branded short domain in 15 minutes

A branded short domain is the single highest-leverage change you can make to your link strategy. The same destination URL behind qurly.dev/spring-sale and acme.li/spring-sale performs differently in click-through rate by a wide margin — most teams see between 25 and 35 percent more clicks once they switch.

This guide walks through the entire setup in about fifteen minutes of focused time. We’ll cover picking the right domain, buying it, adding it to Qurly, configuring DNS at your registrar, verifying ownership, migrating existing links, and the four gotchas that catch most teams.

Before you buy: pick the right kind of domain

The most common mistake is buying a long domain. The whole point is brevity, so optimise for that.

Three patterns work:

• Short ccTLD with a brand match — .li, .io, .co, .me, .us. If your brand is “Acme,” then acme.li, acme.io, or acme.co are all great. These TLDs cost $10-30/year.
• A short alias of your main domain — if you own acme.com, register acm.li or acmeco.de as an alias. Slightly less polished but cheap and you already control the brand.
• A .link or .click — purpose-built link TLDs (acme.link, acme.click) cost $5-15/year. They scream “this is a short link” which is good (trust) and bad (slightly less elegant).

Avoid:

• Domains with hyphens (acme-co.com)
• Domains longer than 8 characters before the TLD
• New TLDs your audience won’t recognise (.xyz, .online, .store — fine for some industries, suspicious for others)
• Anything that’s been used for spam or phishing — check on abuse.ch and Google Safe Browsing’s transparency report before you buy

Step 1: Buy the domain

Use any registrar — we recommend Cloudflare Registrar because they sell at registry cost (no markup), or Porkbun if you want a simple UI. For this guide we’ll use Cloudflare; the steps are nearly identical at any registrar.

Buy the domain. Don’t add any of the upsells (privacy guard is included free at most modern registrars). Wait for the registration to complete (usually instant, occasionally up to an hour for new TLDs).

Step 2: Add the domain to Qurly

In your Qurly dashboard, go to Settings → Custom domains and click Add domain.

Enter the bare domain (no https://, no path): acme.li. Choose whether the domain should be:

• Default for new links — if checked, every new link defaults to this domain. You can override per-link.
• Available to all members — if checked, every member of the org can create links on this domain. Otherwise admins-only.

Click Add. Qurly returns a verification token (a string like qurly-verify-abc123). Keep this tab open — you need it in the next step.

Step 3: Configure DNS at your registrar

This is where most people get stuck. The configuration looks scary but it’s three records.

In Cloudflare’s DNS panel for acme.li, add:

Type	Name	Content	Proxied
TXT	@	qurly-verify-abc123	(n/a)
CNAME	@	proxy.qurly.dev	DNS only
CNAME	www	proxy.qurly.dev	DNS only

Notes:

• TXT record is the verification token. Replace qurly-verify-abc123 with what Qurly showed you.
• CNAME at the apex (the @ record) — most registrars support this; some still don’t and require an A record instead. If your registrar doesn’t support apex CNAMEs (look for “CNAME flattening” in their docs), check Qurly’s apex setup section in the help center for the alternative.
• Proxied: DNS only in Cloudflare’s panel — uncheck the orange cloud. Qurly handles its own SSL termination, and proxying through Cloudflare on top of Qurly’s proxy creates a double-redirect that breaks short links. This is the single most common DNS gotcha.
• The www CNAME is optional but recommended — it catches users who type www.acme.li.

Save the records. DNS propagation usually takes 5-15 minutes, occasionally longer for new domains.

Step 4: Verify in Qurly

Back in Qurly, click Verify on your domain. Qurly checks that:

1. The TXT record contains the expected verification token
2. The CNAME points at proxy.qurly.dev
3. The proxy is reachable on the domain

If verification fails, the most common cause is DNS propagation. Wait 5 minutes and click Verify again. If it still fails after 30 minutes, see the gotchas at the bottom.

Once verified, Qurly automatically issues an SSL certificate (Let’s Encrypt). This takes another 1-3 minutes; the domain status will move from “Verifying” → “Issuing certificate” → “Active.” Your domain is now live.

Step 5: Test it

Create a test link on your new domain. The URL should look like acme.li/test-2026. Visit it in a fresh incognito window. You should be redirected to the destination URL with no warnings, no certificate errors, and no extra redirects.

If you’re seeing certificate warnings, that’s almost always either:

• DNS hasn’t fully propagated (wait another 10 minutes)
• The Cloudflare orange-cloud proxy is still on (turn it off, see step 3)

Migrating existing links

If you’ve already been using Qurly with the default domain (qurly.dev or similar) and now want existing links to use your branded domain, you have two options:

Option A: keep old links on the old domain. Easiest. Don’t migrate; just use your branded domain for new links. The old links keep working forever — they’re just less branded. Most teams pick this.

Option B: migrate. For each existing link, edit it and change the domain field to your new branded domain. Qurly creates a new short link on the branded domain pointing at the same destination and automatically sets up a redirect from the old short link to the new one, so anything in the wild keeps working.

There’s no bulk-migrate button (yet). For more than ~20 links, use the API: PATCH /v1/links/{id} with { "short_domain": "acme.li" } for each.

Four gotchas that catch most teams

1. Cloudflare orange cloud

If you registered the domain with Cloudflare, the proxy (“orange cloud”) is on by default. Qurly handles its own SSL and routing — proxying through Cloudflare creates double redirects, breaks WebSocket-based features, and sometimes serves Cloudflare’s “host not configured” page instead of your link. Click the orange cloud to turn it off (“DNS only”) before verifying.

2. Apex CNAME on legacy registrars

Some older registrars (GoDaddy, Network Solutions, some country-specific registrars) don’t support a CNAME at the apex. If your CNAME entry is rejected with “CNAME records cannot coexist with NS records,” your registrar is one of these. Switch the apex record to an A record pointing at our IP (in the help center) and use a CNAME on www.

3. CAA records blocking SSL

Some registrars set restrictive CAA records by default that prevent Let’s Encrypt from issuing a certificate. If your domain is stuck in “Issuing certificate” after 10 minutes, check whether you have CAA records and either remove them or add 0 issue "letsencrypt.org" to allow Let’s Encrypt.

4. Email DNS gets clobbered

If you also receive email at this domain, make sure your existing MX records, SPF, DKIM, and DMARC records aren’t accidentally deleted when you add the link records. The link records only touch the apex CNAME, the www CNAME, and one TXT — leave the rest alone.

Pre-flight checklist

Before going live with the branded domain on real traffic:

• Domain registered and DNS propagated (dig acme.li +short returns a Qurly IP)
• Verified in Qurly (status: Active)
• SSL certificate issued (test in a fresh incognito window)
• One test link created and confirmed redirecting cleanly
• All team members updated on the new default domain (so they don’t keep generating links on the old one)
• If migrating: existing links audited; bulk migration script run if needed

That’s it. From here on, every short link you create is branded, your CTRs lift, and your packaging / print collateral can finally use a domain that doesn’t make your audience pause.