Por: Marcela Mexia
Consejera Nacional de Transformación Digital.

Consultamos los registros públicos de 713 hoteles independientes mexicanos —de Cancún a Ciudad Juárez, de San Miguel de Allende a Monterrey— para responder una sola pregunta: si alguien manda un correo haciéndose pasar por ese hotel, ¿hay algo que lo detenga?

En el 88.5% de los casos, no.

No es una estimación ni una encuesta. Es una consulta a registros que cualquiera puede leer, y al final de este artículo está el detalle de cómo se hizo y qué se excluyó, para que quien quiera pueda repetirla.

Qué es DMARC, sin tecnicismos

Cuando alguien recibe un correo que dice venir de tu hotel, el servidor que lo recibe necesita alguna forma de comprobar si eso es cierto. El correo electrónico se diseñó en los años setenta sin ese mecanismo: poner cualquier remitente es tan fácil como escribir cualquier nombre en el sobre de una carta.

Con los años se añadieron tres piezas para cerrar ese hueco, y las tres se publican en la configuración de tu dominio, no en tu sitio web:

SPF es la lista de servidores autorizados a enviar correo a tu nombre.

DKIM es una firma invisible que tu servidor le pone a cada mensaje que sale, y que el servidor receptor puede comprobar.

DMARC es la instrucción final: le dice al servidor que recibe qué hacer cuando un correo dice venir de ti pero no pasa esas dos comprobaciones. Tiene tres respuestas posibles. Puede decir «déjalo pasar» ( p=none ), «mándalo a spam» ( p=quarantine ) o «recházalo» ( p=reject ).

Un dominio sin DMARC, o con DMARC en p=none , está diciéndole al mundo: si alguien escribe con mi dirección y no puede probar que soy yo, entrégalo igual.

Lo que encontramos

De 713 hoteles independientes que operan y manejan su propio correo:

Uno de cada diez no tiene ni siquiera SPF.

El dato que más inquieta no es el 54.7% sin DMARC. Es el 33.8% que sí lo tiene publicado, pero en modo observación. Alguien en esos hoteles se tomó la molestia de configurarlo y quedó a medias: el registro existe, pide informes, y no rechaza absolutamente nada. Si alguien revisa una lista de pendientes de seguridad, ese hotel aparece como resuelto. En la práctica está tan expuesto como el que no tiene nada.

Es más de un tercio de la muestra creyendo que ya lo atendió.

Por tipo de destino las diferencias son moderadas: los hoteles de playa salen mejor —82.0% expuestos— y los de ciudades coloniales y Pueblos Mágicos peor, con 96.2%. La lectura correcta no es que unos estén bien y otros mal. Ninguno de los cuatro grupos baja del 81%. El problema es parejo en todo el país.

Las cadenas ya lo resolvieron

Para saber si esto es un problema del sector o de un tamaño de negocio, medimos también los dominios de las 35 cadenas hoteleras con presencia en México que el muestreo había apartado: las internacionales y las mexicanas, de Marriott a Grupo Posadas.

Cincuenta y un puntos de diferencia. Marriott, Hilton, Hyatt, Meliá, Barceló, RIU, Four Seasons, Wyndham, Pueblo Bonito y las cuatro marcas de Grupo Posadas —Fiesta Americana, Fiesta Inn, Gamma y One— tienen DMARC en una política que rechaza o filtra. Ninguna de las 35 carece de SPF.

Esto importa por dos razones.

La primera es que descarta la explicación fácil. Si el problema fuera del correo electrónico, o de lo caro que resulta, o de que la tecnología no está madura, las cadenas estarían igual de expuestas. No lo están. Lo mismo que el 88.5% no ha hecho, el 62.9% ya lo hizo, con los mismos proveedores y las mismas herramientas.

La segunda es que la diferencia no es de presupuesto. Publicar los tres registros no cuesta dinero. Lo que una cadena tiene y un hotel de veinte habitaciones no es un área de sistemas que revise esta clase de cosas. La tarea es la misma; lo que falta es que alguien la ponga en una lista.

Conviene decir que las cadenas tampoco están perfectas: una de cada cinco no tiene DMARC, y ahí aparecen nombres grandes. Y hay un detalle que cualquier hotelero debería revisar hoy mismo: en la muestra aparece una cadena cuyo dominio corporativo está protegido mientras que el dominio con el que escribe a sus huéspedes está en p=none . Tener varios dominios y proteger sólo uno deja abierto justo el que importa. Aun así, la distancia entre los dos grupos es demasiado amplia para atribuirla al azar.

Primera consecuencia: el fraude que ya está ocurriendo

Esto no es hipotético, y no hace falta imaginarlo: hay un regulador documentándolo en tiempo real.

En julio de 2026 la Agencia Española de Protección de Datos recibió 919 notificaciones de brechas de datos personales: la cifra mensual más alta de los últimos doce meses, y más del triple de las 282 que había recibido en julio del año anterior. La Agencia señala de dónde vino el aumento: de establecimientos hoteleros y de sus proveedores de software de gestión de reservas.

