Custom domains for QR codes — the setup

Custom domains for QR codes are the part of the build that one person on the team has done and four people on the team have heard about. The DNS records, the TLS step, the dashboard wiring, the scan-time preview banner — every layer touches something nobody on the marketing side wants to think about. So the work gets skipped, the QR goes out on whatever default host the generator handed back, and the brand finds out about it the first time a scanner sees qr-platform-23.io/aB7kx on a poster and decides not to tap.

This is the implementation companion to the case for why the QR code domain matters at all. That post argues the why. This one is the how — what to set up, in what order, and what the scanner actually sees at each step. For the visual-design side and the trust-data side, those are upstream pieces. The work here starts after the decision to use a custom domain has already been made.

What the scanner sees, one frame at a time#

Before any of the setup makes sense, it helps to know exactly what surfaces the custom domain is going to show up on. There are four, and they happen in roughly this order across the first two seconds of a scan.

The first is the camera preview banner. The phone's camera locks onto the QR code's finder patterns, decodes the URL, and pops a pill or a card showing the literal URL — no redirect resolution, no TLS check, no fetch. Just the encoded string. On iOS this is a yellow banner near the bottom of the viewfinder. On Android (Google Lens or the stock camera) it's a chip or a small card. Either way, what's visible to the human eye in that half-second window is the host name and the slug. The protocol is hidden on most modern phones. The query string, if any, is hidden or truncated. Everything else is the host.

The second is the browser address bar at the moment the user taps the banner. Before the redirect resolves, the browser opens a page on the short-link host — even if only for a hundred milliseconds. The address bar reads the host name. If the redirect host is slow, that bar reads the short-link host for closer to half a second.

The third is the browser address bar after the redirect resolves. Once the 302 lands, the bar updates to the destination URL. The short-link domain is no longer visible — but in-app browsers (Instagram, Facebook, LinkedIn) sometimes show a small footer with the most-recently-resolved URL, which is the short link.

The fourth is what the phone remembers. Camera apps keep a recent-scans list. Browsers add the page to history. Share sheets paste the short link, not the destination. A week from now, if the user opens their share history or types two letters of the short-link domain in their address bar, that's the URL the phone is going to volunteer. If you want to see what your own domain looks like across those four surfaces before committing to print, render a test code in the Linked.Codes QR generator on your custom host and walk through scan → preview → tap → history on your own phone.

Every one of these surfaces reads the host name. The visual design of the QR — round modules, logo overlay, colour palette — affects whether the scan happens. Everything after the scan is the domain. Get the domain right and all four frames read as the brand. Get it wrong and the same campaign hands four free impressions to whatever shortener you defaulted to.

The DNS step — one record, two gotchas#

The mechanics of pointing a custom domain at a QR-redirect host are the same as pointing a domain at any other web service. You log into your registrar's DNS panel, you add one record, you wait a couple of minutes for propagation. The record type depends on whether you're using a subdomain or a root domain.

For a subdomain (qr.yourbrand.com, link.yourbrand.com, go.yourbrand.com), use a CNAME. The value is whatever host the redirect platform tells you to point at. CNAMEs handle TLS provisioning the cleanest because the redirect host can resolve the underlying IP without needing you to update DNS every time their infrastructure moves.

For a root domain (yourbrand.com directly, no subdomain), use an A record pointing at a fixed IP, or an ALIAS / ANAME record if your DNS provider supports them. A records lock you to a specific IP — if the redirect host changes its infrastructure, you have to update the record yourself. ALIAS/ANAME records sidestep this by resolving the CNAME at the DNS provider's side, which is what you want for a root domain.

The two gotchas are:

TTL matters. Set the TTL to 300 seconds (five minutes) during initial setup. If the record is wrong or the redirect host changes the target value, a long TTL means scanners get stale DNS for hours. Once everything's working and stable, you can bump the TTL up to an hour or longer. Don't ship with a 24-hour TTL on day one.

