22 Oct 20265 minutes read
Waseem OsmanEspecialista en DMARCCómo impedir que un generador de correos de phishing suplante su dominio

Resumen sobre el correo de phishing:
- Un correo suplantado que llega a las bandejas de entrada señala que falta la aplicación de DMARC, no que el atacante sea experto.
- SPF comprueba un dominio distinto del que ven los destinatarios, por lo que no puede detener un encabezado "From" falsificado.
- Solo p=reject bloquea el correo suplantado. Una política p=quarantine lo sigue entregando a Spam o Correo no deseado.
- Una etiqueta
sp=más débil puede dejar expuestos los subdominios incluso cuando el dominio raíz está en p=reject.
Los atacantes ya no necesitan conocimientos técnicos para suplantar a una marca. Un generador de correos de phishing da a cualquiera los medios para enviar mensajes que muestran un dominio de confianza. Muchas organizaciones aún no han aplicado los controles de autenticación del correo que impiden que esos mensajes lleguen a las bandejas de entrada.
Cuando un correo suplantado con su dominio aterriza en la bandeja de entrada de un cliente o proveedor, no demuestra que el atacante sea sofisticado. Demuestra que su dominio no está en plena aplicación de DMARC.
Este artículo explica cómo estas herramientas abusan de las debilidades de la autenticación, qué controles las detienen y cuatro comprobaciones que los equipos de seguridad y TI pueden ejecutar en sus dominios.
Cómo funciona un generador de correos de phishing
Un generador de correos de phishing hace dos trabajos. Construye un mensaje convincente y lo envía de modo que parezca proceder de una organización de confianza.
La técnica en la que se apoya un kit de phishing para ese segundo trabajo es la suplantación del encabezado. La herramienta establece el encabezado “From” visible con su dominio mientras envía desde una infraestructura que usted no controla. Los servidores receptores solo rechazan el mensaje si su política DMARC se lo indica.
Por qué un generador de correos de phishing supera SPF
SPF confirma que un mensaje procede de un servidor autorizado a enviar en nombre del dominio. No comprueba el encabezado “From” que ve el destinatario. Un kit de phishing puede usar un dominio que supera SPF desde el propio servidor del atacante mientras muestra su dominio en el encabezado “From”.
El resultado es un SPF superado para el dominio equivocado. Por eso la suplantación del encabezado tiene éxito contra los dominios que dependen de SPF sin aplicar DMARC.
DKIM y DMARC cierran esa puerta:
- DKIM añade una firma criptográfica. Un atacante no puede producir una firma válida para su dominio sin su clave privada. Las firmas DKIM suelen sobrevivir al reenvío, aunque fallan cuando un intermediario modifica el mensaje.
- DMARC exige que el dominio autenticado por SPF o DKIM se alinee con el dominio del encabezado “From”. En p=reject, indica a los servidores receptores que rechacen los mensajes que no superan esta comprobación.
Con ambos implantados, la suplantación del encabezado de su dominio exacto fracasa. El atacante debe aceptar el rechazo o pasar a un dominio que controle, como un dominio similar.
Cuatro comprobaciones que muestran si su dominio puede ser suplantado
Ejecute cada comprobación en todos los dominios que posee su empresa, incluidos los que no envían correo.
1. Confirme que la política es p=reject
Una política p=none solo monitoriza. Genera reportes, pero no pide a los receptores que bloqueen nada. Una política p=quarantine envía los mensajes que fallan a Spam o Correo no deseado, donde los destinatarios aún pueden encontrarlos y abrirlos.
Solo p=reject impide que el correo no autenticado llegue al destinatario. Use el verificador de registros DMARC para confirmar la política publicada en cada dominio.
2. Compruebe que la política de subdominios no debilite la protección
Los subdominios heredan la política p= cuando falta la etiqueta sp=. El riesgo proviene de un registro que establece explícitamente una política de subdominios más débil, como sp=none.
Un dominio en p=reject con sp=none deja subdominios como invoices.example.com abiertos a la suplantación del encabezado.
3. Asegúrese de que todos los remitentes legítimos firmen con DKIM
Las plataformas de terceros, como los sistemas de RR. HH., las herramientas de tickets y las plataformas de marketing, deben firmar el correo con una clave DKIM. Los remitentes que dependen solo de la alineación SPF fallan DMARC cuando se reenvía su correo.
4. Revise los reportes agregados en busca de fuentes desconocidas
Los reportes agregados enumeran todas las fuentes que envían correo con su dominio, junto con los resultados de autenticación. Los receptores envían estos reportes en todos los niveles de política, incluido p=reject, de modo que mantiene la visibilidad de los intentos de suplantación tras la aplicación.
Las fuentes desconocidas se dividen en dos grupos: herramientas internas no aprobadas y abuso activo. Las unidades de negocio que adoptan herramientas SaaS sin la aprobación de TI suelen aparecer aquí primero. Revisar a mano reportes XML en bruto en decenas de dominios exige un tiempo del que los equipos de seguridad justos de recursos rara vez disponen.
Documentar la aplicación para auditoría y equipos de riesgos
Los comités de auditoría y los consejos esperan cada vez más una prueba de que los controles de autenticación del correo funcionan, y no solo de que existen. La evidencia que resiste una auditoría incluye:
- p=reject publicado en todos los dominios, incluidos los que no envían correo
- Firma DKIM configurada para todos los remitentes de terceros autorizados
- Reportes agregados revisados según un calendario definido, con un responsable designado
Cómo puede ayudar Sendmarc
Llevar todos los dominios a p=reject rara vez lo bloquea el propio protocolo. Se estanca porque los equipos no ven a todos los remitentes, los departamentos añaden herramientas sin aprobación y el personal de seguridad no tiene tiempo para analizar reportes de distintas regiones y marcas. Sendmarc elimina esa carga para que los atacantes no puedan usar su dominio.
La gestión de DMARC identifica todas las fuentes legítimas y no autorizadas que envían correo en su nombre, en dominios raíz, subdominios y dominios inactivos. El equipo de implementación de Sendmarc lleva a su organización de p=none a p=reject por etapas, para que la facturación, las notificaciones y el correo de marketing sigan llegando a las bandejas de entrada.
La protección no termina con la aplicación. La monitorización y la optimización continuas mantienen la autenticación al día a medida que cambian los proveedores, los dominios y los equipos. Defensa contra dominios similares monitoriza los dominios recién registrados que se parecen al suyo y cubre el vector al que recurren los atacantes cuando se bloquea la suplantación del encabezado.
Para los equipos de riesgos y cumplimiento, Sendmarc ofrece reportes sobre el estado de autenticación por dominio y un certificado de cumplimiento de DMARC como prueba verificable de la aplicación. Eso da a los comités de auditoría y a los consejos una evidencia creíble sin añadir trabajo manual a TI.
Descubra la gestión de DMARC y Defensa contra dominios similares para ver cómo Sendmarc lleva todos los dominios a p=reject y monitoriza los dominios similares que usan los atacantes cuando fracasa la suplantación.


