Correo electrónico: phishing desde tu dominio — un manual de respuesta a incidentes que funciona

Playbook de diagnóstico rápido

Buscas el cuello de botella: ¿el correo salió por tu infraestructura?, o ¿alguien está suplantando tus cabeceras y aprovechando la red pública? No “revises todo.” Comprueba las tres cosas que separan esos mundos.

Primero: ¿algún mensaje atravesó tus sistemas salientes?

• Revisa tus logs del MTA (seguimiento de mensajes de Postfix/Exim/Exchange). Si no hay evidencia de que el spam saliera de tus sistemas, mayormente se trata de suplantación y políticas, no de un emisor comprometido.
• Revisa el seguimiento de mensajes de tu proveedor (Microsoft 365 / Google Workspace). Si muestra envíos salientes exitosos, probablemente hay robo de credenciales o abuso de token API.

Segundo: ¿las cabeceras en los destinatarios muestran autenticación exitosa?

• Si SPF=pass para tu dominio y DKIM=pass con tu selector, probablemente el remitente usó tu infraestructura real o credenciales.
• Si SPF/DKIM falla pero el mensaje aún llega, tu política DMARC es demasiado débil (o inexistente), y los destinatarios toman sus propias decisiones.

Tercero: ¿tu política de dominio está aplicando algo?

• Revisa el registro DMARC: si es p=none, estás observando, no protegiendo.
• Revisa la alineación: SPF/DKIM pueden “pasar” pero seguir fallando DMARC si no están alineados con el From: visible.

Regla de velocidad: en los primeros 30 minutos, prioriza detener envíos adicionales y preservar evidencia. La reparación de reputación puede esperar hasta que el incendio esté controlado.

Qué suele significar “phishing desde tu dominio”

Hay tres realidades comunes detrás de la misma captura aterradora.

1) Suplantación pura (tu dominio está falsificado, no hackeado)

El correo se diseñó en una era cuando “ser educado” era un modelo de seguridad razonable. Cualquiera puede escribir From: ceo@yourdomain.com en un mensaje. Si tu dominio carece de una fuerte aplicación de DMARC, muchos sistemas receptores lo entregarán de todos modos—especialmente a humanos entrenados por la vida corporativa a clicar en cosas urgentes.

2) Compromiso de cuenta (alguien está enviando como tú)

Un buzón fue phished, se aprobó una pantalla de consentimiento OAuth, se filtró un token API o se eludió la MFA con el robo de una cookie de sesión. El atacante envía desde tu tenant real, por eso SPF y DKIM a menudo pasan. Este es el doloroso porque el spam es “auténtico”.

3) Abuso de infraestructura (open relay, envío SMTP expuesto, herramienta de marketing abusada)

Menos común, pero catastrófico cuando es cierto: tu MTA está haciendo relay para todo el mundo, una credencial SMTP olvidada sigue válida, o un servicio de envío de terceros permitido en SPF está siendo abusado. La diferencia aquí es que lo verás en tus logs.

Una buena respuesta a incidentes es mayormente clasificación. Una vez sabes en cuál de los tres estás, la solución se vuelve aburrida. Aburrido es bueno.

Datos interesantes y contexto histórico

• SMTP se lanzó sin autenticación a principios de los 80; la identidad se asumía, no se verificaba. La suplantación no era un “bug”, estaba fuera del modelo de amenazas original.
• SPF nació como una idea de autorización de remitente basada en DNS a principios de los 2000, principalmente para reducir el spam con sobres forjados.
• DKIM proviene de DomainKeys e Identified Internet Mail; firma criptográficamente el contenido del correo para que los destinatarios puedan verificar el control del dominio.
• DMARC (alrededor de 2012) unió SPF y DKIM con reglas de alineación y un control de política (none/quarantine/reject), además de reportes.
• Los reportes DMARC crearon una nueva industria de telemetría: de repente podías ver quién “está enviando como tú”, incluidos proveedores olvidados hace tiempo.
• La “alineación” es la trampa: SPF puede pasar para un dominio mientras el From: visible es otro; DMARC es lo que se preocupa por esa discrepancia.
• ARC (Authenticated Received Chain) existe porque el reenvío y las listas de correo rompen la autenticación; ARC permite a los intermediarios atestiguar lo que vieron.
• Los principales proveedores de correo fueron endureciendo las reglas: con el tiempo, los emisores masivos fueron empujados hacia la aplicación de SPF/DKIM/DMARC y expectativas de baja fricción para bajas de suscripción.
• Los equipos de seguridad aprendieron por las malas: “tenemos SPF” no es una defensa. SPF es una puerta. Los atacantes caminan alrededor de las puertas.

