Alguien envía correos como si fueran de tu empresa: suplantación, cuenta robada o nombre falso

La llamada llega de dos maneras. O un cliente nos reenvía un mensaje que recibieron sus propios clientes, firmado con el nombre de la empresa y pidiendo con mucha educación un cambio de cuenta bancaria, o nos manda un montón de avisos de rebote por correos que nadie en la oficina escribió nunca. La pregunta es la misma en los dos casos: cómo es que alguien está enviando correos como nosotros, y cómo lo paramos.

La respuesta honesta es que "alguien envía correos como nosotros" son tres problemas distintos con el mismo disfraz, y distinguirlos es toda la primera hora del trabajo. Si te equivocas, pasas una semana apretando registros DNS mientras el intruso sigue con la sesión abierta en un buzón.

Tres problemas, una sola queja

• Una cuenta está comprometida. El correo sí salió de tu organización, enviado por quien tiene la contraseña o una sesión robada. A veces la evidencia está en la carpeta de Enviados. A veces no, porque quien entró la borró y dejó un filtro puesto.
• Están suplantando tu dominio. Los mensajes se escriben en otra parte, con tu dominio escrito a mano en el encabezado From. A ti no te entraron a nada. La ayuda de Gmail es clara con el límite: como esos mensajes se crean fuera de Gmail, Gmail no puede evitar que alguien ponga tu dirección en el campo From, y los síntomas son los que describen los clientes, reportes de rebote por correos que nunca enviaste y respuestas a mensajes que nunca escribiste.
• Usan tu nombre, no tu dominio. La dirección es del atacante: una cuenta de correo gratuito, o un dominio registrado la semana pasada que se lee como el tuyo si no miras dos veces. Solo el nombre visible dice tu empresa.

El primero es un incidente. El segundo es trabajo de DNS y de política. El tercero no se arregla con DNS, y esa es la parte que casi todos los artículos se saltan.

Empieza por un mensaje real, no por tu DNS

Antes de que alguien abra un panel de DNS, queremos los encabezados completos de un mensaje que el destinatario haya recibido de verdad. No una captura, no un reenvío: los encabezados en crudo. En Gmail, un signo de interrogación junto al nombre del remitente significa que el mensaje no se autenticó, y al desplegar la línea del remitente se ve si hay un dominio en Enviado por o en Firmado por. Ese solo indicador separa dos de los tres casos en unos cuatro segundos.

Después leemos los encabezados en un orden fijo:

1. ¿El dominio del encabezado From es tuyo de verdad, o solo se parece al tuyo?
2. ¿Authentication-Results muestra un pass de SPF o de DKIM, y el dominio que pasó coincide con el del From? Un pass de otro dominio no es un pass tuyo.
3. ¿La cadena Received empieza dentro de tu proveedor de correo, o en un lugar que nunca habías visto?

Si el dominio del From es tuyo y nada lo autenticó, estás frente a una suplantación. Si es tuyo y autenticó limpio desde tu propio proveedor, trátalo como cuenta comprometida hasta que se demuestre lo contrario. Si no es tuyo, ningún cambio en tus registros lo va a tocar. Nuestro analizador de cabeceras te da esas mismas tres respuestas sin que tengas que leer la cadena a mano, y hay un recorrido más largo en cómo leer las cabeceras de un correo.

Descarta una cuenta comprometida antes de tocar un registro

Cuando los encabezados apuntan hacia dentro de tu propia organización, el trabajo de DNS puede esperar. La guía de Google para administradores de Workspace pone el orden sin rodeos: primero suspende la cuenta, porque suspender a un usuario restablece sus cookies de inicio de sesión y sus tokens de OAuth, luego investiga, luego restablece la contraseña y revoca los tokens de OAuth 2.0, y al final restauras el acceso.

