8 min readFeatures

Custom Domain TLS for Short Links: Setup in 5 Minutes

Custom domain TLS on Elido: add one TXT and one CNAME record, and the certificate is issued on first use. What each step does and what breaks if it fails.

Marius Voß
DevRel · edge infra

Setting up a custom domain with HTTPS takes one TXT record, one CNAME record and a short wait. You add the hostname in Elido, copy two DNS values it gives you, and the TLS certificate is issued automatically the first time someone opens a link on that domain. The slow part is DNS propagation, which you control with the TTL. This post walks through the five steps, then explains the machinery so you know where to look when a step stalls.

Everything below was checked against the current Elido code and dashboard on 2026-10-09. Where a related feature is not built yet, the post says so.

A short link is a redirect, and the redirect response is the whole payload. A 301 or 302 with a Location header carries your destination URL. If the first request travels over plain HTTP, anyone on the network path can read that destination before the browser follows it.

QR codes make this worse. Someone scanning a code in a shop window or on a poster has no prior relationship with the URL, so the address bar is the only trust signal they get. A browser warning on scan is the worst possible first impression, and you have already paid for the print run.

On the shared Elido short domains the certificate belongs to Elido, so the padlock is real but the name on it is not yours. On go.acme.com the name is yours. For the DNS and TLS fundamentals behind this, see the cornerstone post on custom domain short links.

The Elido custom domains list showing one active domain, one pending DNS check, and one failed verification with a fix hint

Step 1: pick the hostname

Choose a short subdomain you control and do not use for anything else: go.example.com, links.example.com or similar. The prefix appears in every link you send, so shorter is better.

Use a subdomain, not the bare root. RFC 1034 section 3.6.2 says a name with a CNAME cannot hold other data, and the root of a zone always holds SOA and NS records, so a CNAME there is not allowed. Some DNS providers fake it with ALIAS or flattened records, but those answer with IP addresses instead of a CNAME. Elido's verification asks for the CNAME itself, so a flattened root will not pass.

Two more rules apply when you register the name. The hostname must be a lowercase fully qualified domain name, and names under elido.me or elido.app are reserved.

Step 2: add the domain in Elido

Open Domains in the dashboard sidebar, type the hostname, and click Add domain. Tick the wildcard box only if you want every subdomain of that name to work, as in *.go.example.com. Usually you don't. Elido then shows the two DNS records with a copy button next to each.

The Domains page of the Elido dashboard with a hostname field, a wildcard checkbox, an Add domain button, and a table listing one domain with its status and 30-day clicks

The same step through the API, for onboarding scripts or client workspaces:

curl -X POST https://api.elido.app/v1/workspaces/{workspace_id}/domains \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"hostname": "go.example.com", "is_wildcard": false}'

The call needs a role that can manage domains. A new domain comes back with status pending, a verify_token, and an instructions object holding the exact record values:

{
  "domain": {
    "id": 42,
    "hostname": "go.example.com",
    "status": "pending",
    "is_wildcard": false
  },
  "instructions": {
    "txt_record": "_elido-verify.go.example.com TXT \"verify=<token>\"",
    "cname_record": "go.example.com CNAME edge.elido.me"
  }
}

Custom domains need a paid plan. Try to register one on a Free workspace, past your plan's domain count, or on a paused or cancelled subscription and the API answers 402, which is the code I'd handle first in any onboarding script because it's the one a client hits on day one. A duplicate hostname gets 409. Agencies running many client domains should read the agency solutions page for the workspace model.

Step 3: publish the two DNS records

Add both records at your DNS provider, exactly as shown:

go.example.com                  CNAME  edge.elido.me.
_elido-verify.go.example.com    TXT    "verify=<your-token>"

The CNAME routes traffic to Elido. The TXT record proves you own the zone. Both are required, and the TXT value must match the token exactly.

For a wildcard registration the CNAME becomes *.go.example.com, while the TXT record stays at _elido-verify.go.example.com, on the parent name without the asterisk.

Set a 300 second TTL on both records if your provider allows it. Many zones default to 3600 seconds, and a long TTL is what turns a five minute job into an hour.

One provider note matters more than the rest. If you use Cloudflare, leave the CNAME as DNS-only. Cloudflare's documentation says a proxied record is answered with Cloudflare's own IP addresses instead of the record's content (accessed 2026-10-09). A proxied name therefore never returns the CNAME Elido looks for, and verification will not pass.

Step 4: wait for verification

You do not need to click anything. A background worker inside Elido's API checks every pending domain on a timer, 30 seconds by default, using Google's public resolver at 8.8.8.8. It passes the domain only when both conditions hold:

  1. The TXT record at _elido-verify.<hostname> contains exactly verify=<token>.
  2. The hostname has a CNAME that resolves to the Elido edge target.

When both pass, the status changes to verified. Poll it yourself if you are scripting the setup:

curl https://api.elido.app/v1/workspaces/{workspace_id}/domains/42 \
  -H "Authorization: Bearer $ELIDO_API_TOKEN"

To skip the wait for the next tick, send POST .../domains/42/verify. It returns 202 and moves the domain to the front of the queue. A domain that stays pending for 24 hours is marked failed with the reason "verification timeout", and the same verify call puts a failed domain back to pending so you can retry after fixing DNS.

If it stalls, query the records the same way the checker does:

dig @8.8.8.8 TXT _elido-verify.go.example.com +short
dig @8.8.8.8 CNAME go.example.com +short

The first should print "verify=<your-token>". The second should print edge.elido.me., trailing dot included.

Step 5: the first request issues the certificate

Once the status is verified, you have nothing left to do. Elido does not pre-issue certificates. The TLS layer issues one on demand, the first time a browser opens a TLS connection for your hostname.

