Cualquiera puede escribir un correo que parezca de tu hotel. Impedirlo son tres renglones de texto.

Nadie va a despertarse un día y decidir suplantar a tu hotel en particular. Eso es lo que casi todo el mundo se imagina, y por eso casi nadie se preocupa.

Lo que de verdad ocurre es más mecánico, y justamente por eso es más probable.

En septiembre de 2026 consultamos los registros públicos de 713 hoteles independientes mexicanos en 18 ciudades, y publicamos el resultado en el blog de FETUR, la Federación de Empresarios Turísticos. El 88.5% no podía impedir que alguien mandara correos en su nombre. Las cadenas, medidas el mismo día y con el mismo método, salieron en 37.1%. La diferencia no es de presupuesto: las tres piezas que cierran el problema no cuestan dinero.

Este artículo es lo que sigue a ese estudio: qué son esas tres piezas, en qué orden se publican, y qué pedirle exactamente a quien te lleva los sistemas.

Pero antes conviene entender por qué el riesgo no depende de que alguien se fije en ti.

Los registros que dicen si un dominio está protegido son públicos. Tienen que serlo: son los que consulta cualquier servidor de correo del mundo cada vez que recibe un mensaje tuyo. Y se pueden consultar uno por uno o a miles, sin permiso de nadie, sin entrar a ningún sistema y sin tocar el sitio de nadie.

Los 713 del estudio los consultamos en seis segundos. Ciento catorce por segundo, desde una computadora común.

Que esa consulta esté al alcance de cualquiera es justamente lo que hace que el problema exista. No hace falta ser un experto. Alguien que apenas empieza en esto puede recorrer miles de dominios en una tarde, sin entrar a ningún sistema y sin necesitar una sola contraseña, y quedarse con la lista de los que sí sirven.

Interpretarla ya es otra cosa. Saber qué registros pedir, distinguir un dominio protegido de uno que sólo lo parece, y sacar de la cuenta a los que ni siquiera manejan correo propio. De los 950 dominios con los que empezamos, 237 tuvieron que salir por razones de ese tipo antes de que el porcentaje significara algo. Ese es el trabajo que convierte una consulta de seis segundos en un dato del que uno puede responder.

Quien busca dominios para suplantar hace la consulta fácil, con otra intención: recorre listas y se queda con los que no tienen protección. No investiga tu hotel. Comprueba una casilla. Si tu dominio pasa ese filtro, entra a la lista de los que sirven, junto con otros miles.

Y entonces pueden escribirle a tus huéspedes con tu dirección de remitente. El mensaje llega a la bandeja de entrada como cualquier otro correo tuyo, porque no hay nada que lo desmienta. No necesitaron entrar a tu correo, ni robar tu contraseña, ni saber nada de tu hotel más que su dirección.

Ese correo tiene nombre: phishing, que es el intento de engañar a alguien haciéndose pasar por quien no se es, casi siempre para que pague algo o entregue un dato. Cuando además el remitente es de verdad el tuyo, el huésped no tiene de dónde agarrarse para dudar.

Y aquí conviene una precisión que casi nadie hace, porque marca lo que estas tres piezas pueden y no pueden hacer por ti. Lo que cierras no es el phishing: es la suplantación de tu dominio, que es lo que lo vuelve creíble. A tus huéspedes les pueden seguir escribiendo desde una cuenta de Gmail o desde un dominio parecido al tuyo, y eso no lo detiene ningún registro que publiques. Lo que dejas de regalar es tu nombre.

Dónde viven estas tres cosas (y por qué tu proveedor de sitio web no tiene nada que ver)

Antes de las definiciones, una aclaración que ahorra semanas de confusión.

Las tres piezas no van en tu página web. Van en la configuración de tu dominio, en un lugar llamado DNS, que es la libreta pública donde tu dominio declara cosas sobre sí mismo: a qué servidor va tu página, a qué servidor va tu correo, y quién puede escribir en tu nombre.

Eso importa porque casi siempre son tres empresas distintas: quien te vendió el dominio, quien administra el DNS, y quien te da el correo. Pueden ser la misma, pero no lo asumas. La pregunta correcta a tu proveedor no es «¿puedes arreglarme el correo?», sino «¿tú administras mi DNS?». Si la respuesta es no, te va a mandar con quien sí, y te ahorras dos semanas de rebotes.

SPF: quién tiene permiso de enviar

SPF es una lista. Dice qué servidores están autorizados a mandar correo con tu dominio.

Cuando un servidor recibe un mensaje que dice venir de tu hotel, consulta esa lista y comprueba si el servidor que se lo entregó está en ella. Si no está, es señal de que algo no cuadra.

