Un día me hice la pregunta incómoda: ¿puede alguien enviar correos haciéndose pasar por mí? Sin la protección adecuada, la respuesta es sí — y colaría. Así que me puse a cerrar esa puerta en mi propio dominio. Comparto cómo funciona, por si te sirve.
El problema: suplantar un correo es más fácil de lo que crees
El protocolo del correo (SMTP) nació sin autenticación: por diseño, cualquiera puede escribir en el campo "De:" lo que quiera. Es la base del phishing y del fraude del CEO (BEC), el que más dinero mueve. Si tu dominio no está protegido, alguien puede escribir a tus clientes o a tu propio entorno como si fueras tú, y el correo llegará con tu nombre.
La defensa no es un producto que se compra: son tres estándares abiertos que se configuran una vez en el DNS del dominio y trabajan juntos.
Capa 1 · SPF — quién puede enviar en mi nombre
SPF (Sender Policy Framework) es una lista blanca de los servidores autorizados a enviar correo con tu dominio. Si un mensaje sale de un servidor que no está en la lista, el receptor sabe que algo huele mal. Es un registro TXT. En mi caso, el correo va por Zoho, así que:
v=spf1 include:zohomail.eu ~all
El ~all indica "lo que no esté autorizado, trátalo como sospechoso". Solo puede existir un registro SPF por dominio.
Capa 2 · DKIM — una firma que prueba que es auténtico
DKIM (DomainKeys Identified Mail) añade a cada correo una firma criptográfica. El servidor de envío firma con una clave privada y el receptor verifica con la clave pública publicada en tu DNS. Demuestra dos cosas: que el correo salió de verdad de ti y que nadie lo manipuló por el camino. La clave pública se publica en un registro TXT bajo un "selector" (en mi proveedor, zmail._domainkey).
Capa 3 · DMARC — qué hacer con quien falla (y visibilidad)
DMARC (Domain-based Message Authentication) es el que ata todo: le dice al receptor qué hacer con los correos que no pasan SPF/DKIM, y —clave— te envía informes de quién está intentando enviar en tu nombre. Su política es progresiva:
-
p=none— solo observa e informa (no afecta a la entrega). -
p=quarantine— lo que falla va a spam. -
p=reject— lo que falla se rechaza directamente.
Lo mío está en quarantine con alineamiento estricto y con informes activados:
v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:...@adeodato.es; fo=1
La forma correcta de avanzar es empezar en none, revisar los informes unas semanas para asegurarte de que no bloqueas nada legítimo, y subir después a quarantine y reject.
Sin esto: el doble castigo
Un dominio sin autenticación sufre lo peor de dos mundos: por un lado, cualquiera puede suplantarte; por otro, tus correos legítimos acaban en spam, porque los proveedores desconfían de lo que no está autenticado. Pierdes seguridad y entregabilidad a la vez.
La web también: empieza por los cimientos
La misma lógica aplica al sitio web: adeodato.es va por HTTPS y con el dominio bien configurado. La seguridad no es una capa que se añade al final, es el cimiento sobre el que se construye lo demás.
Crear, no comprar
Nada de esto es un producto ni una licencia: son estándares abiertos y públicos que cualquiera puede implementar y auditar. Prefiero soluciones que entiendo y poseo, sin ataduras de proveedor.
La lección
Autenticar el correo es de las medidas de mayor impacto y menor coste que existen: se configura una vez y protege para siempre contra un vector de ataque que sigue siendo el número uno. Lo apliqué primero en mi propia casa — predico con el ejemplo — porque la mejor forma de recomendar algo es haberlo hecho tú antes.
Escrito por Rafael Adiosdado Caballero Diéguez — **Adeodato, ciberseguridad IT/OT y desarrollo seguro. Más en adeodato.es.
Top comments (0)