Autenticación de correo electrónico en las mayores empresas de IA del mundo

El sector de la inteligencia artificial ha dedicado dos años a facilitar a todo el mundo la suplantación de identidad digital de forma convincente. Decidimos comprobar hasta qué punto las empresas líderes mundiales en IA protegen sus propios dominios corporativos frente a esos mismos riesgos de suplantación de identidad. El 6 de agosto de 2026, realizamos pruebas en tiempo real de consultas DNS recursivas en ocho protocolos fundamentales de seguridad del correo electrónico para 30 importantes empresas de IA.

La conclusión principal es sencilla. Todas y cada una de las empresas han implementado la capa básica de autenticación del correo electrónico. Las 30 publican registros SPF y DMARC, y al menos 28 confirman el uso de DKIM. Sin embargo, más allá de estos aspectos básicos, el nivel de seguridad se desploma. Solo dos de las treinta empresas publican MTA-STS. Solo seis firman sus registros DNS con DNSSEC, y 19 siguen teniendo sus registros SPF configurados en «softfail».

Ninguna de las empresas dedicadas exclusivamente a la IA incluidas en nuestro análisis publica MTA-STS. Las únicas dos empresas del análisis que lo hacen son Google y Microsoft.

Esto hace que todas las empresas emergentes de IA de este grupo sean vulnerables a los ataques de degradación y a la interceptación del tráfico en tránsito, incluso aunque sus registros DMARC superen la verificación.

Comprueba la seguridad de tu dominio

¿Quieres saber cuál es la situación de tu propio dominio? Comprueba la configuración de tu dominio en tiempo real con el Analizador de dominios de PowerDMARC mientras exploras el conjunto completo de datos de referencia.

Qué hemos medido y cómo

Nuestra muestra de investigación abarca 30 organizaciones importantes del ámbito de la IA: OpenAI, Anthropic, Google, DeepMind, Microsoft, Meta AI, NVIDIA, Amazon, Apple, IBM, xAI, Mistral, Cohere, Perplexity, Hugging Face, Stability AI, Midjourney y Character.AI, ElevenLabs, Runway, Databricks, Scale AI, DeepSeek, Cursor, Replit, Groq, Together AI, Cerebras, Writer y Glean. Evaluamos el dominio principal corporativo de cada entidad el 6 de agosto de 2026; Google y DeepMind se consideran dominios principales independientes a lo largo de este informe.

Hemos evaluado ocho protocolos y parámetros específicos: configuración del registro SPF, presencia del selector DKIM, implementación de la política DMARC, validación DNSSEC, MTA-STS, TLS-RPT, BIMI (indicadores de marca para la identificación de mensajes) y proveedores de servicios MX. Realizamos consultas a resolutores recursivos públicos (1.1.1.1, 8.8.8.8, 9.9.9.9, 8.8.4.4) con EDNS0 habilitado y llevamos a cabo entre tres y cuatro reintentos por registro. Los registros TXT de SPF en el nodo raíz se recuperaron utilizando DNS sobre HTTPS para evitar problemas de recambio a TCP/53 en conjuntos de registros TXT de gran tamaño. Los recuentos de búsquedas recursivas de SPF se calcularon estrictamente según lo establecido en la sección 4.6.4 del RFC 7208.

Para garantizar la total transparencia de esta investigación, señalamos seis limitaciones analíticas claras:

• Límites de la comprobación de DKIM: Los selectores DKIM no pueden enumerarse mediante consultas DNS estándar. Nuestro recuento de 28 de un total de 30 representa un límite inferior. Por ejemplo, meta.com no devolvió ningún resultado tras comprobar más de 100 selectores, lo que indica que se trata de un selector personalizado y no de una falta de DKIM.
• Comodines: databricks.com utiliza un comodín de DNS bajo _domainkey. Cualquier consulta de selector se resuelve, por lo que no tiene sentido contar el número exacto de selectores. Hemos registrado esta configuración como un hallazgo de comodín.
• Ámbito de análisis: Solo hemos analizado los dominios principales de las empresas. No se han evaluado los subdominios dedicados al marketing o a las transacciones.
• Fallos de DNS en las inclusiones secundarias: amazon.com depende de spf3.amazon.com, cuya resolución falló debido a su tamaño. El total de cuatro consultas registradas por Amazon sirve como referencia mínima.
• Ámbito temporal: Las configuraciones del DNS cambian. Estos datos reflejan una instantánea en tiempo real del 6 de agosto de 2026.
• Postura frente a brecha: una política de autenticación más flexible refleja una postura más débil frente a la suplantación de identidad. Esto no implica una brecha de seguridad ni una negligencia operativa.