Árbol de decisión: suplantación vs compromiso vs relay

Si los logs salientes muestran mensajes saliendo de tus sistemas

• Probable: buzón comprometido, credencial SMTP comprometida, integración de proveedor abusada.
• Haz ahora: bloquea el remitente, revoca tokens, restablece credenciales, fuerza cierre de sesión, investiga logs de acceso, preserva muestras.

Si los logs salientes no muestran nada, pero los destinatarios ven tu From:

• Probable: suplantación.
• Haz ahora: refuerza DMARC, asegúrate de que DKIM esté habilitado en todas las fuentes legítimas y verifica que SPF incluya solo lo que controlas.

Si los logs muestran que tu MTA hizo relay a muchos dominios con los que no haces negocio

• Probable: open relay o submission/auth expuesto.
• Haz ahora: restringe reglas de relay, limita puertos de submission, rota credenciales, bloquea IPs ofensivas y revisa si hay malware en el host.

Cita para tener en la pared (idea parafraseada): John Allspaw: la fiabilidad viene de cómo se comportan los sistemas bajo estrés, no de lo bonitas que sean tus diagramas.

Tareas prácticas con comandos (y cómo decidir)

Estas son tareas reales que puedes ejecutar en un host MTA Linux o en un jump box con herramientas DNS. Cada una incluye: el comando, qué significa la salida y la decisión que tomas. Ajusta dominios y nombres de host según corresponda.

Task 1 — Pull SPF record and sanity-check it

cr0x@server:~$ dig +short TXT yourdomain.com
"v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all"

Qué significa: SPF autoriza 203.0.113.10 además de Google y SendGrid. El ~all es “softfail”, que es básicamente una sugerencia amable.

Decisión: inventaría cada include. Si no puedes explicar por qué está, no es “temporal”, es “riesgo desconocido.” Avanza hacia -all solo cuando estés seguro de que todos los emisores legítimos están cubiertos.

Task 2 — Check DMARC record and policy level

cr0x@server:~$ dig +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; adkim=r; aspf=r; pct=100"

Qué significa: Estás recopilando reportes pero no haciendo cumplir. Está activada la alineación relajada.

Decisión: si te están suplantando activamente, p=none no es un plan de respuesta. Pasa a p=quarantine rápidamente y luego a p=reject tras validar que las fuentes legítimas firman/autorizan correctamente.

Task 3 — Verify DKIM selector exists (common failure: missing record)

cr0x@server:~$ dig +short TXT s1._domainkey.yourdomain.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Qué significa: La clave pública DKIM existe para el selector s1.

Decisión: si falta, DKIM fallará para el correo firmado con ese selector. Arregla el DNS y luego valida el firmado en el lado del emisor.

Task 4 — Inspect a phishing sample’s Authentication-Results

cr0x@server:~$ grep -E "Authentication-Results|From:|Return-Path:|Received-SPF|DKIM-Signature" -n sample.eml | sed -n '1,120p'
12:From: "Accounts Payable" <ap@yourdomain.com>
18:Return-Path: <bounce@evil-example.net>
31:Authentication-Results: mx.example.net;
32: spf=fail (mx.example.net: domain of bounce@evil-example.net does not designate 198.51.100.77 as permitted sender) smtp.mailfrom=evil-example.net;
33: dkim=none (message not signed);
34: dmarc=fail (p=none) header.from=yourdomain.com

Qué significa: No está firmado, SPF falla para el dominio del sobre, DMARC falla pero la política es none por lo que aún puede llegar.

Decisión: trátalo como suplantación. Tu trabajo es hacer que DMARC fallido signifique “no entregar.” Endurece DMARC y asegúrate de que los emisores legítimos estén alineados.

