Skip to main content

Custom Domains

By default your links are served from LinkForty's shared domain. A custom domain serves them from your own instead:

https://go.linkforty.com/summer-sale     →     https://links.example.com/summer-sale

Why It Matters

Branding is the obvious reason, but for deep links there is a second one that matters more.

Universal Links (iOS) and App Links (Android) only open your app when the link's domain is associated with your app. That association lives on a domain you control. On a shared domain, every workspace's links come from the same host — on your own domain, your app owns the association, and the association files are served automatically for you.

There is also a deliverability argument. A shared link domain accumulates whatever reputation all of its users earn. Your own domain earns only yours.

Plan Limits

PlanCustom domains
Free1
Pro5
Business15
UnlimitedUnlimited

Adding a domain beyond your plan's limit is rejected until you remove one or upgrade.

Who Can Manage Domains

ActionRequired role
View the domain listAny member with settings access
Add, verify, remove, or set a defaultOwner

This is stricter than most settings in LinkForty. A custom domain changes where every existing link resolves, so it is deliberately limited to workspace owners.

Adding a Domain

Step 1: Open the domains settings

Go to Settings → Custom Domains.

Step 2: Add the domain

Click Add Domain and enter the hostname on its own — no protocol, no path, no trailing slash:

links.example.com
Use a subdomain

Point a subdomain such as links. or go. at LinkForty rather than your root domain. A root domain usually already serves your website, and a CNAME on it will collide with that.

Step 3: Add the CNAME record

When the domain is accepted, the dashboard shows the exact DNS record to create. Add it at whatever DNS provider hosts the domain — Cloudflare, Route 53, Namecheap, and so on:

TypeNameValue
CNAMEthe subdomain, e.g. linksthe fallback origin shown in the dashboard
No TXT record needed

LinkForty verifies ownership over HTTP, not DNS TXT. The CNAME is the only record you create. Once it resolves, verification and SSL issuance both happen on their own.

Step 4: Verify

Click Verify on the domain. It becomes usable only when both ownership and the SSL certificate are active — the dashboard reports which of the two is still outstanding.

Most domains finish in 5–15 minutes. DNS can take up to 24 hours to propagate, so a domain that is not ready immediately is normal rather than broken. Click Verify again after a few minutes.

Setting a Default Domain

Once a domain is verified you can mark it as the workspace default, and new links use it automatically.

A domain must finish verification before it can become the default — this prevents pointing new links at a hostname that does not resolve yet. Setting a new default clears the previous one; exactly one domain is the default at a time.

The default is not a lock. Any individual link can be issued on any verified domain in the workspace, chosen when you create or edit the link.

This is what makes several domains per plan useful — a campaign domain, a support domain, and a product domain can all live in one workspace and appear in analytics together.

Short codes are immutable, domains are not

Moving a link to a different domain changes the URL you hand out. Anything already printed, posted, or emailed keeps pointing at the old hostname, and it will keep resolving only while that domain remains on the workspace.

Your apple-app-site-association and assetlinks.json files are served automatically on every custom domain you add. You do not upload or host them yourself.

They are generated per host from your workspace's App Configuration, so that has to be filled in first:

PlatformRequired in Settings → App Configuration
iOSTeam ID and Bundle ID
AndroidPackage name and SHA-256 signing fingerprints

If those values are missing, the association file returns 404 on your domain and the OS silently declines to open your app — the link falls back to the browser with no error anywhere. If deep links open the web page instead of the app, check this first.

You also need the domain listed in your app:

  • iOS — add applinks:links.example.com to the Associated Domains entitlement.
  • Android — add an intent filter for the host and make sure the signing fingerprint matches the one in App Configuration.

Removing a Domain

Removing a domain releases it from LinkForty and from Cloudflare.

Links on that domain stop resolving

Every link issued on a removed domain breaks immediately. The links still exist in your workspace with their click history intact, but the hostname no longer routes. Move them to another domain before removing one that is in use.

You can also delete the CNAME record at your DNS provider afterwards; leaving it in place simply points at a host that no longer recognises your domain.

Troubleshooting

"We can't see your DNS record yet"

The CNAME has not propagated, or it is not pointing where LinkForty expects.

  • Confirm the record type is CNAME, not A.
  • Confirm the value matches the fallback origin shown in the dashboard exactly.
  • Check propagation with dig links.example.com CNAME +short — if it returns nothing, your provider has not published it yet.
  • If your DNS provider is Cloudflare, set the record to DNS only (grey cloud). An orange-cloud proxied record hides the CNAME behind Cloudflare's own proxy and verification cannot see it.

The certificate is still being issued

Ownership is confirmed and only SSL remains. This normally completes within 15 minutes. Nothing to do but retry.

"That domain is already registered"

The domain is attached to a workspace already — possibly one of your own. Remove it there first. If you believe it is registered to someone else in error, contact support; for privacy reasons the error does not say which workspace holds it.

"This domain cannot be verified automatically"

The domain has reached a state that a retry will not clear. Remove it and add it again. If it returns to the same state, contact support.

The SSL certificate is no longer valid

Certificates renew automatically, so this normally means the domain drifted out of a valid state. Remove the domain and add it again to request a fresh certificate.

Almost always missing App Configuration — see Universal Links and App Links above. Confirm the association file is actually served:

curl -s https://links.example.com/.well-known/apple-app-site-association
curl -s https://links.example.com/.well-known/assetlinks.json

A 404 from either means the corresponding platform is not configured in your workspace.

Self-Hosted Deployments

This page describes LinkForty Cloud, where custom hostnames are provisioned for you. A self-hosted deployment points customers at its own service domain and needs its own Cloudflare for SaaS configuration — see Self-Hosting and Environment Variables.