Por Qué Cada Ajuste Del Correo Tiene Que Estar Bien

Cada nombre que tu máquina resolvió hoy, se lo creyó, y escribí un post entero sobre eso. Este va sobre lo que le pasa al correo después de la resolución. La versión corta: se envía a un servidor elegido por DNS, por un canal que solo va cifrado si nadie se opone, cargando un mensaje que cualquiera en el camino puede leer y cambiar, y casi ninguna de las protecciones que se inventaron para impedirlo está activada.

No es una sola cosa rota. Son siete, cada una diseñada para que, cuando está mal, el correo pase igualmente. Sin error. La factura llega. El restablecimiento de contraseña llega. Solo que también llegan a, o a través de, alguien que nunca debería haberlos visto, y en ningún sitio se dice nada.

Este post es el argumento para dejar cada uno de esos ajustes bien, con la prueba de lo que vale cada uno. Los tres posts siguientes lo construyen en servidores reales: Postfix, Microsoft 365 y Stalwart. Este es el porqué.

El Ataque Que La Norma Describe Y Luego Prohíbe

Empieza por la tubería entre dos servidores de correo, porque es la que la mayoría piensa que ya está resuelta. STARTTLS es el comando que eleva una conexión SMTP a TLS. La mayoría de los servidores de correo lo soportan, la mayoría del correo va cifrado en tránsito, y eso suena a problema resuelto hasta que lees cómo se ofrece esa elevación.

El servidor que recibe anuncia STARTTLS en su saludo. El servidor que envía ve la oferta y la toma. Nada firma esa oferta, y nada la protege. Así que una máquina en el camino entre ambos puede borrar la línea, y este es el resultado, capturado en un laboratorio desde un emisor puesto en el modo oportunista normal por defecto:

 ~> EHLO client.test