Cada dato de este informe puede verificarse de forma independiente mediante los comandos «dig» estándar con resolutores públicos.

Todos superan los requisitos básicos de autenticación del correo electrónico

Los protocolos de referencia gozan de una adopción generalizada en todo el sector de la IA. Las 30 empresas publican un registro SPF, las 30 publican un registro DMARC y 29 publican una dirección de informes agregados (rua) válida. El 90 % de la muestra aplica DMARC con el valor p=quarantine (12 empresas) o p=reject (15 empresas).

Sin embargo, el contexto es importante. Exactamente el 50,0 % de estas empresas líderes en IA aplican una política estricta de «p=reject». A modo de referencia, nuestro reciente informe sobre la adopción de DMARC y MTA-STS en Estados Unidos muestra una tasa de aplicación de «p=reject» del 49,0 % a nivel nacional. Las empresas de IA más valiosas del mundo se sitúan justo en la media nacional en cuanto a la aplicación básica de DMARC.

Si quieres entender qué hace realmente «p=reject», sirve como última barrera para bloquear los mensajes no autorizados antes de que lleguen a la bandeja de entrada. Tres empresas incluidas en la comparativa —Hugging Face, Stability AI y Cerebras— siguen con la configuración «p=none», que supervisa el tráfico sin bloquear los correos falsificados.

Matriz de adopción de protocolos (muestra de 30 empresas líderes en IA)

Fuente: Estudio sobre DNS en tiempo real de PowerDMARC (6 de agosto de 2026)

Solo dos de treinta publican MTA-STS

Aunque la verificación básica de dominios está muy extendida, la seguridad en la capa de transporte presenta una situación muy diferente. De los 30 líderes del mercado, solo Google y Microsoft publican registros RFC 8461 MTA-STS (Mail Transfer Agent Strict Transport Security) y TLS-RPT (SMTP TLS Reporting). Ninguna startup especializada en IA ni ningún proveedor de hardware especializado publica estos registros. Nuestra guía explicativa sobre MTA-STS detalla exactamente cómo funciona el protocolo.

DMARC y MTA-STS resuelven problemas totalmente distintos dentro de la estructura de seguridad. DMARC autentica la identidad del remitente para evitar la suplantación de encabezados. MTA-STS garantiza que las conexiones entre servidores de correo se realicen mediante TLS cifrado para evitar la interceptación de tipo «hombre en el medio» y los ataques de degradación. Ninguno de los dos protocolos sustituye al otro.

Para ser justos, una tasa de adopción del 6,7 % en esta muestra sigue superando el 1,7 % de referencia nacional que se recoge en nuestro estudio sobre EE. UU. La verdadera conclusión es de carácter estructural: las únicas empresas del ecosistema de la IA que garantizan la seguridad del transporte son los dos gigantes tecnológicos que gestionan plataformas globales de correo en la nube. Puedes comprobar el estado del cifrado de tu transporte con el verificador MTA-STS de PowerDMARC.

La brecha del DNSSEC: cómo incluir a todos los grandes actores del sector tecnológico en el ámbito de la IA

El DNSSEC (Extensiones de Seguridad del Sistema de Nombres de Dominio) proporciona una garantía criptográfica de que las respuestas del DNS no han sido falsificadas. Solo seis de las treinta empresas incluidas en nuestro estudio firman su zona corporativa con DNSSEC: Hugging Face, ElevenLabs, Databricks, Scale AI, Writer y Glean. Esto supone una tasa de adopción del 20,0 %, ligeramente superior al 18,0 % de la media nacional de EE. UU.