Task 5 — Confirm your outbound IP reputation signals (quick: check if you’re listed)

cr0x@server:~$ dig +short 10.113.0.203.zen.spamhaus.org A
127.0.0.2

Qué significa: 203.0.113.10 aparece listado (respuesta de ejemplo). Algunas listas devuelven distintos loopbacks por diferentes razones.

Decisión: si estás listado y realmente enviaste el correo, la contención y limpieza importan más que discutir con la lista. Si no lo enviaste, igual necesitas la aplicación de DMARC y evidencia para solicitudes de delisting.

Task 6 — Search Postfix logs for suspicious volume spikes

cr0x@server:~$ sudo zgrep -h "postfix/smtp" /var/log/mail.log* | awk '{print $6}' | cut -d= -f2 | sort | uniq -c | sort -nr | head
  4821 status=sent
   118 status=deferred
    22 status=bounced

Qué significa: Muchas envíos exitosos. Eso es consistente con actividad saliente real, no mera suplantación.

Decisión: pivota a “quién lo envió” (usuario autenticado, IP de origen, logs de submission). Si el volumen es cero, deja de perseguir fantasmas del MTA y arregla DMARC.

Task 7 — Identify authenticated SMTP users (submission abuse)

cr0x@server:~$ sudo zgrep -h "sasl_username=" /var/log/mail.log* | awk -F'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  913 payroll@yourdomain.com
  112 notifications@yourdomain.com
   10 helpdesk@yourdomain.com

Qué significa: Un buzón específico domina los envíos vía SMTP autenticado.

Decisión: deshabilita inmediatamente esa cuenta, rota la contraseña, revoca sesiones y revisa el historial de inicios. Luego verifica si es un emisor legítimo (sistemas de nómina suelen serlo) o un atacante.

Task 8 — Trace one message queue ID to see destinations and timing

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5*     2048 Mon Jan  4 08:55:12  ap@yourdomain.com
                                         user1@example.net
                                         user2@example.org

cr0x@server:~$ sudo postcat -q A1B2C3D4E5 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:            2048
sender: ap@yourdomain.com
*** MESSAGE CONTENTS ***
From: "Accounts Payable" <ap@yourdomain.com>
Subject: Updated remittance advice
Date: Mon, 04 Jan 2026 08:55:11 +0000

Qué significa: Esto está realmente en tu cola. Eso no es suplantación; tu sistema lo está enviando.

Decisión: contiene pausando la salida o reteniendo la cola si es necesario, luego aisla la cuenta o aplicación origen.

Task 9 — Stop Postfix outbound temporarily (containment lever)

cr0x@server:~$ sudo postfix stop
postfix/postfix-script: stopping the Postfix mail system

Qué significa: Detuviste el MTA. Esto es contundente pero efectivo si tu servidor es el cañón.

Decisión: úsalo solo si confirmaste que tu host está enviando correo abusivo y puedes tolerar una interrupción. De lo contrario, restringe en el borde (firewall, límites de tasa, deshabilitar cuenta) para evitar daños colaterales.

Task 10 — Check for open relay behavior (the classic “nope”)

cr0x@server:~$ swaks --to victim@example.net --from spoof@yourdomain.com --server mail.yourdomain.com
=== Trying mail.yourdomain.com:25...
=== Connected to mail.yourdomain.com.
<= 220 mail.yourdomain.com ESMTP Postfix
=> EHLO server
<= 250-mail.yourdomain.com
=> MAIL FROM:<spoof@yourdomain.com>
<= 250 2.1.0 Ok
=> RCPT TO:<victim@example.net>
<= 554 5.7.1 Relay access denied
=> QUIT
<= 221 2.0.0 Bye

Qué significa: Relay denegado. Bien. Si vieras 250 2.1.5 Ok para RCPT a un dominio externo sin auth, tendrías un open relay.

Decisión: si está abierto, corrige las restricciones de relay inmediatamente. Si está cerrado, deja de culpar al MTA por correo forjado que no enviaste.

Task 11 — Validate TLS and submission ports exposure

cr0x@server:~$ sudo ss -lntp | grep -E ":(25|465|587)\s"
LISTEN 0 100 0.0.0.0:25   0.0.0.0:* users:(("master",pid=1123,fd=13))
LISTEN 0 100 0.0.0.0:587  0.0.0.0:* users:(("master",pid=1123,fd=15))