[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
 -> Please pay invoice 1042 to sort code 20-00-00, account 12345678.
<-  250 2.0.0 Ok: queued as D6A84132069C

El emisor no vio que se ofreciera STARTTLS, así que hizo lo que significa oportunista: envió igualmente, en claro. La máquina del medio leyó todo, factura y datos bancarios incluidos. El correo se entregó. Ningún error llegó a nadie.

Yo no inventé ese ataque. El RFC 3207, la norma que define STARTTLS, lo describe con precisión en sus propias Consideraciones de Seguridad:

A man-in-the-middle attack can be launched by deleting the “250 STARTTLS” response from the server. This would cause the client not to try to start a TLS session.¹

La misma sección da la defensa, y es la obvia: poder exigir TLS. “both clients and servers MUST be able to be configured to require successful TLS negotiation … for selected hosts before messages can be successfully transferred.”¹ Así que configura el receptor para exigirlo, y la sesión arrancada se rechaza:

[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
<** 530 5.7.0 Must issue a STARTTLS command first

Salvo que no puedes, no en un MX público, porque la misma norma lo prohíbe:

A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.²

Lee esas dos citas juntas. La norma describe un ataque man-in-the-middle, te dice que la defensa es exigir TLS, y luego te dice que tu servidor de correo público no tiene permitido exigirlo. Léelo dos veces. Esa regla se escribió en 2002 para mantener el correo fluyendo entre servidores que todavía no podían hacer TLS todos. Sigue vigente, y es por lo que la mayor parte de internet todavía acepta correo en claro, y por lo que arrancar STARTTLS todavía funciona hoy.

Hay una versión competente del atacante, también. Un receptor que exige TLS no te salva, porque el atacante no tiene que pasar la sesión en claro. Puede leer el texto claro degradado del emisor y abrir su propia conexión TLS perfectamente válida hacia el receptor, que ve un certificado bueno y se queda contento. Enseñé las dos mitades en el laboratorio: el arranque que expone al emisor, y un cliente TLS normal que el receptor estricto acepta sin quejarse. La política del receptor no puede frenar esto. Solo lo frena que el emisor se niegue a enviar sin TLS autenticado, y ese es todo el argumento a favor de DANE³ y MTA-STS,⁴ que vienen más adelante en este post.

Siete Ajustes, Y Cómo Falla En Abierto Cada Uno

La tubería es uno de dos problemas. El otro es la identidad: un mensaje que llega cifrado solo está afirmando ser de quien dice. Así que hay siete ajustes en juego, repartidos entre esos dos trabajos, y lo que tienen en común es lo primero que vale la pena aprender.

Aquí tienes cada uno: qué protege, y qué hace cuando está mal puesto. Fíjate en la última columna. Casi siempre dice que el correo pasa igual.

Seis de esos siete, mal puestos, siguen entregando el correo. DANE es la excepción. Es el único ajuste de toda la lista que falla en cerrado: equivócate y tu correo se para en vez de filtrarse. Guarda esa idea, porque resulta ser la razón por la que la gente le tiene miedo, y la razón por la que es el que más vale.

Unas palabras sobre cada uno de los tres de identidad, porque el resto de esta serie se apoya en ellos. SPF lista los servidores autorizados a enviar por un dominio, y termina en una regla: -all significa «nadie más», ~all significa «nadie más, pero entrégalo igualmente». DKIM añade una firma criptográfica sobre el mensaje, así cualquier cambio se nota, siempre que el dominio haya publicado de verdad una clave contra la que comprobarla. DMARC ata los dos y le dice al receptor qué hacer cuando fallan, y si cuadran con la dirección From: que el lector ve realmente. Son los RFC 7208, 6376 y 7489, y cada uno merece un post propio.^{6 7 8}

DMARC por sí solo deja pasar una factura manipulada

La capa de identidad tiene un hueco justo donde más cuesta, y vale la pena enseñarlo porque «tenemos DMARC en reject» es lo que dice la gente cuando cree que está cubierta.

DMARC pasa si alguno, SPF o DKIM, pasa y cuadra con el dominio del From:. Alguno, no ambos. Así que coge un mensaje real firmado de un dominio, cambia los datos bancarios en el cuerpo, y reenvíalo desde el mismo sitio:

SPF sigue pasando, porque vino de un servidor autorizado. La firma DKIM ahora falla, porque el cuerpo se cambió. Pero DMARC solo necesita un paso alineado, y SPF le dio uno, así que DMARC pasa y el mensaje con el número de cuenta nuevo se entrega con el mismo aspecto exacto que el original. Capturé esto en el laboratorio: Rspamd lo puntuó con R_SPF_ALLOW, R_DKIM_REJECT y DMARC_POLICY_ALLOW, y por sí solo lo habría entregado. Lo único que lo frenó fue una regla que rechaza de plano con una firma rota. Un dominio en p=reject no está protegido contra la manipulación que esa firma estaba ahí para pillar. Eso vale la pena saberlo antes de dar el trabajo por hecho.

DANE Solo Vale Lo Que El DNSSEC Que Hay Debajo

Ahora los ajustes de transporte que de verdad frenan al atacante competente, porque trasladan la decisión al emisor. DANE es el más fuerte de ellos. Permite que un dominio publique, en DNS, una huella de la clave que su servidor de correo va a presentar en un registro TLSA, de modo que un servidor emisor pueda rechazar cualquier cosa que no coincida.⁹ Sin autoridad de certificación de por medio, sin fiarse de quienquiera que respondiera el handshake TLS. El dueño del dominio dice «esta es mi clave», y ahí se acaba.

Salvo que las respuestas de DNS son falsificables, así que una huella publicada en DNS normal no vale nada: el mismo atacante que arranca STARTTLS puede darte una huella falsa que cuadre con una clave falsa. DANE solo significa algo cuando el DNS en el que vive está firmado con DNSSEC, de modo que la propia huella no se pueda falsificar. Esa es toda la cadena, y es por lo que este post está en una serie que empezó con DNSSEC. Si no lo conoces, los cimientos están en /es/dns/dnssec-the-root-is-signed-you-are-not/, y la versión de una línea es: la raíz está firmada, todos los TLD que merece la pena nombrar están firmados, y luego se para en seco en los nombres que la gente usa de verdad.

El diagrama muestra dos dominios que publican ambos un registro TLSA. Uno está en una zona firmada, con una cadena de firmas sin romper desde la raíz hasta la huella, así que un emisor puede fiarse. El otro está en una zona sin firmar, así que su huella son solo bytes que cualquiera podría haber escrito, y un emisor correcto la ignora por completo y no obtiene ninguna protección DANE. El mismo registro, publicado de dos maneras. Solo una puede demostrar que es real.

El registro a publicar es 3 1 1: la clave propia del servidor en vez de la de una CA, la clave pública en vez del certificado entero, con hash SHA-256. El número del medio es el que paga operativamente, porque fijar la clave en vez del certificado significa que el registro sobrevive a cada renovación mientras conserves la misma clave. El post de Postfix tiene el procedimiento completo y la trampa que pilla a la gente, que es que la forma habitual de renovar certificados genera una clave nueva cada vez y rompe el registro sin avisar. Para aquí, lo que hay que llevarse es que 3 1 1 más reutilización de clave es un registro que publicas una vez y dejas en paz.

Las Reglas De La Casa, Y Lo Que Cuesta Cada Una

Todo lo de arriba se convierte en una lista corta de reglas, y los tres posts siguientes someten a ellas a servidores reales. No están suavizadas, y no son gratis. Aquí están con la factura adjunta, porque una regla cuyo coste escondes es una regla que no has decidido mantener de verdad.

El coste del reenvío es el que muerde, y es real: rechaza solo por SPF y un mensaje reenviado desde un sitio que no está en el registro SPF del emisor se rechaza, porque para el receptor un reenviador tiene exactamente la misma pinta que un falsificador. Hay arreglos, SRS y ARC,¹⁰ y el post de Postfix enseña el fallo. La posición honesta es que estas reglas rebotan algo de correo que un servidor más laxo habría entregado. Ese es su sentido. Parte de ese correo debería haberse rebotado, y el resto te está avisando de una configuración de reenvío que dependía de que nadie comprobara nada.

Falla En Abierto, Y Aquí Está La Prueba

La afirmación sobre la que descansa todo este post es que estos ajustes fallan en abierto, sin ruido, así que no puedes distinguir uno que funciona de uno roto con solo mirar. No es una preocupación teórica. Montando el servidor Postfix para el post siguiente, pasó cada uno de estos fallos, y cada uno era un ajuste que parecía configurado y no hacía nada.

Seis ajustes reales, cada uno de montar el servidor Postfix para el post siguiente. Cinco fallaron en abierto: entregaron el correo, sin error, con toda la pinta de estar funcionando bien. El sexto, el registro DANE caducado, falló en cerrado. Es el que todo el mundo teme, y es el único que protegió el mensaje en vez de filtrarlo. La lección está justo ahí en la última columna del diagrama: el ajuste que la gente evita porque podría parar su correo es el único que se comporta como se supone que debe hacerlo un control de seguridad.

Cada fila de eso es una captura, no una lectura de un manual. La forma de distinguir un ajuste que funciona de uno roto es enviar el mensaje que se supone que debe frenar y mirar lo que vuelve, y lo digo una vez aquí y lo demuestro tres veces a lo largo del resto de la serie.

Entonces, ¿Quién Hace Realmente Algo De Esto?

Una cosa es decir que los ajustes importan. Otra es preguntar si las organizaciones cuyo correo más importa los han activado. Así que lo hice, con nada más que DNS de solo lectura y un resolver validante, el 22 de octubre de 2026: veintiséis dominios que reciben correo, los bancos, los grandes proveedores, los especialistas alemanes y las autoridades de certificación, cada uno comprobado por las siete cosas de este post.¹¹

Lee primero hacia abajo la columna de DMARC, porque es la que está casi toda rellena. La mayoría de estos publican una política DMARC, y la mayoría de los bancos están en reject. DMARC es el ajuste que se hace, porque es el que pregunta un auditor y el que te puede vender un proveedor, y es visible: lo puedes consultar y marcar una casilla. Es también, por sí solo, el ajuste que dejó pasar una factura manipulada antes en este post.

Ahora lee la columna de DANE, el único ajuste de aquí que no se puede degradar ni se puede falsificar. Cinco dominios de veintiséis. Cada uno de ellos es un proveedor alemán o Proton. Ni un solo banco del Reino Unido. Ni una sola de las autoridades de certificación, las empresas cuyo negocio entero es dar fe de claves. La protección más fuerte contra el ataque exacto con el que abrió este post la hace un puñado de gente a la que le importa, y nadie que sea meramente cumplidor.

Los bancos son la fila más afilada. Ocho de ellos, todos en DMARC reject, y entre todos: nada de DANE, nada de MTA-STS en enforce, y uno solo, Monzo, alcanzable por IPv6. Dos de las cuatro autoridades de certificación no publican registro SPF en su propio ápice. HMRC y NatWest tampoco tienen ninguno. Estos no son chiringuitos pequeños que nunca se pusieron a ello. Estas son las organizaciones que te mandan el correo que más miedo te da que alguien falsifique, y la protección que tienen es la insignia que parece la más fuerte y hace lo menos.

La columna de IPv6 es su propio pequeño escándalo. Veinte de los veintiséis no tienen ningún registro AAAA en su servidor de correo, así que un emisor que corre en una red solo-IPv6 no puede alcanzarlos, y ese número va en una sola dirección. Escribí /es/networking/we-never-ran-out-of-addresses/ sobre la negativa de la industria a terminar ese trabajo, y aquí está otra vez, en el camino del correo esta vez. Tiene la misma forma que el censo de gov.uk en /es/dns/dnssec-the-root-is-signed-you-are-not/: la parte difícil se hizo hace años, los registradores lo regalan, y la gente que más obviamente debería usarlo no lo ha hecho. El gov.uk central ni siquiera está en la tabla, porque no publica ningún MX. No recibe correo. Esa es una forma de pasar la prueba.

Si Todavía No Haces Esto, ¿Puedes Llamarte Profesional?

Cada norma nombrada en este post, y el censo que hay debajo, apuntan en una sola dirección: esto no es un problema de investigación, es un problema de encenderlo, y el encenderlo no lo está haciendo la gente mejor situada para hacerlo. Cuando la evidencia está así de desequilibrada, la pregunta deja de ser académica y se vuelve una que tienes que responder sobre tus propios servidores. Si llevas el correo de una organización que maneja el dinero de otros o la salud de otros, y tu MX no hace DANE, no obliga con MTA-STS y no se puede alcanzar por IPv6, ¿puedes llamar a eso un trabajo profesional?

Hay tres respuestas honestas, y solo las dos primeras se sostienen. Sí, con una razón escrita y una fecha al lado: estás en una plataforma que todavía no ofrece DANE, lo has planteado, y hay una línea en el plan del año que viene. Eso es un profesional gestionando una restricción real, y está bien. Sí, porque no lo sabías, y ahora lo sabes, y vas a ir a averiguar dónde está tu servidor esta semana. Nadie empezó sabiendo esto. Y no: sabías lo bastante para estar inquieto, has leído hasta aquí, y vas a cerrar la pestaña y no cambiar nada, porque el correo fluye y no salta ningún error y nadie te obliga. Esa última no es una laguna de conocimiento. Es una decisión de dejar que una cosa de la que eres responsable siga rota porque rota es más silenciosa.

La norma no te obliga a hacerlo. Ese es todo el problema, y es también todo el sentido. Saber no es algo que te pase, y nadie va a venir a decirte que tu servidor de correo lleva dos años enviando en claro sin hacer ruido. Por eso, asegurarte de saberlo es el trabajo, y no es de nadie más.

Una Norma Es Una Promesa Que Cumples Cuando Nadie Mira

Las piezas de esto estaban todas terminadas hace años. STARTTLS es de 2002, SPF y DKIM y DMARC tienen una década o más, DANE para correo se especificó en 2015, MTA-STS en 2018. Nada de ello está detrás de una licencia, nada de ello necesita un proveedor, y los registradores que llevarían los registros DNSSEC los regalan. La ingeniería difícil está hecha. Lo que queda es la parte fácil, la parte que solo es fácil si alguien se molesta: encenderlo, y comprobar que está de verdad encendido, y mantenerlo encendido cuando el certificado se renueva y el registro tiene que seguirlo.

Esa última parte es todo, en realidad. Una norma no es el documento. El documento lleva veinte años existiendo y el correo todavía va en claro. Una norma es algo que cumples cuando no hay ningún mensaje de error obligándote a cumplirla, cuando el correo fluiría igual si la dejaras caducar sin ruido, cuando la única persona que llegaría a saberlo eres tú. Cada uno de estos ajustes falla en abierto precisamente para que nadie esté obligado a que le importe. Lo que significa que que te importe es el trabajo entero.

No te dan premio por ello. La factura que no se alteró tiene exactamente la misma pinta que la que sí. El restablecimiento de contraseña que nadie leyó en tránsito tiene exactamente la misma pinta que el que sí leyeron. La única diferencia está en los días en que algo lo intentó, y en esos días la persona que lo encendió todo y comprobó que funcionaba nunca se entera de que la atacaron, porque no funcionó. Así es como se ve hacer el trabajo bien desde fuera: que no pasa nada, por razones que nadie puede ver.

Así que deja cada ajuste bien de todas formas. No porque alguien esté comprobando, porque nadie lo está. Hazlo porque eres tú quien dijo que el correo estaba seguro, y por aquí eso todavía cuenta para algo.