A booking does not end when the client pays. It ends when they read the confirmation.

Picture this: a Friday in December, a family in London books a suite at a hotel in Gstaad on its website. The payment goes through without a hitch. The confirmation leaves the website’s server with the hotel’s address, but that server is not among those authorised to send email on its behalf. Gmail files it as spam. The family cannot find it. On Saturday they write to reception to ask whether the booking exists. On Sunday, just in case, they also book another hotel through a platform.

A great deal goes into getting the client to book on the website. Almost nothing goes into making sure the email that confirms it arrives. And that email is the first thing the client receives from you after paying.

What Gmail requires.

Since 1 February 2024, Google has required anyone sending email to personal Gmail accounts to use SPF or DKIM authentication, valid forward and reverse DNS records, an encrypted connection and a spam rate below 0.3%. Anyone sending close to 5,000 messages a day or more must also use both SPF and DKIM, publish a DMARC record, even with the mildest policy, make sure the sender’s domain matches the authenticated one and, for marketing emails, offer one-click unsubscribe honoured within 48 hours.

Since November 2025, according to Google, Gmail has been stepping up enforcement: messages that do not comply face temporary and permanent rejections. Unauthenticated messages may end up in spam or be returned with an error code. The rules apply to email reaching personal Gmail accounts, which is precisely where your patients, your guests and the families who write to you tend to be.

The detail almost nobody reads.

For Gmail, the 5,000-a-day threshold is counted per primary domain: emails from hotel.ch and from news.hotel.ch add up together. And anyone who reaches it once is classified as a bulk sender for good. Google puts it plainly: the status does not expire, and changing how you send does not change it.

In other words, one large newsletter to past clients can permanently change the rules that the booking confirmations sent by your website have to meet. There is a second useful nuance. Booking and form confirmations are exempt from one-click unsubscribe, because they are transactional emails. They are not exempt from authentication.

What I do not know.

Google does not publish how many emails it rejects under these rules, and I have no reliable figure for how many confirmations go missing at clinics, hotels or estate agencies. What I do know is that the failure is silent. The sender cannot see the recipient’s spam folder, and clients rarely call to say they received nothing. My suspicion is that most of the time they simply do not come back.

An email that never arrives does not throw an error. It leaves a silence.

Where I stand.

I think the confirmation email is part of the experience, not a technical detail to be left to the hosting provider. Every system that writes on behalf of your company, whether the website, the booking engine, the CRM, the newsletter tool or the clinic software, has to be authorised, and someone has to read the reports that DMARC sends back. On my own domain, DMARC is set to the strictest policy, the one that asks for anything unauthenticated to be rejected. A booking does not end when the client pays. It ends when they read the confirmation.

What I would check.

• Who sends on your behalf. The website, the booking engine, the CRM, the newsletter tool and the management software.
• SPF, DKIM and DMARC. Whether they exist and cover all of those senders, not just the main mailbox.
• The visible sender. That the address the client sees is on your domain and matches the authenticated one.
• The volume. Whether you have ever sent close to 5,000 emails to Gmail accounts in a day, counting subdomains.
• The real test. A test booking to a personal Gmail account and to an Outlook one, checking the spam folder too.

Where to start.

1. This week

   Run the test

   Book or write through the website from a personal account and see where the confirmation lands.

2. This month

   Take stock

   A list of every system that sends email using your domain, with the person responsible for each.

3. This quarter

   Authenticate and monitor

   SPF, DKIM and DMARC for every sender, and DMARC reports that someone actually reads.

4. Every change

   Test again

   Whenever you change provider, booking engine or newsletter tool.

Write down from memory everything that sends email on behalf of your business: the website, the booking engine, the invoicing, the newsletter, the CRM, that form someone installed two years ago. Then compare it with the list your technical team makes.

If the two lists do not match, you may already have a clue as to why some customers say they never received the confirmation. And a worse doubt remains: how many did not say so?

If you would like me to review what happens to the emails your website sends in your name, start with the Strategic Diagnostic. Which systems may write on behalf of your business is for your management and your technical team to decide, not a designer.