Qué significa: SMTP y submission están escuchando en todas las interfaces. Eso puede estar bien, o puede ser “¿por qué hacemos esto?”

Decisión: si submission (587/465) está expuesto a internet, asegúrate de autenticación fuerte, límites de tasa y MFA en las cuentas. Si no necesitas submission externa, restringe por firewall/VPN.

Task 12 — Pull recent successful logins for a suspected mailbox (generic IMAP auth logs)

cr0x@server:~$ sudo zgrep -h "imap-login: Login:" /var/log/mail.log* | grep "payroll@yourdomain.com" | tail -5
Jan  4 08:41:02 mail dovecot: imap-login: Login: user=<payroll@yourdomain.com>, method=PLAIN, rip=198.51.100.88, lip=203.0.113.10, mpid=22101, TLS
Jan  4 08:43:19 mail dovecot: imap-login: Login: user=<payroll@yourdomain.com>, method=PLAIN, rip=198.51.100.88, lip=203.0.113.10, mpid=22144, TLS

Qué significa: Inicios de sesión repetidos desde una única IP remota. Podría ser el usuario, podría ser un atacante.

Decisión: correlaciona con ubicaciones de usuario conocidas/VPN egress. Si es sospechoso, revoca sesiones y restablece credenciales. No esperes a que RRHH “confirme si era ellos” mientras el spam continúa.

Task 13 — Confirm DMARC aggregate reports are arriving (mailbox health)

cr0x@server:~$ sudo mailq | head
Mail queue is empty

Qué significa: Tu cola local no está atascada, pero no prueba que los reportes DMARC se procesen. Esto es una “verificación de cordura”, no una vuelta de celebración.

Decisión: si dependes de reportes para visibilidad, asegúrate de que el buzón receptor esté monitorizado y tenga suficiente cuota. La telemetría DMARC que rebota en silencio es como un detector de humo con pilas agotadas.

Task 14 — Quick DNS propagation check from multiple resolvers

cr0x@server:~$ dig @1.1.1.1 +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s; pct=100"
cr0x@server:~$ dig @8.8.8.8 +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100"

Qué significa: Diferentes resolutores ven distintos registros—propagación o DNS split-brain. Hasta que esto converja, tu aplicación es inconsistente.

Decisión: no declares “arreglado” mientras internet siga viendo la política antigua. Investiga el hosting DNS, TTLs y si existen múltiples registros TXT.

Task 15 — Check for multiple DMARC TXT records (breaks evaluation)

cr0x@server:~$ dig TXT _dmarc.yourdomain.com +noall +answer
_dmarc.yourdomain.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"
_dmarc.yourdomain.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:old@yourdomain.com"

Qué significa: Dos registros DMARC. Muchos receptores tratan esto como permerror y pueden ignorar DMARC por completo.

Decisión: elimina el registro extra. Un registro DMARC por dominio. Siempre.

Chiste #1: La autenticación de correo es el único sistema de seguridad donde “pass” aún puede significar “fail”, y todos asienten como si fuera normal.

Tres microhistorias corporativas desde la trinchera

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa de servicios financieros mediana empezó a recibir quejas: proveedores recibían correos de “detalles bancarios actualizados” desde el dominio de la empresa. El equipo de TI hizo lo sensato al principio: buscar en los logs salientes. Nada. Declararon, con confianza, “no fuimos hackeados”.

Tenían media razón y estaban totalmente equivocados. Los atacantes estaban suplantando el From: visible y usando una infraestructura de envío desechable. La empresa tenía SPF y DKIM “configurados”, pero DMARC era p=none. Los sistemas receptores quedaron a adivinar si entregar, y muchos dijeron “sí” porque el mensaje parecía empresarial y no activó sus filtros de contenido.

La suposición errónea fue sutil: “Si no lo enviamos, no podemos detenerlo.” No puedes impedir que la gente falsifique tu nombre en las cabeceras SMTP, pero puedes hacer que sea caro entregar esas falsificaciones. DMARC existe exactamente para eso.