El mecanismo que describe merece leerse con calma, porque no es el ataque que uno se imagina. No hay sistemas apagados ni pantallas pidiendo rescate. Un tercero accede a los datos de quienes hicieron una reserva, y con esos datos escribe al cliente «a través de los portales de reserva, correo electrónico y otros servicios de mensajería instantánea, alegando problemas en el pago y reclamando el pago de la reserva».

Piensa en lo que recibe esa persona: un mensaje que menciona su reserva real, con sus fechas reales y el importe exacto, informándole de un problema con el cobro. No hay nada ahí que active las alarmas habituales. No es un premio inesperado ni un remitente desconocido: es su propia reserva, con sus propios datos.

La Agencia lo dice sin rodeos. Son «intentos de fraude que en muchas ocasiones tienen éxito».

Cuando ese correo llega con tu dirección de remitente y tu dominio no tiene un DMARC que rechace, no hay nada técnico que lo detenga. El huésped paga dos veces, el dinero se pierde, y quien queda con el problema de reputación es el hotel, que muchas veces se entera semanas después y por el propio cliente.

Segunda consecuencia: tu propio correo acaba en spam

Hay un segundo costo, más silencioso, que casi nadie conecta con esto.

Desde el 1 de febrero de 2024, Google exige autenticación a quien le manda correo a Gmail. Todos los remitentes deben tener SPF o DKIM configurados, y quienes envían volúmenes altos deben tener las tres piezas. La documentación de Google es explícita sobre qué pasa si no se cumple: «Es posible que los mensajes que no se hayan autenticado con estos métodos se marquen como spam o se rechacen».

Un hotel manda confirmaciones de reserva, recordatorios de llegada, facturas y promociones de temporada. Si su dominio no está autenticado, una parte de ese correo —correo legítimo, que el huésped está esperando— termina en la carpeta de no deseados.

Y lo peor de esta consecuencia es que es invisible por los dos lados. El hotel cree que mandó la confirmación. El huésped cree que nunca llegó. Nadie se entera hasta que alguien llama a preguntar.

Dos problemas distintos, y sólo uno es tuyo

Conviene separar lo que se suele mezclar, porque la respuesta es diferente para cada mitad.

El acceso a los datos de reserva ocurre dentro del sistema de reservas, y muchas veces no en el tuyo sino en el de tu proveedor. La Agencia española es explícita sobre qué toca hacer ahí: exigir autenticación de doble factor efectiva, y seleccionar únicamente proveedores que puedan garantizar un nivel de seguridad adecuado. Eso se resuelve en el contrato y en la configuración de esa plataforma.

Que el mensaje fraudulento parezca tuyo depende de algo que controlas por completo. Son tres registros de texto en la configuración de tu dominio. No cuestan dinero, no requieren cambiar de proveedor, y quien te administra el dominio los publica en una tarde.

Una advertencia sobre cómo publicarlos, porque es donde está el 34% a medias: no se empieza en p=reject . Se publica primero en p=none para recibir informes durante dos o tres semanas, se revisa qué remitentes legítimos aparecen —siempre hay uno que se olvida: el que factura, el que manda el boletín, el formulario del sitio— y con esa lista en la mano se sube a quarantine y después a reject . Lo que no puede pasar es quedarse en el primer paso para siempre, que es justo lo que le ocurrió a un tercio de la muestra.

Hay un frente parecido que también conviene mirar: los dominios registrados a propósito para parecerse al tuyo. Basta cambiar una letra o agregar un guion para tener una dirección que a simple vista es idéntica, y desde ahí escribir con impunidad, porque técnicamente ese correo sí sale de un dominio legítimo. Cerrar tu propio dominio no impide que alguien registre uno parecido, pero sí te permite saber cuáles existen y cuáles ya tienen correo configurado, que son los que importan.

Lo que aplica en México

La obligación no es ajena ni opcional. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente se publicó en el Diario Oficial de la Federación el 20 de marzo de 2025 y se reformó el 14 de noviembre del mismo año. Aplica a cualquier empresa privada que trate datos personales, sin mínimo de tamaño.

Un hotel de doce habitaciones que guarda el nombre, el teléfono y la identificación de quien se hospeda está tratando datos personales exactamente igual que una cadena de cien. La diferencia entre los dos no está en la obligación, sino en cuánta atención han podido dedicarle.

A la luz del 88.5%, ese margen de atención es el que hay que recuperar.

Qué revisar esta semana

Tres preguntas concretas:

¿Tu dominio tiene publicados SPF, DKIM y DMARC, y el DMARC está en una política que de verdad rechace y no sólo observe? ¿Existen dominios registrados por terceros que se parezcan al tuyo, y alguno tiene correo configurado? ¿Tu proveedor de reservas ofrece autenticación de doble factor, y la tienen activada todas las personas con acceso?