Qué pedir: un registro TXT con la lista de tus servidores de correo.

Y aquí está el detalle que casi nadie te dice: termínalo en ~all, no en -all.

Esa diferencia de un carácter cambia lo que le dices al servidor que recibe, sobre un remitente legítimo que se te olvidó incluir. Con -all estás afirmando que ese servidor no está autorizado, punto. Con ~all dices algo más suave: probablemente no es mío, trátalo con sospecha.

La norma que define SPF -el RFC 7208, que es el documento técnico donde está especificado y que citamos al final- no obliga a rechazar en ninguno de los dos casos: deja la decisión en manos de quien recibe. Pero recomienda expresamente no rechazar basándose sólo en un ~all, y no dice lo mismo de -all. En la práctica, el correo de un remitente olvidado tiene muchas más probabilidades de llegar con ~all que con -all.

Y siempre hay uno que se olvida. El sistema que manda las confirmaciones de reserva. El que emite las facturas. El formulario de contacto del sitio. La plataforma del boletín. Empezar en -all es la forma más rápida de que tus propias confirmaciones dejen de llegar mientras todo el mundo jura que no cambió nada.

Y si se rechaza, casi siempre se genera un aviso de rebote. El problema es a quién le llega: no a ti, sino a la plataforma que mandó el mensaje. Por eso este tipo de falla puede pasar semanas sin que nadie en el hotel se entere.

Ahora, una advertencia que casi nunca se dice y que importa más que la elección entre ~all y -all. Ese margen del ~all sólo te protege mientras tu DMARC no esté bloqueando. En cuanto lo subas a p=reject, deja de servirte: para DMARC un ~all no cuenta como aprobado, sólo cuenta un pass. El remitente olvidado se va a rechazar igual, lleve ~all o -all.

Por eso el paso que de verdad te protege no es el carácter final del SPF. Es leer los reportes de DMARC antes de subir la política, que es justo de lo que trata la siguiente sección.

DKIM: la firma que va dentro del mensaje

DKIM es una firma invisible que tu servidor le pone a cada correo que sale. El servidor que lo recibe puede comprobarla contra una llave que tú publicas en tu DNS.

Si el mensaje se modificó en el camino, o si salió de un servidor que no tiene tu llave, la firma no cuadra.

Qué pedir: que tu proveedor de correo active la firma DKIM y te dé la llave para publicarla. En los proveedores grandes es una casilla en el panel de administración y un registro que copiar. No se programa nada.

Si usas Google Workspace o Microsoft 365, esto ya existe en tu cuenta; lo que suele faltar es que alguien lo encendiera.

DMARC: la instrucción de qué hacer cuando no cuadra

Las dos anteriores sirven para comprobar. DMARC es la que decide.

Le dice al servidor que recibe qué hacer con un correo que dice venir de ti pero no pasa esas comprobaciones. Tiene tres respuestas posibles:

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

Y aquí está el hallazgo más incómodo del estudio. El problema más grande no fue el 54.7% que no tenía nada. Fue el 33.8% que sí tenía DMARC publicado, pero en modo observación. Alguien en esos hoteles se tomó la molestia de configurarlo y se quedó a medias. Si alguien audita, encuentra el registro y lo da por bueno. Pero un DMARC en p=none no rechaza absolutamente nada: es un letrero que pide reportes. Quien lo tiene así está, para efectos de quien quiera suplantarlo, en la misma situación que quien no publicó nunca nada.

El orden importa, y es la parte que la gente se salta

Leído lo anterior, la reacción natural es pedir p=reject de una vez. No lo hagas.

p=reject le ordena al mundo rechazar todo correo que no pase las comprobaciones, incluido el tuyo si se te olvidó incluir un remitente. Ponerlo el primer día es la forma más eficiente de que dejen de llegar tus confirmaciones de reserva.

La secuencia que funciona tiene tres pasos:

Lo que no puede pasar es quedarse en el paso uno para siempre. Eso es exactamente lo que le ocurrió a un tercio de los hoteles medidos. p=none no es una política: es una etapa. Si lleva más de dos meses ahí, alguien publicó el registro y se olvidó de volver.

El caso de los dos dominios, que es más común de lo que parece

Muchos hoteles tienen el sitio en un dominio y el correo en otro. A veces porque el sitio se hizo en .com y el correo quedó en .com.mx. A veces porque cambiaron de nombre comercial y conservaron el dominio viejo sólo para los buzones. A veces porque el sitio lo maneja una agencia y el correo lo maneja el hotel.