Una vez pasaron a p=quarantine y luego a p=reject, las quejas cayeron drásticamente. Algunos sistemas legítimos se rompieron—un proveedor de facturación antiguo no firmaba DKIM y enviaba desde una IP no incluida en SPF. Esa limpieza ya era necesaria de todas formas.

El postmortem fue directo: el incidente no fue “compromiso de correo”, fue “debilidad de política.” La solución no fue un milagro del SOC; fue un registro TXT en DNS y una semana de inventario de proveedores.

Microhistoria 2: La optimización que salió mal

Una empresa SaaS decidió “simplificar” el correo enrutando todo el correo saliente por una única plataforma de terceros. Un include SPF, un selector DKIM, un solo lugar para gestionar plantillas. La migración funcionó, la entregabilidad mejoró y todos siguieron con su trabajo.

Seis meses después, una ola de phishing afectó a sus clientes con autenticación perfecta. SPF pasó. DKIM pasó. DMARC pasó. Los mensajes se enviaron a través de esa plataforma, usando claves API válidas que se filtraron desde un artefacto del CI. No fue culpa del proveedor, exactamente. La empresa había tratado las claves API como configuración, no como credenciales de producción.

El error de optimización fue la centralización sin contención. Eliminaban diversidad (múltiples emisores), pero también controles del radio de impacto. Todas las funciones de correo—restablecimiento de contraseñas, facturas, marketing, soporte—compartían una “clave divina.” Cuando se filtró, los atacantes obtuvieron la credibilidad de su emisor más fuerte.

La recuperación tomó días: rotar claves, reconstruir higiene en CI, separar lo transaccional de lo marketing, implementar claves por servicio con permisos acotados y añadir límites de tasa y detección de anomalías. La ironía: la “simplificación” convirtió un incidente molesto en un evento de reputación.

Microhistoria 3: La práctica aburrida y correcta que salvó el día

Una organización sanitaria tenía una rutina que nadie quería: revisiones mensuales de reportes DMARC y un registro de autorizaciones de proveedores. Era tedioso. Generaba hojas de cálculo. Hacía suspirar a la gente en reuniones.

Entonces un atacante intentó suplantarlos durante un corte regional, usando un correo “útil” pidiendo a pacientes confirmar datos personales. El DMARC de la organización ya estaba en p=reject con alineación estricta para el dominio organizacional. Los mensajes suplantados fallaron DMARC y fueron rechazados por muchos proveedores principales antes de llegar a las bandejas de entrada.

Aun así recibieron algunos reportes—capturas desde sistemas de correo marginales y unos pocos reenvíos—pero la escala nunca llegó a “puente de incidentes.” Lo que sí hicieron fue revisar sus datos agregados DMARC y confirmar el patrón: muchos fallos desde rangos IP nuevos, cero actividad saliente correspondiente.

La práctica aburrida pagó doble: la aplicación fuerte redujo la entrega y la telemetría base facilitó clasificar el evento como suplantación, no compromiso. Eso significó que no perdieron un día rotando cada contraseña de la compañía “por si acaso”.

Contención: detener la hemorragia primero

La contención varía según la clasificación, pero la mentalidad es la misma: reduce el throughput del atacante rápidamente, sin destruir la evidencia que necesitarás para probar lo ocurrido.

Si es compromiso de buzón (más urgente)

• Deshabilita la cuenta o bloquea el inicio de sesión. No empieces con “preguntar al usuario.” Los usuarios están dormidos o a la defensiva; los atacantes no.
• Revoca sesiones y tokens. Restablecer contraseña sin revocar tokens es teatro.
• Elimina reglas maliciosas en la bandeja (clásico: reenvío automático, eliminar al recibir, “marcar como leído”).
• Detén la salida desde esa identidad mediante reglas de transporte/política, o bloquea temporalmente destinatarios externos.
• Preserva muestras: cabeceras completas, MIME crudo, timestamps e IDs de mensaje.

Si es abuso de remitente tercero

• Rota claves API, luego invalida las antiguas. Si no puedes invalidar claves antiguas, asume que no puedes contener.
• Acota permisos (claves separadas para transaccional vs marketing vs soporte; restricción por app).
• Limita la tasa de salida por clave y por IP, y alerta sobre anomalías.