Las dos primeras se responden consultando registros públicos, sin permiso de nadie y sin instalar nada. Publicamos una herramienta gratuita que hace exactamente esa revisión y entrega el resultado en un informe legible: Ciber-Scan. Es gratuita, no pide registro y tarda dos minutos. Es la misma consulta que hicimos para este artículo, aplicada a tu dominio.

La tercera no la contesta ninguna herramienta. Ésa se contesta llamando a tu proveedor, y conviene hacerlo antes de temporada alta.

Cómo se hizo esta medición

Se partió de 950 dominios de hoteles en México, obtenidos de fichas públicas de Google en 18 ciudades agrupadas en cuatro tipos de destino: playa, ciudades coloniales y Pueblos Mágicos, ciudades grandes, y frontera y negocios. Se excluyeron desde el origen las cadenas internacionales, cuyos dominios corporativos no reflejan la situación de un establecimiento mexicano.

De esos 950 se excluyeron 237, por estas razones:

• 150 sin registros MX. Un dominio que no maneja correo propio no está expuesto al fraude que este artículo describe, y contarlo inflaría el resultado.
• 29 dominios muertos, que no existen o no resuelven. Que un dominio abandonado no tenga DMARC no prueba nada.
• 15 cadenas, mexicanas e internacionales, entre ellas airbnb.es , belmond.com , rosewoodhotels.com , vidanta.com , elcid.com y los cuatro dominios del grupo Kavia. Operen donde operen, no son establecimientos independientes.
• 6 dominios de corporativos extranjeros. El hotel está en México, pero el dominio medido pertenece a la matriz en Singapur, Estados Unidos o Reino Unido, y su configuración la decide un equipo fuera del país.
• 16 direcciones que no son de un hotel: el directorio público listaba en el campo «sitio web» el dominio del software de reservaciones, de un directorio, de un servicio gratuito de páginas o de enlaces, o, en dos casos, de la institución dueña del inmueble (un centro de investigación y un museo).
• 6 rentas vacacionales e inmobiliarias, que no son establecimientos de hospedaje.
• 15 dominios en TLD de bajo costo ( .top , .site , .online ), agrupados en patrones que sugieren páginas creadas por un tercero y no el dominio propio del hotel.

Quedaron 713 dominios de hoteles mexicanos independientes que operan y manejan su propio correo, que es la población sobre la que se calculan todos los porcentajes de este artículo.

La depuración se hizo cruzando el nombre del negocio contra el dominio para detectar marcas repetidas, sin consultar los sitios web. Como prueba de robustez: quitar los 55 dominios detectados en esa segunda auditoría mueve el porcentaje de expuestos del 87.8% al 88.5%, siete décimas. El resultado no depende de dónde se trace esa frontera.

De cada uno se consultaron únicamente dos registros DNS públicos: el registro TXT de _dmarc y el registro SPF del dominio. La consulta se hizo el 22 de septiembre de 2026.

Las 35 cadenas de la comparación son los dominios corporativos que el muestreo había apartado por no ser establecimientos independientes. Se midieron con el mismo procedimiento, el mismo día y el mismo criterio: sólo las que manejan correo propio.

Para confirmar que se trata de negocios en operación y no de dominios abandonados, se comprobó además que el servidor de correo anunciado por cada dominio exista: 699 de los 713 (98.0%) tienen un servidor de correo que resuelve. El 48.0% lo tiene contratado con un proveedor identificable —Google Workspace, Microsoft 365, GoDaddy, Titan o Zoho—, es decir, un buzón que alguien paga y administra.

Calculando únicamente sobre esos 699, el porcentaje de expuestos es 88.4%, prácticamente el mismo: el resultado no depende de los casos dudosos.

No se accedió a ningún sistema, no se envió ninguna petición a los sitios web de los hoteles y no se contactó a ningún establecimiento. Los registros DNS son públicos por diseño: son los mismos que consulta cualquier servidor de correo del mundo cada vez que recibe un mensaje.

Se clasificó como «protegido» únicamente al dominio con DMARC en política quarantine o reject . La política none se contabiliza aparte, porque publica el registro sin bloquear nada.

No se publica el nombre de ningún hotel, y la lista no se comparte con nadie. Todos los resultados de este artículo son agregados.

Esto no es una formalidad. Una relación de establecimientos que no pueden impedir que los suplanten es, leída al revés, una lista de objetivos. Publicarla o repartirla causaría exactamente el daño que este artículo busca evitar, así que no se publica, no se vende y no se entrega a terceros. La única excepción que contempla la práctica responsable es informar a un establecimiento de su propio resultado, nunca del ajeno.

Por eso el artículo cierra con una herramienta y no con una lista: cada hotel puede consultar su propio dominio cuando quiera, y ese resultado es suyo.

Fuentes

• Agencia Española de Protección de Datos, Notificaciones de brechas de datos personales, julio de 2026, División de Innovación Tecnológica.
• Google, Directrices para remitentes de correo electrónico, requisitos vigentes desde el 1 de febrero de 2024.
• Cámara de Diputados, Ley Federal de Protección de Datos Personales en Posesión de los Particulares, DOF 20-03-2025, última reforma DOF 14-11-2025.