Skip to main content

Custom Domains

Every workspace has a LinkForty domain of its own — acme.toapp.me — and a custom domain serves your links from a domain you own instead:

https://acme.toapp.me/summer-sale     →     https://links.example.com/summer-sale

Why It Matters​

Branding is the main reason: links.example.com is yours, and it says so on every link you share.

Universal Links (iOS) and App Links (Android) only open your app when the link's domain is associated with your app, and the association files for that are served automatically on any host LinkForty runs for you — your LinkForty domain and every custom domain alike. So a custom domain is not required for your app to open from a link; it is required for the host to carry your name rather than ours.

One thing neither gives you: the shared go.linkforty.com host cannot carry an app association, because every workspace's links come from that same host. Workspaces created before September 2026 still use it until they switch — see below.

Your LinkForty Domain​

Every workspace has one host on toapp.me, chosen from its name when the workspace is created: Acme becomes acme.toapp.me, and if that is taken you pick from a few alternatives or type your own. You can see it, and copy it, under Settings → Domains.

  • New workspaces use it from their first link. Nothing to set up, and nothing to switch: a workspace created since labels launched has never had a link anywhere else, so it always uses its own host.
  • Existing workspaces keep go.linkforty.com until an admin switches — the same page has a Use as the default for new links toggle. Links you have already shared on go.linkforty.com keep working, and always will; switching changes the host on new links and on the URLs the dashboard and API show, nothing else.
  • The label is permanent. It is the hostname on every link you will share, so it cannot be renamed — releasing it would let another workspace take over links you have printed. Choose it as you would a domain name.
  • Your app can open links on it. The association files are served on it from your App Configuration, exactly as on a custom domain; add applinks:acme.toapp.me to your app as described below.
  • A custom domain still wins. When a verified custom domain is the workspace default, links use it; your LinkForty domain is the fallback for links with no domain of their own.
  • Its reputation is yours alone. Each label is a separate host to browsers, mail providers and network filters. A problem on another workspace's label does not touch yours.

A label that spells another company's name or reads like a sign-in page is refused.

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.

Some links should always open your website, even for people who have your app installed: a newsletter pointing at a blog post, or an email linking to a podcast page. Put those links on a domain reserved for web links.

  1. Add a custom domain for them, for example links.example.com, and verify it as above.
  2. Under Settings → Domains, check For web links on that domain (owners only).
  3. When you create a link, pick that domain in the Domain field. It's labeled (web links).

Every link on a web-links domain:

  • Opens your website on every device and OS version, starting immediately
  • Goes to the link's web fallback URL (link, then template, then workspace), with its UTM parameters
  • Never opens your app, shows the Launchpad page, or sends visitors to an app store

LinkForty serves no association files on a web-links domain, so iOS and Android never hand its links to your app, even if the domain is later added to your app by mistake.

The same link still behaves as an app link on your other domains: what decides is the domain in the URL you share. A web-links domain can be your workspace default. If it is, new links open your website unless you pick another domain, so the dashboard asks you to confirm.

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 host listed in your app — your LinkForty domain, your custom domain, or both:

  • iOS — add applinks:acme.toapp.me (and applinks:links.example.com for a custom domain) to the Associated Domains entitlement.
  • Android — add an intent filter for each 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.