Si es suplantación

• Mueve DMARC de none → quarantine rápidamente si puedes tolerar algunos falsos positivos. Usa pct=25 como rampa si hace falta, pero con límite de tiempo.
• Confirma que DKIM esté habilitado para cada fuente legítima, especialmente CRM/plataformas de marketing.
• Depura includes de SPF. Elimina proveedores obsoletos. SPF es una lista blanca; trátala como reglas de firewall.

Chiste #2: Si tu registro SPF incluye cinco proveedores que nunca has oído, felicitaciones—has inventado un “open relay externalizado”.

Erradicación y endurecimiento: que quede fijo

La contención compra tiempo. El endurecimiento evita que la misma clase de incidente se repita el próximo trimestre con un remitente distinto.

Restringe identidades y vías de acceso

• MFA en todas partes, pero además: bloquea protocolos de autenticación heredados y contraseñas de aplicaciones si puedes. A los atacantes les encantan las puertas viejas.
• Acceso condicional para inicios de sesión riesgosos: viaje imposible, dispositivo nuevo, rangos IP sospechosos.
• Gobernanza de apps OAuth: restringe consentimientos, revisa apps empresariales y monitoriza nuevas concesiones.

Haz la política de autenticación aplicable

• DMARC en p=reject para tu dominio organizacional cuando estés listo. Si no puedes llegar a reject, no conoces todos tus emisores.
• Usa alineación estricta donde sea posible (adkim=s, aspf=s) para reducir abusos por suplantación. Relaxed es un peldaño, no un destino.
• Separa dominios: usa un subdominio para marketing masivo y mantén el dominio principal bloqueado. Las plataformas de marketing se comprometen; eso no es una predicción, es física.

Corrige intencionalmente los casos límite de reenvío y listas de correo

Los reenviadores suelen romper SPF (porque la IP del reenvío no está autorizada) y las listas de correo suelen romper DKIM (porque modifican el mensaje). ARC ayuda, pero no asumas que cada receptor lo usa consistentemente.

• Para flujos críticos (facturas, restablecimientos de contraseña), evita enviar solo a listas/reenvíos como única vía de entrega.
• Si operas servidores de listas, configúralos para preservar la autenticación cuando sea posible y usa ARC si corresponde.

Construye detección que no dependa de la suerte

• Alerta sobre picos de salida por usuario/app/clave API.
• Rastrea nuevas reglas de reenvío y reglas de bandeja que eliminen o redirijan.
• Retención de logs: asegura suficiente historial para responder “¿cuándo empezó esto?” sin adivinar.

Recuperación de reputación y entregabilidad

Una vez has detenido el abuso en curso, tienes un segundo problema: internet ahora cree que eres desordenado. Salir de la caja de penalización se trata sobre todo de probar que eres estable.

Estabiliza tus patrones de envío

• Reduce el volumen temporalmente si puedes (especialmente marketing). Las primeras 48 horas tras un incidente son cuando los filtros son menos indulgentes.
• Envía tráfico limpio y esperado: mensajes transaccionales a destinatarios comprometidos son tu “latido saludable”.
• Elimina direcciones muertas y evita rebotes repetidos; son veneno para la reputación.

Arregla la causa y luego aborda listas negras

Solicitar delisting sin arreglar la causa es como fregar mientras la tubería sigue goteando. Algunas listas te relistan rápido, y la segunda vez suele ser más lenta de resolver.

Comunica como adulto

• Informa a los equipos internos qué ocurrió y qué cambió: política DMARC, bloqueos de cuentas, restricciones a proveedores.
• Proporciona a los clientes una nota breve con orientación: “No solicitamos restablecer contraseñas por enlace en email; verifica dominio e indicadores de autenticación.” Sé factual.
• No prometas de más. Si dices “no fuimos hackeados” sin haber verificado, estás apostando la confianza a una suposición.

Listas de verificación / plan paso a paso

0–30 minutos: clasificar y contener

