Should I use a subdomain or my apex domain for branded links?

A subdomain such as links.example.com. The apex cannot take a CNAME under RFC 1034, so it needs A records or a proprietary ALIAS type, and it is usually already serving your website. A subdomain can be repointed independently, gets its own certificate and its own association files, and keeps link infrastructure separate from the site.

Why can't I use a CNAME on my apex domain?

Because a CNAME must be the only record at its name, and the apex necessarily carries SOA and NS records. Some DNS providers offer ALIAS or ANAME records that resolve a hostname and answer with A records to work around this, but support is not universal and behaviour differs between providers. Using a subdomain avoids the question entirely.

Does a branded link domain need its own apple-app-site-association file?

Yes. iOS associations are per host, so links.example.com needs its own file and its own applinks entry in the entitlement even if example.com is already configured. Most link providers host the file for you on the branded host; check its contents after setup, because their default path rules may route more URLs into the app than you intended.

Why did my branded domain's SSL certificate fail to issue?

The three usual causes are DNS not yet pointing at the provider, /.well-known/acme-challenge blocked by a forced HTTPS redirect or a WAF, and a CAA record on the root domain that does not permit the issuing authority. A proxying CDN in front of the host also intercepts the validation. Check with dig +short CAA and by requesting the challenge path over plain HTTP.

What happens to existing links if I switch link providers?

On a domain you own, you repoint DNS and rebuild the redirect mappings, and every published link keeps resolving. On a provider's shared domain the links belong to the provider and stop working when your account ends, which takes printed QR codes, live ad creatives and every link in previously sent email with them.

Glossary/Implementation artifacts

Branded Link Domain

Definition

A branded link domain is a domain or subdomain you own that is used to serve your short links and deep links instead of a link provider's shared domain.

The marketing argument for one is recognisability. The engineering argument is stronger: a shared link domain is a shared reputation, a shared AASA file, and a single point at which every link you have ever published can stop working. Setting one up is mostly DNS, and the parts that go wrong are the same three every time.

Why it is not only branding

Shared provider domain versus a domain you control.
	Shared domain	Branded domain
Reputation	Shared with every other customer, including spammers	Yours alone
Blocklisting risk	Another customer's abuse can get the domain filtered	Only your own behaviour affects it
Association file	Provider's AASA lists many apps	Your file, your App IDs, your path rules
Portability	Links die if you change provider	Repoint DNS; links keep working
Click-through rate	Lower on unrecognised domains	Measurably higher on a known one
Email deliverability	Shortener domains are a common spam signal	A domain aligned with your sending domain
Setup cost	None	DNS records plus certificate issuance

Portability is the underrated one

Links on a provider's domain are the provider's asset. Every QR code you printed, every link in an email sent last year, and every ad creative in flight stops resolving on the day you migrate. On a domain you own, migration is a DNS change and the links survive — which is exactly the lesson Firebase Dynamic Links taught a generation of apps.

The DNS, and the apex trap

Providers ask for a CNAME because it lets them change infrastructure without asking you to change records. CNAME is also the record you cannot use on an apex domain, and that is where most setups stall.

Which record to use, by host.
Host	Record	Notes
`links.example.com`	`CNAME` → provider hostname	The normal case. Recommended
`go.example.com`	`CNAME` → provider hostname	Same
`example.com` (apex)	`A`/`AAAA`, or `ALIAS`/`ANAME` if your DNS host offers it	A `CNAME` at the apex is invalid per RFC 1034
Apex already serving your website	Not usable for links	Two services cannot both own the apex

Verify the records resolve as intended

# The CNAME chain, all the way to an address
dig +short CNAME links.example.com
dig +short links.example.com

# Certificate: issuer, subject and validity
echo | openssl s_client -connect links.example.com:443 \
  -servername links.example.com 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

# CAA records: these can silently block issuance
dig +short CAA example.com

Use a subdomain, not the apex

The apex is where your website lives, where your email records live, and where a CNAME is not allowed. Putting links on links.example.com keeps link infrastructure independently repointable, avoids ALIAS support questions entirely, and lets the link domain have its own AASA file without touching the one on your main site.

Certificates and the checks that stall them

Providers issue a certificate for your host automatically, almost always over ACME. Issuance needs two things that are easy to break by accident.

