Octubre es el Mes de Concienciación sobre la Ciberseguridad (Cybersecurity Awareness Month) en Estados Unidos y el Mes Europeo de la Ciberseguridad en la UE. La campaña de 2026 de la agencia estadounidense CISA, «Securing the Next 250», sitúa en primer lugar, entre sus cuatro pasos básicos, evitar y denunciar las estafas de phishing. En la UE, una encuesta Eurobarómetro publicada por la Comisión Europea el 30 de septiembre de 2026 reveló que tres de cada cuatro empleados se habían encontrado con correos electrónicos, mensajes o enlaces sospechosos en el trabajo durante los seis meses anteriores a la encuesta.
El sitio web, el correo electrónico y los accesos de los clientes de una empresa dependen de sus nombres de dominio, y cinco parámetros determinan si esos nombres pueden ser secuestrados, perderse o ser suplantados.
¿Quién controla sus dominios?
Quien tiene en su poder la cuenta en el registrador y la ficha del titular, así que compruebe ambas cosas: el bloqueo de cada nombre y los datos de contacto que lo respaldan.
¿Está su dominio bloqueado contra las transferencias?
Debería estarlo. En .com y en muchas extensiones de código de país, los datos públicos del dominio lo muestran: el bloqueo del registrador aparece como el código de estado clientTransferProhibited, que, como explica la ICANN, indica al registro que rechace las solicitudes de traslado del dominio a otro registrador. Los códigos clientUpdateProhibited y clientDeleteProhibited hacen lo mismo con las modificaciones y la eliminación.
Algunos registros no publican ningún estado de bloqueo, por ejemplo nic.at para .at y DENIC para .de. En esos casos, pregunte a su registrador cómo se autoriza una transferencia.
El bloqueo de registro (registry lock) va más allá. Los códigos que empiezan por server, como serverTransferProhibited, los fija el registro, y algunos registros los ofrecen como un servicio de bloqueo que solo se levanta cuando el registrador lo solicita al registro. Pregunte a su registrador cuáles de sus nombres pueden tenerlo.
Para comprobarlo, consulte el dominio en nuestra búsqueda whois, que muestra los códigos de estado de hasta 20 nombres a la vez, cuando el registro los publica. Después, compruebe quién puede levantar el bloqueo: la ICANN aconseja a los titulares activar la autenticación multifactor en su cuenta del registrador cuando esté disponible.
¿Son exactos los datos del titular y del contacto administrativo?
Deben designar a la empresa propietaria de la marca, con direcciones y números que ella controle. Los registros de la UE han empezado a verificar estos datos en virtud de las leyes nacionales que transponen la Directiva NIS2. EURid publicó una política de verificación para .eu en octubre de 2024, y la ley austriaca NISG 2026 entró en vigor el 1 de octubre de 2026: los titulares de .at deben facilitar ahora un número de teléfono además de una dirección de correo electrónico, y colaborar cuando se les pida que verifiquen sus datos.
El registro austriaco advierte de que la falta de pruebas o su entrega tardía puede llevarle a eliminar el dominio. Según sus preguntas frecuentes sobre NIS2, un dominio cuyos datos no se verifiquen en 21 días pasa a serverHold, lo que detiene su sitio web y su correo electrónico, y se revoca si los datos no se corrigen en los 30 días siguientes.
Desde el 1 de octubre, nic.at también publica en el whois el número de teléfono y la dirección de correo electrónico de los titulares que son empresas, datos que estas podían ocultar hasta entonces, por lo que recomienda una dirección y un número centrales en lugar de los de un empleado.
Los avisos de caducidad y las solicitudes de verificación se envían a estos contactos. Un dominio a nombre de un antiguo empleado, una agencia o una filial es difícil de renovar, trasladar o defender, y una dirección de contacto alojada en un dominio que caduca puede caer en manos de quien registre ese dominio. Para comprobarlo, pida a su registrador los datos completos de cada dominio, ya que el whois público suele ocultar los datos del titular, y compare el titular con la denominación social de la empresa.
¿Quién recibe los avisos de caducidad de sus dominios?
La dirección de correo electrónico del titular. En las extensiones genéricas, la política de recuperación de registros caducados (ERRP) de la ICANN obliga a los registradores a enviar al menos dos recordatorios, aproximadamente un mes y aproximadamente una semana antes de la caducidad, y otro en los cinco días siguientes a la caducidad si el nombre no se ha renovado ni eliminado. Todos ellos se envían a la dirección de correo electrónico del titular que figura en los datos de contacto.
Tras la caducidad, un registrador puede ofrecer un periodo de gracia de renovación automática de 1 a 45 días. Una vez eliminado un dominio genérico, el registro debe ofrecer un periodo de gracia de recuperación (Redemption Grace Period) de 30 días, durante el cual el titular puede restaurarlo a través del registrador, posiblemente previo pago de una tarifa. El DNS se corta antes de la eliminación y durante el periodo de recuperación, por lo que el sitio web y el correo electrónico dejan de funcionar, incluidos los buzones del propio dominio. Los registros de código de país fijan sus propias reglas.
Para comprobarlo, active la renovación automática de todos los nombres en uso, mantenga registrado un medio de pago válido, envíe los avisos a un buzón compartido en otro dominio y anote las fechas de caducidad de los próximos doce meses.
¿Pueden suplantarse sus dominios?
Sí, en el DNS y en el correo electrónico, salvo que la zona esté firmada con DNSSEC y cada dominio publique SPF y DMARC.
¿Está activado DNSSEC y sigue coincidiendo?
Debería estarlo siempre que el registro lo admita, con un registro DS publicado por el registro que siga coincidiendo con una clave de su zona. Sin DNSSEC, explica la ICANN, un resolutor no puede verificar que una respuesta DNS sea auténtica, y un atacante que envenene su caché puede enviar a los usuarios a una copia de su sitio.
Nuestra comprobación de zona DNS lee el registro DS que publica el registro y las claves de su zona, e indica si coinciden, sin verificar las firmas. Una clave ausente o distinta hace que el dominio falle para los resolutores que validan DNSSEC, así que realice la comprobación tras cada cambio de proveedor DNS. No todos los registros admiten DNSSEC: nuestra página de gestión DNS explica cómo lo gestionamos.
La raíz del DNS tuvo su propia fecha este mes. La ICANN previó que KSK-2024, la nueva clave de firma de claves de la zona raíz, asumiera la firma el 11 de octubre de 2026. Un resolutor que no confíe en ella (etiqueta de clave 38696) trata las respuestas firmadas con la nueva clave como manipuladas, por lo que todas las consultas fallan, como explican las preguntas frecuentes de la ICANN. Si su empresa gestiona sus propios resolutores con validación, compruebe que la tienen, tal como pide la página de la ICANN sobre el cambio de clave.
¿Autentican el correo todos sus dominios, incluidos los que no envían ninguno?
Deberían, porque un dominio que no envía correo puede suplantarse con la misma facilidad que uno que sí lo envía. SPF enumera los servidores autorizados a enviar su correo, DKIM firma cada mensaje y DMARC indica a los servidores receptores qué hacer con el correo que no supera la verificación.
El National Cyber Security Centre (NCSC) del Reino Unido advierte de que un registro defensivo no protege un dominio por sí solo, y aconseja proteger primero los dominios que no envían correo, porque una vez protegidos no requieren mantenimiento. Enumera cuatro registros DNS, que deben configurarse en este orden:
- SPF sin remitentes autorizados: v=spf1 -all;
- DMARC en _dmarc con una política de rechazo: v=DMARC1; p=reject, más una dirección de informes para detectar los abusos;
- un registro MX nulo, 0 ., cuando el dominio tiene un registro de dirección pero ningún servidor de correo;
- opcionalmente, un registro DKIM comodín con una clave vacía, que revoca cualquier clave almacenada en caché.
Para los dominios que envían correo, el plan de implantación del NCSC empieza DMARC con una política none, que solo recopila informes, pasa a quarantine cuando todos los remitentes legítimos superan la verificación y, después, a reject. La comprobación de zona muestra los registros SPF y DMARC de cualquier dominio. Las claves DKIM se encuentran bajo un selector que define su plataforma de correo, así que compruébelas allí.
¿Qué debe hacer ahora?
Realice las cinco comprobaciones en todos los dominios de los que sea titular y, después, defina para cada una cuándo repetirla.
| Parámetro | Cómo comprobarlo | Cuándo volver a comprobarlo |
|---|---|---|
| Bloqueo de transferencia y acceso a la cuenta | Códigos de estado whois, cuando el registro los publica; usuarios de la cuenta del registrador y autenticación multifactor | Cuando se marcha alguien con acceso a la cuenta |
| Datos de contacto | Datos completos facilitados por el registrador, cotejados con los datos legales de la empresa | Tras una reorganización y ante cualquier solicitud del registro |
| Renovación y caducidad | Renovación automática, medio de pago, dirección de los avisos, fechas de caducidad | Un mes antes de cada fecha de caducidad |
| DNSSEC | Comprobación de zona: el registro DS coincide con una clave de la zona | Tras cada cambio de proveedor DNS |
| SPF, DKIM, DMARC | Comprobación de zona; plataforma de correo para DKIM; informes DMARC | Cuando se añade o se retira un servicio que envía correo en su nombre |
Domgate registra y gestiona dominios de código de país para titulares de marcas y sus asesores. Publica los registros SPF, DKIM y DMARC y lleva la política DMARC hasta reject paso a paso. Su auditoría de estrategia global de nombres de dominio enumera cada nombre con su titular, sus contactos y su fecha de caducidad, y después fija reglas de renovación y de seguridad, incluido un bloqueo de registro cuando la extensión lo ofrece.