1. Recopila al menos una muestra completa (raw .eml con cabeceras). Una captura no es evidencia.
2. Revisa trazas/logs salientes: ¿lo enviaron tus sistemas?
3. Si sí: deshabilita cuentas sospechosas y revoca tokens; pausa la salida si es necesario.
4. Si no: confirma la política DMARC; prepárate para mover a quarantine/reject.
5. Anuncia un canal de incidente con un propietario y un tomador de decisiones. El caos es el verdadero malware.

Mismo día: arregla las condiciones habilitantes

1. Inventario de emisores: M365/GWS, plataforma de marketing, sistema de tickets, alertas de monitorización, facturación, RRHH.
2. Habilita firmado DKIM por emisor cuando sea posible.
3. Restringe SPF: elimina includes obsoletos; asegúrate de no exceder límites de consultas DNS.
4. Configura DMARC en quarantine (opcionalmente rampando con pct). Empieza a recopilar reportes si no lo hacías.
5. Audita apps OAuth y concesiones de consentimiento; elimina integraciones desconocidas o riesgosas.
6. Busca reglas de reenvío y reglas sospechosas en bandejas.

Dentro de una semana: hazlo durable

1. Pasa DMARC a reject para el dominio organizacional una vez la alineación esté limpia.
2. Divide dominios: transaccional en un dominio controlado; marketing en un subdominio con política clara.
3. Implementa límites de tasa y alertas de anomalías en envíos salientes.
4. Escribe el runbook que desearías tener. Luego ejecuta un tabletop y obsérvalo romperse (amablemente).

Errores comunes: síntoma → causa raíz → arreglo

“Tenemos SPF, ¿por qué sigue ocurriendo suplantación?”

Síntoma: los destinatarios ven tu dominio en From:, pero Authentication-Results muestra SPF fail y DKIM none/fail, aun así los mensajes se entregan.

Causa raíz: SPF solo verifica el dominio del sobre, y sin aplicación de DMARC los receptores pueden seguir entregando correo con From: forjado.

Arreglo: implementa DMARC con quarantine/reject, asegura firmado DKIM y alinea SPF/DKIM con el From: visible.

“DMARC está configurado, pero los receptores dicen permerror”

Síntoma: DMARC falla con “permerror” en los reportes; la suplantación continúa.

Causa raíz: múltiples registros TXT DMARC, etiquetas malformadas o registros demasiado grandes.

Arreglo: asegura exactamente un registro DMARC, valida la sintaxis y manténlo dentro de los límites DNS.

“DKIM pasa a veces, falla otras veces”

Síntoma: validación DKIM inconsistente según receptor o ruta.

Causa raíz: múltiples sistemas emisores con distintos selectores/claves, problemas de propagación DNS o intermediarios que modifican contenido (listas/pies de página).

Arreglo: estandariza DKIM por emisor, verifica el selector en DNS, evita modificaciones del cuerpo del mensaje y considera ARC para intermediarios conocidos.

“Pusimos DMARC a reject y ahora correo legítimo falta”

Síntoma: facturas o respuestas de soporte desaparecen; usuarios se quejan.

Causa raíz: un emisor legítimo de terceros no está incluido en SPF y no firma DKIM con dominio alineado.

Arreglo: incorpora correctamente al proveedor: autoriza IPs o inclúyelo en SPF, exige firmado DKIM con tu dominio (o usa un subdominio), y vuelve a probar antes de endurecer política.

“Nuestro dominio se usa, pero nuestro servidor de correo está limpio”

Síntoma: sin logs salientes; aún así muchas quejas.

Causa raíz: suplantación pura combinada con DMARC débil (p=none) y/o heurísticas receptoras pobres.

Arreglo: pasa a DMARC quarantine/reject, publica una política clara y monitoriza reportes para fuentes no autorizadas restantes.

“Rotamos contraseñas y el spam sigue saliendo”

Síntoma: el spam saliente persiste tras restablecer contraseñas.

Causa raíz: el atacante usa sesiones existentes, tokens OAuth o claves API, no la contraseña.

Arreglo: revoca sesiones/tokens, rota claves API y deshabilita apps empresariales o concesiones de consentimiento sospechosas.

“Bloqueamos el puerto 25 y el problema paró… y también nuestro correo de negocio”

Síntoma: una acción de contención causó fallos masivos en el envío saliente.