Apex CNAME is forbidden by the DNS spec. You cannot put a CNAME on yourbrand.com (the apex). Every DNS provider that "supports apex CNAMEs" is doing something proprietary (ALIAS, ANAME, flattening) on their side. If your provider doesn't, you have two choices: use an A record with a fixed IP, or use a subdomain instead. RFC 1034 is unambiguous about this — apex CNAME is invalid because the apex needs to hold the domain's SOA and NS records, which a CNAME would shadow.

TLS — the part that breaks more often than you'd think#

Once DNS resolves, the redirect host needs a TLS certificate for the custom domain. Almost every modern platform handles this with Let's Encrypt or a similar automatic certificate authority. The certificate is issued on the first request that hits the new host name, then renewed every 60-90 days for the rest of the domain's life. The user never sees this happen.

The places it breaks are predictable. Let's Encrypt enforces rate limits — 50 certificates per registered domain per week, 5 duplicate certs per week, 300 new orders per account per three hours. The numbers are documented in the Let's Encrypt rate-limits page and they almost never bite a normal user. They do bite if you're an agency standing up 200 client domains in one afternoon, which is the case where the rate limit matters and the workaround is to use the Let's Encrypt staging environment for early testing, then promote to production in smaller batches.

The other place TLS breaks is CAA records. If yourbrand.com has a CAA record at the apex permitting only one specific CA (a holdover from someone's earlier setup), Let's Encrypt cannot issue a certificate for qr.yourbrand.com either. CAA inherits down the tree. The fix is either to remove the CAA record, or to add Let's Encrypt to it. Most domains don't have a CAA record at all, in which case nothing has to change.

The third is mixed-content if the destination is http:// rather than https://. The redirect itself works, but the destination page loads warnings. Always destination-redirect to HTTPS.

Multi-tenant — one platform, many domains, one mental model#

The agency case looks harder than it is. The brief: ten clients, ten brand domains, each running their own QR redirects, all administered out of one platform. The instinct is "ten separate setups, ten times the work, ten places to break". The reality is one platform with ten domain records and ten DNS records — and a single mental model that scales to any number.

Every redirect host worth using in 2026 supports multi-tenant domain mapping. You add each client's domain in the platform UI. The platform tells you the DNS target for each. You (or the client) add the CNAME at their registrar. The platform notices the DNS resolves, issues TLS, and the new domain is live. Each client's QRs encode their own domain. Each client's preview banner reads as their brand. The platform sits underneath, invisible to the scanner.

The architecture detail that matters is per-domain tenancy versus per-account tenancy. Per-domain means each client's data, links, and analytics are isolated by domain — they cannot see each other's traffic even if you mistakenly grant cross-tenant access. Per-account means the agency's account holds all the data and the domains are just routing labels. Per-domain is safer for client trust; per-account is faster to administer. The right pick is whichever the platform offers natively — converting later is painful. The agency multi-brand QR walkthrough covers the billing and deliverable side of this. The architecture side is below.

The URL anatomy decoder#

This is the widget version of the discussion above. Paste any URL into the input and the widget breaks it into the parts the scanner sees, with an annotation per part about what role it plays at scan time. Inputs persist across page reloads so you can come back to it later.

Run a few URLs through it. A long URL with three UTM parameters runs to 120 characters or more — the encoded QR jumps two versions and the print starts failing at small sizes. The short-link version on a custom domain runs to 25 — the entire problem disappears. This is the URL versus short-link anatomy comparison made concrete: you can see the length collapse happen as you swap the input.

The customer-experience side — what builds trust in that half-second#

The preview banner is the only surface where the trust decision is being made by someone who hasn't yet consented to the URL. Every other touchpoint — destination page, sign-up form, checkout — happens after the user has already chosen to engage. The banner is the only place where the URL has to earn the tap from a cold start.

What builds trust there:

Match between the surrounding context and the host. A poster reading "Spring sale — yourbrand.com" with a QR pointing at qr.yourbrand.com/spring closes the trust loop in one read. A poster reading the same message with a QR pointing at xqr-7.io/aB7k2X opens it. The user can't tell which one is real because both work mechanically; they choose based on whether the QR is reading consistent with the rest of the asset.

A host they could plausibly type. Hosts under 20 characters with one obvious brand reference read as legitimate. Hosts that look like generated strings of letters and digits read as auto-generated, which reads as suspicious. The fact that xqr-7.io actually is a real generator does not help — the scanner has half a second to decide and reads it as random.

The TLS padlock on the destination. Not visible at the banner, but visible the moment the redirect resolves. A custom domain on HTTPS is the baseline. A custom domain that redirects to HTTP is worse than a generic shortener that redirects to HTTPS, because the scanner gets a warning at the destination. Always redirect to HTTPS, always have TLS on the custom domain. The same trust dynamics carry over from the case for branded short links over bit.ly — what builds trust at the click on a phone screen is also what builds trust at the QR scan banner.

No redirect chain. A QR that encodes domain A, redirects to domain B, redirects to domain C reads as a phishing chain. Modern phones flag long redirect chains. The redirect at the QR layer should land at the destination in one hop. Two hops if a UTM normalisation step is unavoidable. Three or more, the user starts seeing warnings.

What doesn't build trust at the banner:

The visual design of the QR itself. The logo overlay. The colour. The round modules. All of that is the work that got the scan — it doesn't affect the read of the URL after the scan. The post on the trust argument for branded short links covers the click-through angle, and the post on the agency multi-brand QR delivery angle covers what that's worth as a billable line.

Social-platform QRs are the place this matters most concretely. A code on a take-out box pointing straight at m.me/restaurant-handle is fine; the same code pointing at xqr-7.io/aB7k that then redirects to m.me/restaurant-handle reads as a phishing wrapper at the preview banner and loses scans. Putting the redirect on the restaurant's own domain (yourbrand.com/order) closes the trust gap without giving up the analytics layer. The routing options for a facebook qr code across Pages, Messenger, and Events work the same way — a branded domain in front of the social URL is how the campaign keeps the scan rate high.

The QR is the part the scanner looks at for a second. The host is the part they look at for half a second. The work of the host is to make the second one count as much as the first.

What can wait#

A few things people worry about up front that turn out not to matter much.

Picking the absolute shortest possible host. qr.yourbrand.com is 16 characters. lnks.brand.com is 14. The two characters do not change the QR version. Pick the host that reads cleanest to a human; the encoded length is dominated by the slug and any path. The vanity short URL naming guide covers the naming side in depth.

Picking the exact subdomain word. qr., link., go., scan. — all of them work. There's no SEO impact, no trust difference. Pick what fits the brand. The dashboard supports either, and the solopreneur branded QR guide walks through the small-brand case.

Worrying about scan-rate impact from the redirect. Sub-100ms on a healthy host. The user doesn't see the redirect happen. The destination page loads as fast as it would have loaded directly.

Setting up DNSSEC. A nice-to-have. Not load-bearing for QR redirects. If your registrar supports it, fine. If not, skip it.

The setup checklist#

For the practical work, the order is:

1. Decide on the host. Subdomain on your brand domain is the default unless you have a reason to pick a separate vanity domain.
2. Add the host in the platform's domain settings. The platform returns either an A-record IP or a CNAME target.
3. Add the DNS record at your registrar, TTL 300.
4. Wait for DNS to propagate. Most registrars take under five minutes. Some take up to an hour.
5. The platform's domain status flips to verified. TLS provisions on the first request.
6. Test-scan one QR pointing at the new host before generating the print run. Confirm the preview banner reads as expected.
7. Generate the production QRs. The platform encodes them on the new domain by default. The case for routing every QR through a redirect rather than a static URL is laid out in why every QR type should be dynamic by default.
8. Bump the TTL up to 3600 once the setup is stable.

The first time you do this, the whole sequence takes about ten minutes plus DNS propagation. The second time, three minutes plus DNS. The full per-tenant wiring is documented in the custom domain platform docs. After that, every QR you ship runs on your domain, every preview banner reads as your brand, and every scanner walks away with a URL imprint that strengthens the brand instead of the platform. That's the whole point of routing your QRs through your own short-link layer rather than letting them ride on the generator's default.