El dato más destacado es quiénes faltan. Ni una sola de las grandes empresas tecnológicas de nuestra muestra ha firmado su dominio corporativo principal con DNSSEC. Google, Microsoft, Meta, NVIDIA, Amazon, Apple e IBM dejan sin firmar su dominio de nivel superior.

Índices de adopción de protocolos: las 30 principales empresas de IA frente a los valores de referencia (2026)

Fuente: Investigación original de PowerDMARC (agosto de 2026) | Informe sectorial de Valimail 2026

La implementación incompleta de Stability AI

Nuestros análisis revelaron una brecha clásica de implementación en Stability AI. El dominio publica un registro DNSKEY válido dentro de su zona, pero carece del registro DS (firmante de delegación) correspondiente en el registrador principal. Dado que la cadena de confianza se rompe en el nivel superior, los resolutores de validación tratan la zona como si no estuviera firmada en absoluto. Parece una medida de protección sobre el papel, pero no ofrece ninguna seguridad a los usuarios finales.

El DNSSEC influye directamente en la seguridad del correo electrónico, ya que los registros SPF, DKIM y DMARC se transmiten a través del DNS sin cifrar. Sin la firma criptográfica de la zona, los atacantes pueden manipular las respuestas del DNS durante la transmisión para eludir por completo los controles del correo electrónico.

Diecinueve de treinta siguen sin superar la prueba SPF

Nuestra investigación revela que 19 de cada 30 empresas terminan su registro SPF con un calificador «~all» (softfail) en lugar de «-all» (hardfail). Solo nueve utilizan «hardfail», mientras que dos empresas (Meta y Writer) utilizan un mecanismo «redirect=».

Curiosamente, 10 de las 15 empresas que aplican el valor «p=reject» siguen utilizando «~all» en sus registros SPF. Esta lista incluye a Anthropic, Google, DeepMind, NVIDIA, Perplexity, Character.AI, Databricks, Replit, Groq y Glean. Puedes comprobar la sintaxis del registro SPF de tu dominio con la herramienta de consulta SPF de PowerDMARC.

En este contexto, es fundamental comprender la diferencia entre la sintaxis «softfail» y «hardfail» de SPF. Cuando un dominio aplica DMARC con p=reject, la política general de DMARC determina la entrega de los mensajes. Un «softfail» en SPF no supone un agujero de seguridad cuando DMARC está activo. Sin embargo, el uso de «-all» proporciona una señal explícita e inequívoca a los destinatarios que evalúan el SPF de forma independiente. Pasar de «softfail» a «hardfail» sigue siendo una forma sencilla de reforzar tu postura de seguridad.

Desglose de los candidatos a la clasificación SPF en p=rechazados (15 empresas)

Nadie ha superado el límite de consultas SPF… por ahora

La RFC 7208 establece un límite estricto de 10 consultas DNS para la evaluación del SPF. Superar este límite provoca un «PermError», lo que invalida por completo la comprobación del SPF. Ninguna de las 30 empresas supera el límite máximo de 10 consultas. Writer es la que más se acerca a ese límite, con 9 consultas, seguida de Perplexity, con 8. OpenAI, Microsoft y Cohere se sitúan en 7 consultas.

El registro SPF de OpenAI ofrece un magnífico ejemplo de las infraestructuras modernas de correo electrónico corporativo. Su cadena de inclusión abarca Google Workspace, Microsoft 365, HubSpot, Marketo y Oracle Cloud. Esa configuración utiliza siete consultas, lo que deja un margen de tres consultas. Añadir tan solo una herramienta de marketing externa más podría provocar un fallo operativo en su registro.

Margen de consultas DNS de SPF (empresas seleccionadas que se acercan al límite de 10 consultas)

Cinco empresas ya han externalizado la gestión del SPF

Gestionar las consultas manualmente resulta complicado cuando se trata de grandes volúmenes. Cinco empresas de nuestro estudio comparativo utilizan servicios especializados de terceros para gestionar su infraestructura SPF:

