Custom domains for QR code links: how white-label redirects actually work

What a custom domain actually means for a QR redirect

Every dynamic QR code points at a short redirect link before it lands on the real destination, and that link lives on a domain. Scan a code from most QR platforms and the URL bar shows the vendor's own shortener domain: something like qrco.de, bit.ly, or, on ScanKit, scankit.app/r/. A custom domain replaces that vendor domain with one the agency (or the client) already owns, so the redirect reads links.agency.com or qr.clientbrand.com instead.

This is not the same thing as a dynamic QR code versus a static one. Dynamic just means the destination behind the code can change after printing. A custom domain is a separate, additional layer: it changes what the link itself looks like, on any device someone uses to inspect it before or after scanning. Agencies usually want both at once, because a client asking "why does my QR code redirect through someone else's website?" is a real, recurring objection in sales conversations, and it has a precise technical answer.

The mechanism is the same one behind every branded link-shortening product (Bitly, Rebrandly) and every white-label SaaS feature in general: the agency doesn't move their QR platform to a new server, they point a small piece of their own domain at the platform's existing infrastructure using DNS.

The DNS mechanics: a CNAME record, not a domain transfer

Setting up a custom domain for a QR redirect is a DNS change, not a hosting migration. The agency adds one CNAME record in their domain's DNS settings, pointing a subdomain at a hostname the QR platform gives them. A CNAME record is an alias: it tells the internet "requests for links.agency.com should actually resolve wherever edge.qrplatform.com resolves." No files move, no server changes hands, and the agency's main website on the same domain is untouched.

There is one hard constraint worth understanding before requesting this from any vendor: a CNAME record cannot exist at the zone apex, meaning the bare root domain (agency.com with nothing in front of it). This isn't a vendor limitation, it's a structural rule in how DNS itself is specified: the apex of a domain must carry an SOA record and NS records, and a name with a CNAME on it is not allowed to carry any other record type at the same time (RFC 1034, RFC 1912). That's why almost every custom-domain setup, across every SaaS product that offers it, asks for a subdomain, not the bare domain.

If an agency insists on using the root domain itself rather than a subdomain, the workaround is a provider-side feature usually called ALIAS, ANAME, or CNAME flattening (Cloudflare, AWS Route 53, and several other DNS hosts support it under different names). It resolves the target on the provider's own servers and hands back a synthesised A record, so no CNAME actually sits at the apex and the DNS rule is never broken. It is worth knowing this exists, because it is the answer to "can we use agency.com and not links.agency.com", but it depends entirely on which company hosts the agency's DNS, not on the QR platform.

The most common setup failure isn't exotic: it's a stale A record already sitting on the subdomain the agency wants to use (often a leftover from an old redirect or a forgotten test page). Because a name can't hold both a CNAME and an A record, the new CNAME add fails or silently doesn't take effect until that old record is deleted first.

SSL: the certificate has to be provisioned per domain

A working CNAME is only half of a working custom domain. Every one of those domains also needs a valid TLS certificate, or the browser shows a security warning instead of a redirect. This used to mean buying and manually installing a certificate per domain, which made custom domains impractical for a QR platform serving many agencies, each with their own client subdomains.

The modern default is automated: Let's Encrypt issues free certificates through the ACME protocol, which proves domain ownership through a "challenge" before it will issue anything. There are two challenge types in practice. HTTP-01 puts a token file at a specific path on the domain; it's simple but can't issue a wildcard certificate and requires port 80 to be reachable. DNS-01 instead requires publishing a specific TXT record; it's the only method that can validate a wildcard, and it works even if the domain has no web server of its own, which fits a redirect-only subdomain well.