Before it asks Let's Encrypt for anything, the edge calls an authorization check on the Elido API. The answer is yes only if the hostname is in the verified or active state, or if it falls under a verified wildcard registration. Any other answer, including an unknown name, refuses the handshake and no certificate is requested. That gate is what stops a stranger from pointing a million hostnames at Elido and burning through the certificate authority's rate limits.

When the check passes, issuance uses the HTTP-01 challenge from RFC 8555: the certificate authority asks for a token at /.well-known/acme-challenge/ on your hostname over plain HTTP, the edge answers it, and the certificate is issued and cached. The first visitor waits a moment for this. Later requests reuse the cached certificate.

On the first TLS handshake the edge asks an authorization gate; a 404 stops issuance, while a 200 for a verified domain proceeds to the Let's Encrypt HTTP-01 challenge and a cached certificate.

A practical habit: open https://go.example.com yourself right after verification, so the certificate exists before a customer or a QR scan is the first request.

Pass the domain's id as domain_id when you create a link. The link is live at https://go.example.com/<slug> straight away. The Domains page also shows 30-day clicks per hostname. The full reference, including CAA guidance, is in the custom domains guide, and the product overview is on the custom domains feature page.

What the status values mean

StatusMeaningWhat to do
pendingDomain registered, DNS not yet seenCheck the TXT and CNAME with dig
verifiedBoth records found, certificates can be issuedOpen the HTTPS URL once, then create links
failedNot verified within 24 hours, reason is on the rowFix DNS, then call the verify endpoint again
activeAccepted by the gate like verifiedNothing; treat it the same as verified

In the current build a healthy domain stays at verified. The active value exists in the data model and in the dashboard filter, and the certificate gate accepts both, but nothing moves a domain to it yet.

Common pitfalls

CAA records that exclude Let's Encrypt are the first trap. A CAA record limits which authorities may issue for a name, and it is inherited by subdomains (accessed 2026-10-09). If your zone has example.com CAA 0 issue "digicert.com", issuance for go.example.com is refused. Add go.example.com CAA 0 issue "letsencrypt.org" or widen the apex record.

A proxy or CDN in front of the CNAME is the second. Cloudflare's orange cloud is the usual one, covered in step 3. Any layer that answers DNS or HTTP on your behalf breaks both the CNAME check and the HTTP-01 challenge.

Wildcards are not wildcard certificates, either. Per the Let's Encrypt challenge documentation, HTTP-01 cannot issue wildcard certificates, and DNS-01 needs write access to your zone (accessed 2026-10-09). So a wildcard registration covers routing for every subdomain, but client1.go.example.com and client2.go.example.com each get their own certificate on first use. Let's Encrypt limits new certificates per registered domain to 50 every 7 days (accessed 2026-10-09), so onboarding hundreds of fresh subdomains in one week needs planning.

Then there's removing the CNAME later. Today the DNS check runs only while a domain is pending. Once a domain is verified, Elido does not re-check it, so a deleted CNAME shows up as failing redirects and failing certificate renewals, not as a status change or a notification. Monitor the record on your side. A periodic health check with a degraded state and a grace period is planned, not built.


Marius Voß is DevRel + edge infra at Elido. He owns the redirect path and the custom domain flow.

Frequently asked questions

How long does custom domain TLS take to set up?

Adding the domain takes a minute, publishing the two DNS records takes a few more, and then you wait for DNS to propagate. Elido checks pending domains every 30 seconds by default, so verification lands shortly after your records become visible. With a 300 second TTL that is usually minutes; with a 3600 second TTL it can take longer. The certificate is issued on the first HTTPS request to the verified hostname, not before.

Which DNS records does Elido need for a custom domain?

Two. A TXT record at _elido-verify.<your hostname> with the value verify=<token> proves you control the zone, and a CNAME from your hostname to the Elido edge target routes traffic. Elido shows both exact values the moment you add the domain, in the dashboard and in the API response, and both must be present before the domain verifies.

Can I use a root domain such as example.com for short links?

Not reliably. The DNS standard does not allow a CNAME at the zone apex, and Elido's verification looks for a real CNAME answer, so a flattened or ALIAS record that returns only IP addresses will not pass. Use a subdomain such as go.example.com or links.example.com. It is also shorter to type in every link you share.

Does Elido issue a wildcard certificate for my domain?

No. A wildcard domain registration lets every subdomain under your name be served, but each hostname gets its own certificate on its first request through the HTTP-01 challenge. Let's Encrypt only issues wildcard certificates through the DNS-01 challenge, which needs write access to your DNS zone, and Elido does not have that access. The result for visitors is the same.

Why does my domain stay in pending status?

Either the TXT value does not match the token exactly, the CNAME does not resolve to the Elido edge target, or a proxy is answering in place of your CNAME. Elido looks both records up through a public resolver, so check them with dig from outside your network. A domain that is still pending after 24 hours is marked failed with a reason, and you can request a fresh verification afterwards.

Do custom domains work on every Elido plan?

No. Free workspaces have no custom domain allowance. Paid Pro and Business plans include custom domains, and the number you can attach depends on the plan size, so check the pricing page for your tier. Adding a domain beyond your limit, or on a paused or cancelled subscription, is refused with a payment-required error.

Try Elido

Paste a URL, get a working short link

No signup. Link lives for 30 days. Sign up to keep it forever.

No signup needed. Sign up free for 50 links a month.

Try Elido

EU-hosted URL shortener with custom domains, deep analytics, and an open API. Free tier - no credit card.

Tags
custom domain tls
branded short links setup
short url https
custom domain url shortener
on-demand tls
dns cname short link

Continue reading