Spoofing de correo: por qué tu dominio es el que responde
Alguien puede mandar un correo que diga venir de su empresa sin haber entrado nunca a sus sistemas. No es una falla de su servidor: es cómo funciona el correo desde que existe. Lo que sí está en sus manos es que ese mensaje no llegue.
Por qué se puede falsificar un remitente
El protocolo con el que viaja el correo se diseñó cuando todos los que lo usaban se conocían. No previó verificar que quien dice ser el remitente lo sea. El campo De: que muestra el cliente de correo es simplemente un texto que el que envía escribe, y nadie lo contrasta contra nada.
La consecuencia práctica es incómoda. Un atacante no necesita comprometer su casilla, su servidor ni su dominio. Le alcanza con armar un mensaje que declare su dirección y mandarlo desde cualquier servidor. Del otro lado llega con el nombre de su empresa.
Es lo que hace tan efectivo el fraude del CEO, donde un correo que aparenta venir de la dirección le pide a alguien de administración una transferencia urgente. No hay intrusión que investigar, porque nunca la hubo.
Los tres registros que cierran la puerta
La defensa no está en el correo, está en el dominio. Son tres registros DNS que se complementan y que hay que tener los tres.
| Registro | Qué hace | Qué pasa si falta |
|---|---|---|
| SPF | Declara qué servidores pueden enviar en nombre del dominio | Cualquier servidor puede |
| DKIM | Firma cada mensaje, y la firma se verifica al recibirlo | No hay forma de probar que el mensaje no fue alterado |
| DMARC | Define qué hacer con lo que no pasa los dos anteriores, y le avisa a usted | Se detecta el problema y no se rechaza nada |
El orden importa. SPF y DKIM verifican, DMARC decide y reporta. Tener los dos primeros sin el tercero es tener la evidencia y no usarla.
Ya no es opcional
Desde 2024 Google, Yahoo y Microsoft exigen estas autenticaciones como condición para entregar correo masivo. Un dominio sin ellas no solo queda expuesto a que lo suplanten: empieza a tener problemas para que sus propios mensajes lleguen.
Ahí hay un efecto que muchas organizaciones descubren tarde. Las facturas, los presupuestos y los avisos a clientes empiezan a caer en correo no deseado, y se lo atribuye al proveedor de correo o a mala suerte, cuando la causa está en un registro DNS que nunca se configuró.
Cómo saber cómo está parado hoy
La revisión inicial es corta y no requiere tocar nada. Se consultan los registros DNS del dominio y se verifica si existen los tres, y con qué política. Es habitual encontrar un SPF escrito hace años que quedó incompleto cuando se sumó una herramienta de envío, o un DMARC en modo de solo observación que nunca pasó a rechazar.
Ese segundo caso es el más frecuente y el más engañoso. El registro está, la auditoría lo da por cumplido, y no está bloqueando nada.
Un paso más, cuando lo anterior está
Con los tres registros funcionando y DMARC efectivamente rechazando, aparece BIMI, que permite mostrar el logo verificado de la organización junto al mensaje en las casillas que lo soportan. Es visible para el que recibe y trabaja a favor de la confianza, pero conviene tenerlo claro: es el último paso, no el primero, y exige que lo anterior esté bien resuelto.
Es de los pocos controles que se resuelven una vez
La mayoría de los controles de seguridad hay que sostenerlos en el tiempo. Este no. SPF, DKIM y DMARC se configuran una vez, se verifican, y quedan trabajando sin que nadie los toque.
Por eso lo ponemos siempre entre lo primero. Es trabajo acotado, no cuesta licencias, y saca de encima toda una familia de fraudes que hoy usa el nombre de su empresa para engañar a sus propios clientes.
El caso que más vemos es el del DMARC en modo de observación, puesto hace años y nunca pasado a rechazar. El registro figura, la auditoría lo da por cumplido, y no está bloqueando absolutamente nada.
Fuente: WeLiveSecurity