For a platform onboarding custom domains from many different customers at once, the practical pattern (used by Cloudflare for SaaS and similar multi-tenant setups) is to automate that ACME challenge on the customer's behalf once the CNAME is verified, so the certificate is issued and renewed without the agency doing anything beyond the original DNS record. If a domain's DNS zone has a CAA record restricting which certificate authorities may issue for it, that record has to explicitly allow the issuer (Let's Encrypt or whichever CA the platform uses), or issuance fails even with a perfectly correct CNAME.

1. A scan opens the branded redirect link on the visitor's phone.
2. DNS resolves the CNAME, pointing the custom domain at the QR platform.
3. The platform's TLS certificate for that domain is checked before anything loads.
4. The visitor lands on the real, intended destination page.

How long it actually takes

"Up to 48 hours" is the number that gets repeated everywhere for DNS propagation, and it's technically true as a worst-case ceiling, but it overstates the typical case badly enough to be misleading. The delay users actually experience is caching: each DNS record has a TTL (time to live) that tells resolvers how long they're allowed to keep serving the old answer before checking again. Once a change reaches the authoritative nameservers, it is available almost immediately; what takes time is every resolver on the internet that already cached the old record waiting out that record's TTL.

In practice, a low TTL (a common default is 300 seconds, five minutes) means most of the internet sees a DNS change within minutes, not days. The realistic advice for a domain cutover: check the current TTL on the record before making the change, and if it's set high (a day or more), lower it a day in advance so the eventual switch propagates fast, then raise it again afterwards. The 24-to-48-hour figure mostly reflects old, high-TTL configurations and worst-case registry processing windows, not what happens on a well-prepared modern DNS setup.

Does a branded domain actually help, and is it a security feature?

Two separate claims get bundled together in most marketing copy about custom domains, and they deserve to be pulled apart.

The brand consistency claim is straightforward and true: a link that reads qr.clientbrand.com looks like it belongs to the client, and a link that reads through an unfamiliar vendor shortener looks like it belongs to a third party, because it does. For a client paying an agency to run their campaign, that visual consistency is a real, reasonable thing to want, independent of anything measurable about scan behaviour.

The SEO claim is weaker than it sounds. Google has stated for years, including directly from Google's own Search Central team, that subdomains and subdirectories are treated equivalently for ranking purposes, and that Google's systems associate a subdomain with its parent domain rather than penalising it. For a QR redirect specifically this barely matters either way: the redirect link itself isn't content anyone wants indexed and ranked, it's a routing layer that immediately sends the visitor somewhere else. Any SEO benefit attributed to a custom QR domain is really about brand trust, not about search rankings.

The security claim is the one worth being precise about, because it cuts both ways. A verified, DNS-and-TLS-confirmed domain that an agency actually controls is more trustworthy than a generic shortener, for a concrete reason: it's consistent and checkable, not because branded-looking URLs are inherently safe. The US FTC's own consumer guidance on QR code scams is explicit that people should inspect the actual destination URL before trusting a scan, precisely because attackers exploit visual trust cues. Security researchers have documented "quishing" campaigns that register convincing lookalike domains for exactly this reason: a domain that looks like it belongs to a trusted brand is what makes a spoofed QR code convincing in the first place, not a defence against it. See our QR code security guide for agencies for how that risk plays out for print campaigns specifically. The honest framing: a custom domain earns trust because it's the agency's own, verifiable domain under the agency's own DNS control, and that discipline (checking DNS records, renewing certificates, not letting a domain lapse) is what actually protects a client, not the branding on its own.

The agency angle: one platform, many client domains

For an agency running QR campaigns across multiple clients, custom domains aren't a single setup, they're a per-client configuration that has to sit cleanly alongside however the agency already organises client workspaces. A platform that supports custom domains for agencies well should let each client's codes redirect through that client's own domain (or the agency's own, depending on the contract) without the domains interfering with each other, since each one is an independent CNAME plus an independently provisioned certificate.

This has a contractual dimension that's easy to overlook until it causes a problem: whoever's domain the redirect runs through, that party effectively controls the link. If a client's QR codes redirect through a subdomain the client owns and the relationship ends, the agency needs the DNS record removed or repointed, or the client can simply take over what the code does next by changing where their own subdomain points, even on a code that's physically printed and out in the world. Agencies that use client-owned domains for this reason should agree in writing what happens to the DNS record at contract end, the same way they'd agree on who keeps analytics access. Where the agency's own domain is used instead (links.agencyname.com, shared across clients via distinct subpaths or workspace-scoped UTM parameters), that ambiguity doesn't arise, at the cost of the redirect not carrying the individual client's brand.

A pre-flight checklist before requesting a custom domain from any QR platform

Before asking a vendor, of any kind, to set up a custom domain, it's worth having answers to a short list of questions, because the gaps between platforms show up here more than almost anywhere else:

• Subdomain only, or root domain too? Confirm whether the platform can only accept a CNAME (meaning a subdomain), or whether they support ALIAS/CNAME-flattening for a bare root domain through your specific DNS host.
• Is the TLS certificate automatic? It should be, once the CNAME is verified. If a vendor asks for a certificate file to be uploaded manually, that's a sign of an older, less automated setup that will be more fragile to maintain.
• What's the expected setup time? With a correctly prepared DNS record and a low TTL, the domain should be live within the hour, not days. Longer than that usually means a manual review step on the vendor's side, not a DNS limitation.
• Does the domain need to be dedicated, or can it host other things too? A subdomain used purely for QR redirects (qr.clientbrand.com) avoids any conflict with existing records; reusing a subdomain that already serves other traffic is where stale-record conflicts happen.
• Who owns the DNS record contractually? Decide, in writing, whether it's the agency's domain or the client's, and what happens to the record when the relationship ends.
• Does the platform show a security warning path if the certificate ever fails to renew? Certificates auto-renew via ACME, but DNS or CAA changes made later (by someone unaware of the custom domain setup) can silently break renewal months after the initial setup succeeded.

Common failure modes and how to read them

Most custom-domain problems collapse into a small number of causes, and recognising which one is faster than guessing.

"CNAME could not be added" or the record doesn't seem to take effect. Almost always a leftover A, AAAA, or other record already sitting on that exact subdomain. Delete it first; a name can't hold a CNAME alongside anything else.

The domain resolves but the browser shows a certificate warning. Either the certificate hasn't finished provisioning yet (check again after the CNAME has had time to verify), or a CAA record on the domain is blocking the certificate authority the platform uses. Check the CAA record if one exists; it must explicitly permit the issuing CA.

It worked, then broke weeks later with no changes on the platform side. The most common cause is someone else on the team editing DNS for an unrelated reason (adding a mail record, migrating a registrar) and inadvertently touching the same zone, or a CAA record added later for a different purpose that now blocks certificate renewal. This is why the DNS record for a QR custom domain is worth documenting somewhere the whole team can see it, not just in the vendor's dashboard.

Wildcard certificate requests fail. Wildcards can only be validated through the DNS-01 challenge type (a TXT record), never HTTP-01. If a platform's custom domain flow doesn't support DNS-01 validation, it structurally can't offer a wildcard, only individual subdomains, one CNAME and one certificate each.

Frequently asked questions

How long does DNS propagation actually take for a custom QR domain?

With a correctly prepared, low TTL record, most of the internet sees the change within minutes once it reaches the authoritative nameservers. The commonly cited "up to 48 hours" is a worst-case ceiling from old, high-TTL setups and registry processing windows, not a typical modern outcome.

Do I need to buy an SSL certificate separately for a custom QR domain?

No, in a properly built platform. Certificates for customer-owned domains are issued automatically through the ACME protocol (the same system behind Let's Encrypt) once the CNAME is verified, and they renew automatically. Being asked to upload a certificate file manually is a sign of an older, more fragile setup.

Can I use my client's domain instead of my agency's own domain?

Yes, mechanically it works exactly the same way: the CNAME lives in whichever domain's DNS the record is added to. The decision is contractual, not technical, and it's worth agreeing in writing what happens to that DNS record if the agency relationship with that client ends.

Does a subdomain hurt my SEO compared to using the main domain?

Not for a QR redirect link specifically. Google treats subdomains and subdirectories equivalently for ranking, and a redirect link isn't content that needs to rank on its own; it just needs to be trustworthy-looking and reliable.

Does a branded custom domain actually stop QR code phishing?

Not on its own. A domain the agency genuinely controls and keeps verified is more trustworthy than a generic shortener, but attackers specifically register convincing brand-lookalike domains to exploit exactly this kind of visual trust. The real protection is DNS and certificate hygiene the agency actually maintains, plus recipients checking the destination URL, not the presence of a custom domain by itself.

Can I use the bare root domain, like agency.com, instead of a subdomain?

Only if your DNS host supports an ALIAS, ANAME, or CNAME-flattening feature, because a plain CNAME record cannot exist at the domain's root by DNS specification. Most agencies use a subdomain instead (links.agency.com) specifically to avoid needing that workaround.

What's the difference between a custom domain and a white-label QR platform?

A custom domain changes what the redirect link's URL looks like. White-labelling is broader: it can also mean removing the platform's own branding from the redirect page itself, from client-facing reports, or from the dashboard the client sees. A platform can offer one without the other, so it's worth checking both if brand consistency matters for the whole client experience, not just the link.

Can one agency run different domains for different clients on the same account?

Yes, that's the normal agency pattern: each client's codes redirect through that client's own subdomain (or a shared agency subdomain, depending on the contract), each configured as an independent CNAME and certificate, without interfering with any other client's setup on the same account.

The short version

A custom domain for a QR redirect is a DNS change, not a platform migration: one CNAME record pointing a subdomain at the QR platform, with a TLS certificate that a well-built platform provisions and renews automatically through the ACME protocol. It typically goes live within the hour once the record is prepared correctly, not the 48 hours folklore suggests. It genuinely helps with client-facing brand trust and contractual clarity about who controls the link; it does essentially nothing for SEO, and it is not, by itself, a defence against QR phishing, since attackers exploit the same visual trust a legitimate branded domain relies on. Before requesting one from any vendor, agencies should confirm whether root-domain use is supported, whether the certificate is automatic, and who owns the DNS record contractually once a client relationship ends.