Custom domain checklist
Verify a custom domain works end to end before you point campaigns, QR codes, and embeds at it.
1 min read
Run through this before the new address appears anywhere a participant can reach. The cost of finding a problem after the posters are printed is the print run.
Verify the switch
- The record resolves from a public lookup tool, not just from your own browser.
- The padlock appears with no certificate warning, in a fresh browser session.
- A published campaign opens on the new address and runs through to a reward.
- The default OmniLab address still works and stays live — both addresses serve the same campaigns, so nothing already published breaks.
Verify everything that uses it
- Embedded pages. Update the address in every page that embeds an experience. See Website integration.
- Apps. A WebView address is compiled into a release — plan the app update.
- QR codes. Regenerate any code that has not been printed yet.
- Email templates. Check any hardcoded links in your email platform.
Before you publish anything physical
- Scan a test QR code with a real phone on mobile data, not office wi-fi.
- Confirm the address does not trigger a warning in your own corporate network filter — this catches out in-store tablets and staff devices.
Where to send a problem
| What is happening | Who to contact first |
|---|---|
| The address does not resolve | Your DNS or IT team |
| A certificate warning that will not clear | Your DNS team first to confirm the record, then OmniLab support |
| The address resolves but the campaign will not load | OmniLab support |
| Participants cannot stay signed in on an embedded page | Your web team — the page still frames the default address, which the browser treats as third-party. It has to point at your own subdomain |