Skip to content
AppIn

All posts

Guide

Custom domain for app links — why it is risk transfer, not vanity

A shared link domain is convenient until a platform interstitials it. Custom domains move the reputation risk onto a hostname you control. On AppIn that is a Pro feature, configured with a CNAME — not a marketing sticker.

Published By Mehmet Burak, Founder2 min readUpdated 5 September 2026

Why is a custom domain not just cosmetic?

Because a shared link domain is one reputation surface for every customer on it: if a platform flags appin.to, every AppIn link on it can be interstitialed, no matter whose it is. A custom domain moves that risk onto a hostname only you use — a problem on appin.to never touches links.yourapp.com.

appin.to is a shared link domain. That is fine for trials and low-stakes posts. It is a single reputation surface: if a platform flags the domain, every customer on it feels the interstitial. We reduce abuse with destination rules, free-tier limits, and a public report form, but we will not promise a blocklist will never happen — that decision sits with the vendor, not with us.

A custom domain is risk transfer: your bio, QR codes and ads point at links.yourapp.com (or similar). A problem on appin.to does not rewrite those addresses.

Who should use one

  • Links printed on packaging, posters, or hardware.
  • Paid acquisition where a dead day is expensive.
  • Brands that want the hostname to match the app name.

If you are still validating the product on a free plan, stay on appin.to until the link is load-bearing — then move.

What you set up

  1. Choose a hostname you control (subdomain is normal).
  2. On Pro, open custom domains in the AppIn dashboard.
  3. Create the CNAME the dashboard shows — target is cname.appin.to as the product’s Cloudflare for SaaS entry (confirm the live value in the dashboard; do not invent a second target).
  4. Wait for verification, then create or move links onto that hostname.

TLS and routing are handled once verification succeeds. You do not run your own redirect server.

What does not change

  • Device routing, listing-built pages, campaign parameters, and in-app browser handling still apply.
  • Destination rules still apply — custom domain is not a way to turn AppIn into an open shortener.
  • You still should not publish the escape technique; the domain name does not change that policy.

Pricing and limits

Custom domains are a Pro capability. Current link, click and hostname counts live on pricing — that section is the source of truth, not this article.

Questions

Why use a custom domain for app links?
Shared domains can be blocked or interstitialed inside apps. Links on a domain you own are not tied to every other customer’s traffic.
Which AppIn plan includes custom domains?
Pro. See the pricing section for current limits (including how many hostnames).
What DNS record do I need?
A CNAME from your hostname to the target AppIn documents in the dashboard (cname.appin.to). Exact values are shown at setup time.
Does a custom domain change in-app browser behaviour?
Routing and escape still run on the click. The domain change is about ownership and reputation, not a different escape method.

Facts on this page were last checked on . Competitor pricing and platform behaviour both move; check theirs before deciding.

Put load-bearing links on your domain

Upgrade to Pro, add the CNAME we show you, verify, and publish links on your hostname.

See plans