La investigación tiene dos mitades en la consola de administración. Los eventos de registro de usuario guardan los inicios de sesión web correctos y fallidos de todo tu dominio hasta seis meses atrás, que es donde aparece un acceso desde un país al que nadie viajó. La búsqueda de registros de correo guarda los registros de entrega de tus dominios, y responde la pregunta que define todo lo demás: ¿esos mensajes pasaron por tu organización? Si los mensajes de los que se quejan tus destinatarios no aparecen en tus propios registros de entrega, de tu cuenta no salió nada y vuelves a la pista de la suplantación.

Antes de devolver el buzón, busca lo que dejaron puesto y no solo lo que se llevaron. Los filtros y los reenvíos son el residuo habitual, porque siguen funcionando después de un cambio de contraseña. Un robo de cuenta que documentamos a fondo, phishing que se salta la verificación en dos pasos, empezó con un archivo compartido y una sesión robada, no con una contraseña adivinada: por eso un cambio de contraseña, solo, no es contención.

Si están suplantando tu dominio, DMARC es la palanca

DMARC amarra el dominio que lee una persona, el del encabezado From, a un dominio que pasó SPF o DKIM. Ese amarre se llama alineación, y es por lo que DMARC puede hacer lo que SPF y DKIM no pueden solos: dejarte publicar una instrucción sobre el correo que usa tu nombre y no prueba nada. La especificación vigente es el RFC 9989, publicado en mayo de 2026, que reemplazó al RFC 7489. Mantiene los tres valores de política que ya conocen los administradores, none, quarantine y reject, y mantiene la advertencia honesta: una política publicada es una disposición solicitada, y el sistema receptor sigue teniendo la última palabra.

Un primer registro se ve así, con los reportes llegando a un buzón que alguien vaya a leer de verdad:

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com; fo=1"

Arrancar en p=none no es timidez, es secuencia. Los reportes te dicen qué remitentes tuyos están fallando la alineación antes de que una política empiece a rechazarlos: facturación, el CRM, la plataforma de la tienda, la copiadora del pasillo. Dos semanas de reportes, luego quarantine, luego reject. Recorremos la rampa completa en cómo pasar DMARC de p=none a p=reject, y el XML mismo en cómo leer un reporte agregado de DMARC. Si ya tienes reportes acumulados en un buzón, el analizador de reportes DMARC te ordena los remitentes.

Llegar a enforcement es lo que termina con el segundo tipo de queja. Mientras la política no diga reject, a un receptor que respeta DMARC le estás diciendo que entregue el correo suplantado igual.

Los dominios que tienes y nunca usas para enviar

Casi todos los clientes los tienen: el dominio mal escrito que compraron por defensa, la marca vieja, la variante de país que nadie renovó. Un dominio sin uso y sin registros es una identidad gratis y con reputación limpia para quien lo encuentre. A esos dominios les ponemos un SPF que no autoriza a nadie y una política de reject:

ejemplo-viejo.com.         TXT  "v=spf1 -all"
_dmarc.ejemplo-viejo.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.com"

El mismo razonamiento aplica un nivel más abajo, en los subdominios desde los que no envías, que se comportan distinto al dominio raíz y son un hueco frecuente justo después de dejar la raíz bien cerrada. Eso es un trabajo aparte: mira subdominios en DMARC, la etiqueta sp y la delegación.

Lo que DMARC no detiene, y nadie debería disimularlo

Aquí se acaban los dos primeros arreglos. El RFC 9989 pone los ataques al nombre visible fuera de alcance, en su sección de consideraciones de seguridad, y la descripción coincide con lo que llega al buzón de tu equipo: una dirección cualquiera que carga un nombre conocido en el nombre visible, para que quien lee crea que ese nombre se usa de forma legítima. Tu política da igual, porque el atacante nunca reclamó tu dominio.

Tres variantes que vemos todo el tiempo:

