Correo que llega: todo lo que comprueba internet.nl y por qué

LA PUNTUACIÓN

Cómo comprobar la configuración

internet.nl es una prueba gratuita del gobierno neerlandés y varias organizaciones de internet. Importan dos partes: sitio web y dominio de correo. Cada prueba se aprueba o falla y ambas partes son públicas.

Puede ejecutar las pruebas sobre ave17.com; la hoja de ruta describe la publicación prevista de resultados fechados.

La puntuación mide configuración, no conducta: demuestra que falsificar el dominio no es fácil y que el correo viaja cifrado. No demuestra que quienes lo gestionan respondan al correo.

QUIÉN LO ENVIÓ

SPF, DKIM y DMARC, en el orden relevante

Entre los tres responden si el mensaje procede realmente del dominio. Suelen desplegarse en orden incorrecto; por eso tantos dominios tienen los tres y siguen siendo falsificables.

SPF

Enumera las máquinas autorizadas para enviar por el dominio. Barato pero débil por sí solo: falla al reenviar un mensaje porque el reenviador no figura en la lista.

DKIM

Firma el propio mensaje y sobrevive al reenvío. Firmamos con dos claves, RSA y Ed25519, porque algunos receptores no entienden la segunda y preferimos no elegir.

DMARC

Indica qué hacer cuando fallan los dos anteriores y pide un informe. El nuestro es p=reject: rechazarlo. Algo menos estricto es una petición cortés que la mayoría de remitentes ignora.

El orden correcto es DKIM, SPF y DMARC en supervisión hasta que los informes no detecten problemas; después, reject. Ir directamente a reject revela públicamente qué sistemas enviaban correo sin que la organización lo supiera.

CÓMO VIAJÓ

Cifrado que no se puede eliminar

Los servidores llevan veinte años ofreciendo cifrado oportunista; un atacante intermedio puede retirar la oferta y hacer que vuelvan a texto plano sin que ninguno lo detecte. Dos mecanismos lo impiden y faltan en la mayoría de dominios.

MTA-STS

Política servida por HTTPS: "use siempre TLS con estos nombres de host; si no puede, no entregue". La publicamos en modo enforce, el único que actúa.

DANE

Publica en DNS, firmado por DNSSEC, el certificado esperado por el receptor. El remitente lo comprueba contra el dominio, no una lista de autoridades. Publicamos registros TLSA en submission, submissions, IMAPS y el propio intercambiador de correo.

DNSSEC

Firma las propias respuestas DNS. Sin ello, un atacante puede reescribir los registros en tránsito; por eso DANE lo exige y firmamos todas nuestras zonas.

MTA-STS y DANE se solapan deliberadamente. Uno es fácil y confía en certificados web; el otro es más difícil y confía en DNSSEC. Tener ambos protege el dominio alcance el atacante el que alcance.

LA PARTE WEB

Qué exige la prueba del sitio

La parte web trata sobre la misma idea: impedir degradar la conexión y sustituir el certificado.

• IPv6 en el sitio y sus servidores de nombres, accesible y con el mismo contenido que IPv4
• DNSSEC en la zona para impedir reescribir la dirección
• HTTPS con cifrados modernos, HSTS y sin vía de degradación
• DANE también para el certificado web, algo casi inexistente
• CAA cerrado para que solo la autoridad nombrada pueda emitir para el dominio
• Cabeceras que impiden incrustar la página en marcos o reinterpretarla mediante inspección de contenido

DOS COSAS QUE CONVIENE ENTENDER

Dónde puede engañar la puntuación

Primero: p=reject en un dominio que nunca envía es trivial; uno con tráfico real lo alcanza después de semanas leyendo informes. Igual puntuación, trabajo muy distinto. Para comparar proveedores, pregunte cuál hicieron.

Segundo: DANE exige comprobación por el receptor y buena parte del mundo no la hace. Publicarlo protege ante quienes sí lo comprueban sin coste con los demás, pero no garantiza que un mensaje concreto viajara cifrado. Nadie puede garantizarlo.

Y algo incómodo: esto no detiene un mensaje convincente de un dominio parecido al suyo. Es otro problema, que resuelven las personas y no los registros.

CUÁNTO COSTÓ

Con franqueza

Un día para configurar el primer dominio y unos veinte minutos por cada otro, ya con plantilla. Lo que requiere tiempo es leer informes DMARC durante dos semanas antes de pasar con seguridad a reject; no se puede comprar ni apresurar.

Lo operamos nosotros, sin proveedor de correo, por eso podemos describirlo. Preferir un proveedor es razonable y debe pedirle los mismos registros anteriores.