Si es tu caso, la pregunta que decide todo es cuál de los dos aparece después de la arroba en tu dirección de correo. Ése es el que un servidor comprueba cuando recibe un mensaje tuyo, y ése es el que lleva SPF, DKIM y DMARC tal como los explicamos arriba.

Pero el otro dominio no se queda sin trabajo. Se queda con el trabajo contrario.

Un dominio que no manda correo se blinda al revés

Aquí está lo que casi nadie hace, y es la parte que da nombre a esta sección.

Un dominio del que no sale correo legítimo también se puede usar para suplantarte. Nada impide que alguien escriba desde tu dominio del sitio web aunque tú nunca lo hayas usado para eso. Y como nadie vigila un dominio del que no sale correo, es el que menos probabilidades tiene de que alguien note el abuso.

Lo medimos. De los 150 dominios de hoteles que no manejan correo propio en nuestra muestra, 145 podían ser suplantados: el 96.7%. Peor que los que sí mandan correo, que salieron en 88.5%. Sólo cinco de 150 lo tenían cerrado.

La configuración correcta para un dominio que no manda ni recibe correo no es listar servidores: es declarar que no hay ninguno legítimo. Son tres registros:

Por qué aquí sí va -all y arriba no

Esto parece contradecir lo que dijimos en la sección de SPF, y conviene decirlo de frente porque es la duda que le va a saltar a quien te lleve los sistemas.

Arriba recomendamos terminar en ~all y no en -all. La razón era que siempre hay un remitente legítimo que se olvida, y con -all ese correo tiene muchas más probabilidades de rechazarse mientras completas la lista.

En un dominio que no manda correo esa razón desaparece. No hay remitente que olvidar, porque no hay ninguno. Cualquier mensaje que diga venir de ahí es falso por definición, y lo correcto es rechazarlo.

La regla, entonces, es simple: el dominio que envía se cierra con cuidado y por pasos. El que no envía se cierra de golpe, porque no hay nada que romper.

Los dominios parecidos, que son el otro frente

Cerrar tu dominio no impide que alguien registre uno que se le parezca. Basta cambiar una letra, agregar un guion o mover un punto para tener una dirección que a simple vista es idéntica a la tuya.

Desde ahí pueden escribirle a tus huéspedes con impunidad, porque técnicamente ese correo sí sale de un dominio legítimo: el suyo. Tu SPF y tu DMARC no aplican, porque no es tu dominio.

Lo que sí puedes hacer es saber cuáles existen. Y sobre todo, cuáles de ellos ya tienen correo configurado, que son los que importan: un dominio parecido sin servidor de correo es una curiosidad, y uno con servidor de correo es una operación esperando arrancar.

Lo que hay que reenviar

Esta es la parte práctica, y está escrita para que la copies y la pegues en un correo a quien te lleva los sistemas.

Si te contestan que ya está, pide que te enseñen el registro _dmarc y qué política tiene. Si dice p=none, no está: está a medias.

Un costo que casi nadie conecta con esto

Hay una segunda razón para hacerlo, y es la que suele mover a quien no se preocupa por la suplantación.

Gmail dejó de aceptar correo sin autenticar. Desde febrero de 2024, quien le escribe a una cuenta de Gmail tiene que traer SPF o DKIM configurado, y quien manda volúmenes altos, las tres piezas. Google es explícito sobre el desenlace: los mensajes sin autenticar pueden terminar marcados como spam o directamente rechazados.

Piensa en todo lo que sale de un hotel en una semana. Confirmaciones, recordatorios de llegada, facturas, la promoción de temporada baja. Si el dominio no está autenticado, una parte de eso deja de llegar.

Lo cruel es que nadie se da cuenta. Recepción ve el mensaje en «enviados» y da el asunto por cerrado. El huésped no recibe nada y supone que el hotel no contestó. La falla no produce ningún error: produce silencio, y el silencio se descubre semanas después, en una llamada molesta.

Cómo saber en qué estás hoy

Las tres piezas se publican en registros públicos. Eso significa que puedes consultar el estado de tu propio dominio sin instalar nada, sin dar una contraseña y sin permiso de nadie: es la misma consulta que hace cualquier servidor de correo del mundo cada vez que recibe un mensaje tuyo.

Publicamos una herramienta gratuita, Ciber-Scan, que hace exactamente esa revisión y te entrega el resultado en un informe legible, escrito en dos capas: el nombre técnico exacto para quien va a reparar, y qué significa para tu negocio para quien va a decidir. Tarda dos minutos y no pide registro.

Es la misma consulta que usamos para medir los 713 hoteles, aplicada a tu dominio.

Y si tienes más de un dominio, córrela en todos. El que menos sospechas suele ser el que está más abierto.