Cuatro de estas cinco organizaciones utilizan macros SPF en lugar de listas de IP fijas. Las macros SPF evalúan las conexiones entrantes de forma dinámica en el momento de la consulta, lo que las convierte en un estándar contrastado para redes corporativas complejas.

Las organizaciones que deseen eludir los límites de consultas sin necesidad de realizar un seguimiento manual pueden evaluar las soluciones SPF alojadas PowerSPF de PowerDMARC.

La configuración del autor pone de relieve la importancia de una implementación adecuada. Su mecanismo de redireccionamiento de terceros agota nueve de las diez consultas permitidas en un solo paso. El uso de un servicio SPF gestionado y alojado debería simplificar tu registro, no agotar casi todo tu presupuesto de consultas.

Tres divisiones siguen en fase de seguimiento

Hugging Face, Stability AI y Cerebras mantienen una política DMARC con el valor p=none. Esta configuración recopila informes de entrega sin proteger el dominio frente a posibles abusos. Los atacantes pueden enviar mensajes no autorizados utilizando estos nombres de dominio, y los servidores de correo receptores seguirán entregándolos con normalidad.

Esta decisión estratégica resulta especialmente destacable en el caso de Hugging Face, que actúa como centro neurálgico para la descarga de pesos de modelos de IA de código abierto. Un correo electrónico falso pero convincente procedente de Hugging Face podría engañar fácilmente a los desarrolladores y llevarles a descargar código o archivos de modelos comprometidos. Por otro lado, hay que reconocer a Hugging Face el mérito de ser una de las seis únicas empresas de nuestra muestra que ha firmado su dominio con DNSSEC.

Qué significa esto… y qué hay que solucionar

Estas recomendaciones de seguridad prácticas ofrecen una hoja de ruta específica para que las empresas de IA analizadas eliminen las vulnerabilidades de suplantación de identidad y protejan la reputación de sus dominios. La implementación de estos controles de autenticación de correo electrónico y DNS garantiza una verificación rigurosa del remitente, asegura el cifrado durante el tránsito y establece una supervisión operativa continua.

1. Alcanza el nivel de aplicación de DMARC: cambia tu política de «p=none» a «p=quarantine» y, a continuación, establece una fecha límite clara para pasar a «p=reject».
2. Requisitos de Harden SPF: Cambia el final de tu registro SPF de «~all» a «-all» una vez que tus informes agregados de DMARC confirmen que todos los remitentes legítimos coinciden.
3. Implementa MTA-STS y TLS-RPT: protege tu correo electrónico durante el tránsito. DMARC verifica la identidad del remitente, pero MTA-STS protege el cifrado del transporte entre servidores.
4. Activa DNSSEC correctamente: firma tu zona DNS y asegúrate de que tu registrador publique el registro DS correspondiente para completar la cadena de confianza.
5. Gestionar los límites de consultas SPF: Supervisa de cerca el número total de consultas DNS. Utiliza herramientas SPF alojadas basadas en macros para evitar alcanzar el límite máximo de 10 consultas.
6. Definir explícitamente los subdominios: Establece una política «sp=» explícita en tu registro DMARC para evitar que los atacantes suplanten la identidad de subdominios desprotegidos.
7. Asignar la responsabilidad operativa: Los controles técnicos requieren una supervisión periódica. Elige a un miembro del equipo que se encargue de revisar los informes DMARC cada semana.

Cómo subsanar las deficiencias en la autenticación del correo electrónico

Nuestro estudio de agosto de 2026 revela que las 30 principales empresas de IA han implementado los elementos fundamentales de la autenticación del correo electrónico: SPF, DKIM y DMARC están presentes en todas ellas. Sin embargo, la adopción se detiene en cuanto se van más allá de esos pasos iniciales. Solo dos publican MTA-STS, solo seis utilizan DNSSEC y diecinueve siguen recurriendo a registros SPF de «softfail».

El sector de la IA ha completado con éxito la fase inicial de configuración. El siguiente paso consiste en adoptar controles avanzados, como el cifrado de transporte y la firma de zonas, para subsanar las deficiencias restantes. Estas mejoras no requieren cambiar de proveedor, sino que solo exigen una mayor atención a los aspectos operativos.

