Custom Domain for QR Codes and Short Links
A custom domain makes the short links printed on your materials read as yours. Add the host once, prove that you control it with a DNS record, and then choose it on each code.
What a custom domain changes
Without a custom domain, every short link lives on the host of the QR Replica app. With one, the codes you choose resolve on a host name you control, such as a subdomain you create under your main domain for links. The slug stays the same, so the address reads as your brand followed by a short code.
Verification has two parts. You create a CNAME record that points your host to the host where the app runs, and a TXT record named with the prefix _qrreplica-verify followed by your host, whose value is a token the app generated. When you press verify, the app checks the TXT record only. The CNAME carries the traffic, so it is your job to confirm it with your DNS provider.
A verified host belongs to one workspace. Other workspaces can add the same host, but they cannot verify it while the first one holds it. Each dynamic code can use one verified domain from its own workspace, and a code without a custom domain keeps answering on the app host. The app does not issue TLS certificates, so whoever runs the deployment must serve the host over HTTPS.
How to connect a domain in three steps
-
01
Add the host
On the Team plan, open the domains page as an owner and type the host without a protocol or a trailing slash. The app stores it in lower case. Hosts with fewer than four characters, or without a valid top-level domain, are refused.
-
02
Create the two DNS records
Create a CNAME record from your host to the app host that the page shows. Then create a TXT record named _qrreplica-verify followed by your host, with the verification value the page displays. DNS changes can take time to spread, so wait a little before you verify.
-
03
Verify and choose the domain
Press verify. When the TXT record is found, the domain is marked as verified and the time appears on the page. Then open a dynamic code in the editor and choose the domain in the Domain list, which only offers verified domains of your workspace.
Where a custom domain is worth it
-
Product packaging and labels
A label that prints a short link on the box can show your own domain, so the address matches the packaging and a customer can read it back without confusion.
-
Groups with several brands
One workspace can verify a host for each brand. Each code then points to the right host, so the menu for one brand and the loyalty card of another keep recognisable addresses.
-
Trade fairs and temporary stands
Give each stand a code that resolves on the fair's host. When the fair is over, remove the domain, and that host stops answering for those codes.
-
Campaign managers with a seasonal address
Keep one host for a whole season and change the destination of each code inside it. The printed address never changes, while the offer behind it does.
-
Teams that host the app themselves
Once a host is verified, the app accepts requests for it without a redeploy. You still point the DNS records at the app and put HTTPS in front of it.
Tips before you publish a custom domain
- Limit who can edit DNS
- The verification value proves that you control the DNS zone. Anyone who can create records there can complete the verification, so keep the access to the zone with the people who manage the domain.
- Choose the host before you print
- Changing the host later means reprinting, because the printed short link keeps the old host. Pick a subdomain you plan to keep for years, and avoid a name you may sell or let expire.
- Remove a domain with care
- Removing a domain detaches its codes. Those codes then fall back to the app host, and the printed link on the old host stops resolving. Check which codes use the domain before you remove it.
- Retry after DNS has spread
- A verification that fails right after you add a record may simply be early. Wait a few minutes, try again, and compare the record value with the one on the page character by character.
Questions about custom domains
Which plan includes custom domains?
The Team plan. Adding a domain needs an owner and the Team plan, and verifying one is also limited to owners. If a workspace drops to a lower plan, its existing domains and codes keep working, but it cannot add new ones.
Who issues the HTTPS certificate?
Not the app. Whoever runs the deployment must put HTTPS in front of the app for every host you verify. Without a certificate for the host, visitors see a certificate error before the redirect runs.
Can two workspaces use the same domain?
Both can add it, but only one can verify it. Once a workspace holds a verified host, another workspace cannot verify the same host, so an unverified claim cannot take over a domain that someone else has proved.
Which codes use my domain?
Only the codes you choose. The Domain list in the editor offers only the verified domains of your workspace, and its default option keeps the app host. A code that keeps the default is served from the app host.
Can a static code use a custom domain?
No. A static code has no short link, so a domain has nothing to serve. The domain takes effect only on dynamic codes and smart links.
Does the verification check the CNAME record?
No. The app checks only the TXT record. The CNAME is what routes visitors to the app, and the app does not test it, so check it with your DNS provider or a lookup tool.
Maak je eerste code in een minuut
De editor is gratis. Maak een account aan wanneer je codes wilt opslaan, scans wilt volgen of later een bestemming wilt wijzigen.