The DNS record must already point at the provider, so validation reaches them and not you.
/.well-known/acme-challenge/ on that host must be reachable over plain HTTP — a forced HTTPS redirect at the edge, or a WAF challenge page, blocks the check.
A CAA record on example.com, if present, must permit the issuing authority. An old CAA naming a former certificate vendor blocks every new issuance and reports nothing.
Renewal repeats all of the above every 60 to 90 days, so a rule added months later breaks a working setup at renewal time.

Cloudflare proxying is the classic stall

Leaving the orange cloud on for the link host means Cloudflare terminates TLS and answers the ACME challenge, so the provider's validation never reaches its own server. Set the record to DNS-only for the link subdomain, or use the provider's documented Cloudflare path.

What changes for deep linking

A branded link domain is a host, and every host that routes links into your app needs its own association files and its own entitlement entry. Missing this is why a new link domain opens Safari while the old one still works.

The per-host checklist for a link domain.
Item	Where	Notes
`applinks:links.example.com`	iOS entitlement	Subdomains are not inherited from the apex
`apple-app-site-association`	`https://links.example.com/.well-known/`	Usually hosted by the provider on your behalf
`assetlinks.json`	Same host, same directory	Must carry your package name and app signing fingerprint
`<data android:host="links.example.com">`	Android manifest	Inside the `autoVerify` filter
Verification re-run	`pm verify-app-links --re-verify`	A new host is verified independently of existing ones

Confirm the new host is fully wired

# Both association files, on the new host, with no redirect
curl -sSIL https://links.example.com/.well-known/apple-app-site-association
curl -sSIL https://links.example.com/.well-known/assetlinks.json

# The AASA copy Apple's CDN actually holds for this host
curl -sS https://app-site-association.cdn-apple.com/a/v1/links.example.com

# Android verification state for the new host
adb shell pm get-app-links com.example.shop

One more thing changes: if the provider hosts the AASA file for you, its components rules are theirs, not yours. Read the file after setup and confirm it matches the paths you intend to route — a provider default of "/": "*" will send every URL on the host into the app, including ones you wanted to stay on the web.

Deep link debugger

Point it at your new link host and it fetches both association files from that exact hostname, checks the redirect chain and content type, and reports whether iOS and Android would accept them — the check that catches a branded domain wired for DNS but not for deep linking.

Open the deep link debugger →

Frequently asked questions

Should I use a subdomain or my apex domain for branded links?: A subdomain such as links.example.com. The apex cannot take a CNAME under RFC 1034, so it needs A records or a proprietary ALIAS type, and it is usually already serving your website. A subdomain can be repointed independently, gets its own certificate and its own association files, and keeps link infrastructure separate from the site.
Why can't I use a CNAME on my apex domain?: Because a CNAME must be the only record at its name, and the apex necessarily carries SOA and NS records. Some DNS providers offer ALIAS or ANAME records that resolve a hostname and answer with A records to work around this, but support is not universal and behaviour differs between providers. Using a subdomain avoids the question entirely.
Does a branded link domain need its own apple-app-site-association file?: Yes. iOS associations are per host, so links.example.com needs its own file and its own applinks entry in the entitlement even if example.com is already configured. Most link providers host the file for you on the branded host; check its contents after setup, because their default path rules may route more URLs into the app than you intended.
Why did my branded domain's SSL certificate fail to issue?: The three usual causes are DNS not yet pointing at the provider, /.well-known/acme-challenge blocked by a forced HTTPS redirect or a WAF, and a CAA record on the root domain that does not permit the issuing authority. A proxying CDN in front of the host also intercepts the validation. Check with dig +short CAA and by requesting the challenge path over plain HTTP.
What happens to existing links if I switch link providers?: On a domain you own, you repoint DNS and rebuild the redirect mappings, and every published link keeps resolving. On a provider's shared domain the links belong to the provider and stop working when your account ends, which takes printed QR codes, live ad creatives and every link in previously sent email with them.

Related terms

/.well-known/ Directory — The /.well-known/ directory is a reserved path at the root of a domain, defined by RFC 8615, where services publish machine-readable metadata files at standardised URLs.
Associated Domain — An Associated Domain is an entry in an iOS app's com.apple.developer.associated-domains entitlement that declares a domain the app is bound to for a named service, such as Universal Links or shared web credentials.
Apple App Site Association (AASA) — The apple-app-site-association file is a JSON document hosted at a domain's /.well-known/ path that tells iOS which app is allowed to handle which URLs on that domain.
Migrating off Firebase Dynamic Links — Migrating off Firebase Dynamic Links means replacing the link generation, the hosting domain, and the SDK integration of a service that was shut down on 25 August 2025, after which page.link URLs stopped resolving.