La reserva no termina cuando el cliente paga. Termina cuando lee la confirmación.

Imagine la escena: un viernes de diciembre, una familia de Londres reserva una suite en un hotel de Gstaad desde su web. El pago se hace sin problema. La confirmación sale del servidor de la web con la dirección del hotel, pero ese servidor no figura entre los autorizados a enviar correo en su nombre. Gmail la manda a spam. La familia no la encuentra. El sábado escribe a recepción para preguntar si la reserva existe. El domingo, por si acaso, reserva también en otro hotel a través de una plataforma.

Se invierte mucho en que el cliente reserve en la web. Casi nada en que le llegue el correo que lo confirma. Y ese correo es lo primero que el cliente recibe de usted después de pagar.

Lo que exige Gmail.

Desde el 1 de febrero de 2024, Google exige a cualquiera que envíe correo a cuentas personales de Gmail autenticación SPF o DKIM, registros DNS directos e inversos válidos, conexión cifrada y una tasa de spam por debajo del 0,3 %. A quien envía cerca de 5.000 mensajes al día o más le exige además SPF y DKIM a la vez, un registro DMARC, aunque sea con la política más suave, que el dominio del remitente coincida con el autenticado y, en los correos de marketing, una baja en un clic atendida en 48 horas.

Desde noviembre de 2025, según Google, Gmail endurece la aplicación de estas reglas: los mensajes que no cumplen sufren rechazos temporales y permanentes. Los que no van autenticados pueden acabar en spam o ser devueltos con un código de error. Las reglas se aplican al correo que llega a cuentas personales de Gmail, que es justo donde suelen estar sus pacientes, sus huéspedes y las familias que le escriben.

El detalle que casi nadie lee.

Para Gmail, el límite de 5.000 mensajes diarios se cuenta por dominio principal: los envíos de hotel.ch y los de noticias.hotel.ch suman juntos. Y quien lo alcanza una sola vez queda clasificado como remitente masivo para siempre. Google lo dice así: esa condición no caduca, y cambiar la forma de enviar no la cambia.

Dicho de otro modo: una sola newsletter grande a antiguos clientes puede cambiar de forma permanente las reglas que deben cumplir las confirmaciones de reserva que envía su web. Hay un segundo matiz útil. Las confirmaciones de reserva y de formulario están exentas de la baja en un clic, porque son correos transaccionales. No están exentas de la autenticación.

Lo que no sé.

Google no publica cuántos correos rechaza por estas reglas, y yo no tengo una cifra fiable de cuántas confirmaciones se pierden en clínicas, hoteles o inmobiliarias. Lo que sí sé es que el fallo es silencioso. El remitente no ve la carpeta de spam del destinatario, y el cliente rara vez llama para decir que no recibió nada. Sospecho que lo más frecuente es que, sencillamente, no vuelva.

Un correo que no llega no da error. Da silencio.

Mi posición.

Creo que el correo de confirmación es parte de la experiencia, no un detalle técnico que se deja al proveedor de alojamiento. Cada sistema que escribe en nombre de su empresa, la web, el motor de reservas, el CRM, la herramienta de boletines o el programa de la clínica, tiene que estar autorizado, y alguien tiene que revisar los informes que devuelve DMARC. En mi propio dominio, DMARC está en la política más estricta, la que pide rechazar lo que no se autentica. La reserva no termina cuando el cliente paga. Termina cuando lee la confirmación.

Lo que yo revisaría.

• Quién envía en su nombre. La web, el motor de reservas, el CRM, la herramienta de boletines y el programa de gestión.
• SPF, DKIM y DMARC. Si existen y si cubren a todos esos remitentes, no solo al buzón principal.
• El remitente visible. Que la dirección que ve el cliente sea de su dominio y coincida con la autenticada.
• El volumen. Si algún día ha enviado cerca de 5.000 correos a cuentas de Gmail, sumando los subdominios.
• La prueba real. Una reserva de prueba a una cuenta personal de Gmail y otra de Outlook, mirando también la carpeta de spam.

Por dónde empezar.

1. Esta semana

   Hacer la prueba

   Reservar o escribir desde la web con una cuenta personal y ver dónde llega la confirmación.

2. Este mes

   Hacer el inventario

   La lista de todos los sistemas que envían correo con su dominio, con su responsable.

3. Este trimestre

   Autenticar y vigilar

   SPF, DKIM y DMARC para cada remitente, y los informes de DMARC leídos por alguien.

4. Cada cambio

   Repetir la prueba

   Cada vez que cambie de proveedor, de motor de reservas o de herramienta de boletines.

Haga una lista, de memoria, de todo lo que envía correos en nombre de su empresa: la web, el motor de reservas, la facturación, la newsletter, el CRM, aquel formulario que alguien instaló hace dos años. Ahora compárela con la que haga su equipo técnico.

Si las dos listas no coinciden, quizá ya tenga una pista de por qué algunos clientes dicen que nunca recibieron la confirmación. Y queda una duda peor: ¿cuántos no lo dijeron?

Si quiere que revise qué pasa con los correos que su web envía en su nombre, empiece por el Diagnóstico Estratégico. Qué sistemas pueden escribir en nombre de su empresa lo decide su dirección con su equipo técnico, no un diseñador.