• Solo el nombre visible. El nombre se lee como el de tu director; la dirección es una cuenta de correo gratuito. Los clientes de teléfono y tablet suelen mostrar el nombre y esconder la dirección, y por eso funciona.
• Un dominio parecido. Una letra cambiada, un guion, otra terminación. Pasa su propio SPF, DKIM y DMARC, porque el dominio es del atacante.
• Un From limpio con un Reply-To hostil. La conversación se ve bien y las respuestas se van a otro lado.

Así que la mitad de este trabajo es filtrado de entrada: proteger a las personas que leen el correo, no solo al dominio que lo envía.

El lado de entrada: qué activamos en Google Workspace

En la consola de administración, en Aplicaciones, luego Google Workspace, luego Gmail, luego Seguridad, la sección de suplantación de identidad y autenticación cubre esos huecos de forma directa. Hay protección contra dominios parecidos al tuyo o a tus alias; contra mensajes cuyo nombre de remitente coincide con un nombre de tu directorio de Workspace aunque el correo no salió de tu dominio; contra correo entrante que dice venir de tu propio dominio sin pasar SPF ni DKIM, el patrón del fraude del CEO; y contra correo no autenticado en general. Para cada una eliges: dejarla en la bandeja con un aviso, mandarla a spam, o ponerla en cuarentena para que un administrador la revise.

Cuáles tienes disponibles depende de tu edición, así que revisa la consola en vez de suponer. Poner en cuarentena todo lo no autenticado un lunes a primera hora es la forma de que finanzas se pierda un correo real de un proveedor. Empezamos con los avisos visibles, miramos una semana, y pasamos a cuarentena las categorías sin falsos positivos.

Si parte de tus usuarios está en Microsoft 365, la maquinaria equivalente tiene otra forma. Microsoft junta los resultados de SPF, DKIM y DMARC en un solo veredicto de autenticación compuesta, lo pesa contra la inteligencia de suplantación que arma con el historial de flujo de correo y de infraestructura del remitente, y deja que la política antiphishing decida la acción. Una autenticación compuesta fallida, por sí sola, no bloquea el mensaje, y es deliberado, para no cortar a remitentes con autenticación imperfecta. Para el lado de envío de un tenant de Microsoft, mira DMARC en Office 365.

El mes siguiente

La suplantación no es un trabajo que se termina un jueves. Durante los siguientes treinta días miramos tres cosas: fuentes de envío nuevas en los reportes agregados, que es como se cachan tanto una herramienta interna olvidada como un abusador nuevo; la cola de cuarentena, que te dice si las reglas de entrada están calibradas o solo son ruidosas; y el patrón de rebotes que arrancó la conversación, que debería adelgazar a medida que los receptores respetan la política. Los dominios parecidos merecen una búsqueda permanente, porque el único remedio es verlos temprano.

Cómo ayuda Guanacos Tech

Hacemos esto de una pasada: leemos los encabezados, decidimos cuál de los tres problemas tienes, contenemos una cuenta si resulta ser eso, publicamos los registros en un orden que no rompa tus propias facturas, y dejamos las protecciones de entrada en un nivel con el que tu equipo pueda trabajar. Después nos quedamos en los reportes el primer mes, que es cuando aparecen las sorpresas. Ese trabajo vive dentro de nuestra consultoría de entregabilidad de correo, y cómo se define y se cotiza un proyecto está en cómo trabajamos. Si hoy mismo está saliendo correo que dice venir de tu dominio, con una llamada de 30 minutos nos alcanza para decirte cuál de los tres problemas es y cuál es el primer movimiento.

Fuentes

• Someone is sending emails from a spoofed address (Gmail Help)
• Identify and secure compromised accounts (Google Workspace Admin Help)
• Find messages with Email Log Search (Google Workspace Admin Help)
• Advanced phishing and malware protection: spoofing and authentication settings (Google Workspace Admin Help)
• Check if your Gmail message is authenticated (Gmail Help)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
• Anti-spoofing protection (Microsoft Defender for Office 365)