Causa raíz: bloqueos de red contundentes sin entender qué servicios dependen de esa ruta (correo transaccional, alertas, restablecimientos).

Arreglo: prefiere contención dirigida: bloquea cuentas/claves específicas, limita tasa, restringe reglas de relay; mantén rutas críticas disponibles.

Preguntas frecuentes

1) ¿Cómo pueden los atacantes enviar “desde mi dominio” si no fuimos vulnerados?

Porque la cabecera From: es solo texto a menos que los receptores hagan cumplir autenticación. Suplantar es trivial; detener la entrega requiere aplicación DMARC más alineación correcta de DKIM/SPF.

2) ¿Deberíamos poner inmediatamente DMARC en p=reject?

Si estás seguro de conocer todos los emisores legítimos y que están alineados, sí. Si no, ve a p=quarantine primero y usa los reportes DMARC para encontrar rezagados. Limita el tiempo de la fase de quarantine.

3) ¿Cuál es la diferencia entre SPF “pass” y DMARC “pass”?

SPF “pass” significa que la IP emisora está autorizada para el dominio del sobre. DMARC “pass” significa que SPF o DKIM pasaron y están alineados con el dominio From: visible. La alineación es la clave.

4) ¿Por qué los correos reenviados rompen SPF/DKIM?

SPF se rompe porque la IP del servidor reenvío no está autorizada a enviar para el dominio original. DKIM puede romperse si el reenvío modifica el mensaje. Por eso DMARC puede ser doloroso para listas y por qué existe ARC.

5) Usamos múltiples proveedores. ¿Cómo evitamos que SPF se vuelva monstruoso?

Prefiere firmado DKIM por proveedor y mantén SPF ajustado. Cada include: es una relación de confianza. También vigila los límites de consultas DNS de SPF; demasiados includes pueden causar permerror SPF, que es una interrupción autoinfligida.

6) ¿Cómo saber si fue compromiso de token OAuth?

Busca consentimientos de apps nuevos o inusuales, inicios de sesión sin restablecimientos de contraseña correspondientes y envíos continuos después de cambiar la contraseña. Revocar tokens y eliminar apps son las acciones clave de contención.

7) ¿Podemos detener la suplantación sin DMARC?

No puedes detener la falsificación; solo puedes influir en el comportamiento de los receptores. Sin aplicación DMARC, estás esperando que las heurísticas de cada proveedor te salven. La esperanza no es un control.

8) ¿Qué debemos enviar a los clientes durante el incidente?

Breve, factual y accionable: qué ignorar, cómo verificar mensajes legítimos, qué nunca pedirás y un canal de soporte. No especules sobre la causa raíz hasta haberla verificado.

9) ¿Por qué el phishing aún llegó a algunas bandejas después de poner p=reject?

Retrasos de propagación, DNS en caché, receptores que no respetan DMARC de forma consistente o el correo siendo reenviado de formas que alteran la evaluación. También revisa si hay múltiples registros DMARC o problemas de alineación.

Conclusión: próximos pasos que sí puedes hacer

Si tu dominio se está usando para phishing, no empieces con un restablecimiento de contraseñas a nivel empresa y una oración. Empieza por clasificar: ¿atravesó tus sistemas? o no. Luego contiene la capa correcta: identidad, clave de proveedor, reglas de relay del MTA o aplicación de política.

Pasos prácticos para hoy:

1. Consigue un mensaje crudo con cabeceras completas y guárdalo en un lugar sensato.
2. Revisa evidencia saliente (traza del proveedor + logs MTA). Decide: suplantación vs compromiso vs relay.
3. Si es suplantación: mueve DMARC a quarantine ahora y planifica reject tras inventario de emisores.
4. Si es compromiso: deshabilita la cuenta, revoca tokens/sesiones, elimina reglas maliciosas, rota claves.
5. Dentro de una semana: limpia SPF, asegura DKIM en todas partes y empuja DMARC a reject para el dominio organizacional.
6. Dentro de un mes: separa dominios, implementa alertas de anomalías salientes y ensaya este runbook una vez.

La meta no es la perfección. La meta es que la próxima vez, tu puente de incidentes dure 30 minutos, no 30 horas—y que tu dominio deje de ser un disfraz que cualquiera pueda ponerse.