¿Quieres saber cuál es la situación de tu dominio? Puedes comprobar tu propio dominio con el verificador gratuito de registros de dominio de PowerDMARC o explorar el paquete gratuito de herramientas de seguridad de PowerDMARC para reforzar la seguridad de tu correo electrónico. El phishing por correo electrónico sigue aumentando cada año, y las empresas que se mencionan aquí son precisamente el tipo de marcas que a los atacantes les gusta suplantar. Si prefieres analizar qué implican estas vulnerabilidades para tu propio dominio, puedes ponerte en contacto directamente con nuestro equipo.

Preguntas frecuentes

¿Utilizan DMARC las principales empresas de IA?

Sí, el 100 % de las 30 principales empresas de IA evaluadas en nuestro estudio publican un registro DMARC válido. Sin embargo, solo el 90 % aplica una política activa (cuarentena o rechazo), mientras que el 10 % permanece en modo de solo supervisión (p = ninguna).

¿Cuántas empresas de IA aplican DMARC con el valor p=reject?

Exactamente 15 de las 30 empresas (50,0 %) aplican DMARC con el parámetro p=reject. Este dato coincide con la media nacional actual de EE. UU., que se sitúa en el 49,0 % según los indicadores de referencia del sector en general.

¿Qué es MTA-STS y por qué DMARC no lo sustituye?

MTA-STS garantiza que las conexiones TLS estén cifradas para los correos electrónicos que se transmiten entre servidores. DMARC autentica la identidad del remitente para evitar la suplantación de direcciones. Ambos protegen diferentes partes del proceso de transmisión del correo electrónico, lo que significa que ninguno de los dos protocolos puede sustituir al otro.

¿Es importante el DNSSEC para la autenticación del correo electrónico?

Sí, DNSSEC protege tu dominio contra la suplantación de DNS y el envenenamiento de caché. Dado que los registros SPF, DKIM y DMARC se basan en consultas DNS, DNSSEC garantiza que dichos registros de políticas no puedan ser manipulados durante la transmisión.

¿Supone SPF ~all (softfail) un problema de seguridad?

No, si tu dominio aplica DMARC con los valores p=quarantine o p=reject. Cuando la aplicación de DMARC está activa, anula el «softfail». Sin embargo, cambiar a -all («hardfail») ofrece una señal de seguridad más sólida para los destinatarios que comprueban el SPF de forma independiente.

¿Cuál es el límite de consultas del SPF 10 y quién se está acercando a él?

La RFC 7208 limita las evaluaciones de SPF a 10 consultas DNS recursivas para evitar el uso indebido de los servidores. Si se superan las 10 consultas, se genera un PermError. En nuestro estudio, Writer ocupa el primer puesto con 9 consultas, seguido de Perplexity con 8.

¿Cómo se llevó a cabo esta investigación?

Los datos se recopilaron el 6 de agosto de 2026 mediante consultas DNS en tiempo real a resolutores recursivos públicos. Evaluamos los dominios «apex» corporativos de 30 empresas líderes en inteligencia artificial según ocho protocolos fundamentales de seguridad del correo electrónico, de conformidad con las normas RFC.

• Acerca de
• Últimas publicaciones

Milena Baghdasaryan

Especialista en contenidos en PowerDMARC

Milena es una hábil escritora y creadora de contenidos con más de 7 años de experiencia en la elaboración de contenidos atractivos sobre TI, ciberseguridad, eventos virtuales y mucho más. Tiene un historial probado de entrega de trabajos de alta calidad para revistas internacionales y se ha graduado en prestigiosas instituciones como la New York University Abu Dhabi, UWC China y el College of Europe.

Últimos mensajes de Milena Baghdasaryan (ver todos)

• Autenticación de correo electrónico en las mayores empresas de IA del mundo - 10 de agosto de 2026
• Las 5 mejores herramientas contra el fraude por correo electrónico empresarial (BEC) en 2026 - 31 de julio de 2026
• Herramientas DMARC gratuitas: verificadores, generadores y supervisión (2026) - 30 de julio de 2026