How to connect your own domain to a booking engine
The site is built. The logo is right, the markups are set, a test booking went through on the platform subdomain, and someone in the office has already sent the link to three customers. Then the obvious question arrives: why does the address still carry somebody else's name? This guide covers how to connect your own domain to a booking engine without hiring anyone — what you are actually changing, the two or three records involved, why the padlock turns up later than you expect, and the one setting that quietly breaks company email if you touch it.
You do not need to understand DNS in depth. You need one idea: your domain name is a signpost, and you are pointing it at a new building. Everything below is detail on that idea.
Where your domain actually lives
Up to three different companies can be involved, and most owners know only one of them. The registrar is where you bought the name and pay the yearly renewal. The DNS host is where the records for that name are edited — often the same company as the registrar, sometimes not, especially if a web designer set things up years ago and moved the name to a separate DNS service. The website host is wherever your current site runs.
The records you are about to add go to the DNS host. So before anything else, find out who that is. Log in to the registrar and look at the nameservers listed on the domain. If they belong to the registrar, you edit records there. If they point somewhere else, that somewhere else is where you work. A few minutes on this saves an afternoon of editing records in a panel that nothing reads.
Apex or subdomain: decide before you touch anything
The apex — also called the root or naked domain — is yourbrand.com with nothing in front of it. A subdomain is anything with a label in front: www.yourbrand.com, book.yourbrand.com, travel.yourbrand.com. The platform accepts either, and the choice changes which record you add.
The reason is old and not negotiable. The apex already carries the records that define the domain itself, and DNS does not allow a CNAME to share a name with anything else. So an apex is pointed with an A record straight at an IP address, while a subdomain is pointed with a CNAME at another hostname.
| Apex (yourbrand.com) | Subdomain (book.yourbrand.com) | |
|---|---|---|
| Record you add | A record, pointing at an IP address | CNAME, pointing at a platform hostname |
| What customers type | The shortest possible address | One extra word, which matters less when customers arrive through a link |
| Your existing website | Has to move off the apex, or the booking site replaces it | Stays exactly where it is |
| Company email | Unaffected, as long as the MX records are left alone | Unaffected |
| Suits | An agency whose website IS the booking site | An agency with a brochure site, blog or CMS it wants to keep |
Most agencies that already have a website should start with a subdomain. The row people argue with is the second one: some owners feel a subdomain looks less established. That is a fair view, and it weighs less when most customers reach you from a link on WhatsApp or Instagram rather than by typing.
The records you add, and what each one does
The guided DNS step shows the exact values for your domain. Copy them from there, not from any article — this one included. What follows is what each record is for, so the screen makes sense when you see it.
- CNAME, for a subdomain. Name: the label you chose, such as
book. Value: the platform hostname the DNS step gives you. It says "this name is an alias for that one", so if the platform's servers move, your record keeps working without you touching it. - A record, for an apex. Name:
@, which most DNS panels use to mean the bare domain. Value: the IP address the DNS step gives you. It says "this name lives at this address". - TXT, sometimes. Some hosting setups also ask for a verification record: a long random string under a name the DNS step specifies. It does nothing for visitors. It proves that whoever controls the domain agreed to the connection. If the step shows one, add it; if it does not, nothing is missing.
Two mistakes account for most failed attempts. The first is typing the full domain into the Name field. Many panels append your domain automatically, so book.yourbrand.com typed there becomes book.yourbrand.com.yourbrand.com, which resolves to nothing. Type only the label. The second is leaving an old record in place. If book already has an A record from a past project, a CNAME cannot sit beside it, and some panels quietly keep the old one. Delete the old record for that exact name first.
If your DNS host offers a proxy switch on the record — Cloudflare shows it as an orange cloud — set it to DNS-only while you connect. A proxy answers visitors on the platform's behalf, which hides the platform from the check described next.
Why the padlock comes last
This is the step that makes owners think something is broken. The records are saved, the domain looks right, and the browser says the connection is not secure — or the site does not open at all. Nothing is broken. The order is simply fixed.
A TLS certificate, the padlock, is issued by a certificate authority that first has to confirm the domain really points where the request says it does. It checks by looking the name up in public DNS and, in most setups, by making a request to the domain and expecting the platform to answer. Until your record has reached the resolvers that authority uses, the check fails, and no amount of clicking changes that. Once the record resolves, the platform requests the certificate automatically. You do not buy one, upload one or renew one.
How long "resolves" takes depends mostly on the TTL of whatever record was there before: the time other servers were told they may remember the old answer. A brand-new name usually shows up quickly. A name that pointed somewhere else yesterday can keep answering with the old address for a while. If you know you are replacing an existing record, lowering its TTL a day ahead shortens the wait.
Otherwise, wait, then check. Do not keep editing the record — each edit gives every server that cached a wrong answer another reason to keep serving it. Public DNS lookup sites show what the rest of the world sees for your name; when they show the value from the DNS step, the certificate is the next thing to happen.
What getting it wrong costs
The expensive mistakes are not in the booking site. They are in everything else attached to your domain.
The worst is changing the nameservers when you only needed to add a record. Moving nameservers hands the whole domain to a new DNS host, and any record not recreated there disappears — including the MX records that deliver company email. An agency can lose a day of client emails, supplier confirmations and airline schedule-change notices before anyone notices the inbox has gone quiet. Nothing about connecting a booking site requires moving nameservers. Add records; leave the rest alone.
The second is pointing the apex at the booking site while the old website still has pages people use: a visa page that ranks on Google, a contact page printed on business cards. Those links now land on a booking site that does not have them. Either move the old site to a subdomain first, or connect the booking site to a subdomain instead.
The third costs only nerves: announcing the new address before the padlock appears. A browser warning customers away from your site on the day you promoted it is a poor introduction. Announce after the certificate is live, not after the record is saved.
Keep the platform domain — it is your fallback
The platform subdomain your site started on does not go away when your own domain is attached. It cannot be removed, and that is deliberate.
It is the address to test from while the custom domain settles, and the one that still works if a renewal lapses at the registrar or someone edits the DNS by mistake. The booking engine behind both addresses is the same, so bookings, customers and reports do not care which door was used. Keep it written down somewhere that does not depend on your own domain being up.
It also sets the right order for a new site, the same order as in launching an OTA in a day: go live on the subdomain the signup wizard provisions without asking for a card, and connect your domain once the site is worth showing. What the site itself covers once the address is yours is in what a white label travel website actually gets you.
Checklist: connect your own domain to a booking engine
- Find who hosts your DNS. The nameservers on the domain tell you.
- Choose apex or subdomain. If you have a website you want to keep, choose a subdomain.
- Record every existing entry, especially MX, before changing anything. A screenshot will do.
- Delete any old record on the exact name you are about to use.
- Add the record from the DNS step: CNAME for a subdomain, A for an apex, plus TXT if the step shows one. Type only the label in the Name field.
- Switch any proxy on that record to DNS-only.
- Wait for the record to resolve publicly. Do not keep editing it.
- Confirm the padlock, make a test booking on the new address, then tell customers.
Most of that list is waiting. The only step that can really hurt you is the one it does not contain: moving the nameservers.