Configurar DANE para SMTP: registros TLSA y DNSSEC para tu servidor de correo

Qué significa

Por defecto, los servidores que te entregan email usan TLS (STARTTLS) solo "si es posible", y no comprueban tu certificado. Un atacante en la red podría eliminar STARTTLS o presentar un certificado falso. DANE para SMTP (RFC 7672) cierra ese hueco: publicas en el DNS un registro TLSA que indica qué certificado o clave usa tu servidor de correo, y DNSSEC demuestra que ese registro es auténtico. Los servidores de envío compatibles con DANE se niegan entonces a entregar sin un TLS válido y coincidente.

El registro TLSA de un servidor de correo se publica en _25._tcp. seguido del nombre de host del MX:

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 8f1c...e4a2

Los tres números significan: 3 = el propio certificado del servidor (DANE-EE), 1 = comparar solo la clave pública (no el certificado completo), 1 = hash SHA-256. 3 1 1 es la opción habitual para SMTP.

DANE y MTA-STS resuelven el mismo problema de formas distintas. MTA-STS usa HTTPS y funciona sin DNSSEC; DANE necesita DNSSEC. Puedes publicar los dos y usar TLS-RPT (explicado en la guía de MTA-STS) para recibir informes de ambos.

Por qué ocurre

Puede que estés configurando DANE porque:

• una auditoría de seguridad, una norma pública o sectorial, o una prueba tipo internet.nl lo exige (algo habitual en los Países Bajos y Alemania);
• quieres proteger el correo entrante de los ataques de degradación (downgrade);
• una prueba DANE indica que tu registro TLSA ya no coincide tras renovar el certificado, lo que hace que los remitentes con DANE dejen de entregarte correo.

Cómo comprobarlo

1. DNSSEC: la zona del nombre de host de tu MX debe estar firmada. Con dig, busca la marca ad de un resolver que valide:

   dig +dnssec MX yourdomain.com @1.1.1.1
   ;; flags: qr rd ra ad;

   Si el MX apunta al host de tu proveedor (Google, Microsoft 365...), es su zona la que necesita DNSSEC y TLSA, no la tuya.
2. Registro TLSA:

   dig +dnssec TLSA _25._tcp.mail.yourdomain.com

3. Compara con el certificado en uso:

   openssl s_client -connect mail.yourdomain.com:25 -starttls smtp \
     -servername mail.yourdomain.com </dev/null 2>/dev/null \
     | openssl x509 -noout -pubkey \
     | openssl pkey -pubin -outform DER | openssl dgst -sha256

   El hash debe ser igual al último campo del registro TLSA.
4. Herramienta de Postfix: posttls-finger -t30 -T180 -c -L verbose,summary yourdomain.com indica si la validación DANE funciona.
5. Usa el escáner de dominios para confirmar los nombres de host de tus MX antes de empezar.

Cómo solucionarlo

1. Activa DNSSEC

Activa DNSSEC en tu proveedor DNS y añade el registro DS en tu registrador (muchos lo hacen automáticamente). Comprueba con Whois qué registrador gestiona el dominio. Sin una cadena DNSSEC válida, los registros TLSA se ignoran.

2. Obtén el hash de la clave del servidor

En el servidor de correo, a partir del archivo de certificado en uso:

openssl x509 -in /etc/ssl/mail/fullchain.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER | openssl dgst -sha256

3. Publica el registro TLSA

Host:  _25._tcp.mail      (for MX host mail.yourdomain.com)
Type:  TLSA
Usage: 3   Selector: 1   Matching type: 1
Value: <the SHA-256 hex hash>

Publica un registro por cada nombre de host MX. El certificado debe seguir siendo un certificado normal y válido cuyo nombre coincida con el host, para que los remitentes sin DANE y MTA-STS sigan funcionando.

4. Planifica las renovaciones de certificado

Aquí es donde fallan la mayoría de las configuraciones DANE. Con 3 1 1, el hash depende de la clave, no del certificado, así que:

• Renueva los certificados conservando la misma clave privada (por ejemplo, con la opción --reuse-key de Certbot), o
• Usa un esquema "actual + siguiente": genera la siguiente clave por adelantado, publica un segundo registro TLSA para ella, espera al menos dos TTL, cambia el servidor a la nueva clave y elimina más tarde el registro antiguo.

5. Valida DANE al enviar (opcional)

Si usas Postfix y un resolver local que valida DNSSEC, activa DANE para el correo saliente en main.cf:

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

Para lo básico de TLS en tu propio servidor, consulta emails enviados sin TLS.

Comprueba que está solucionado

Espera a que caduquen las cachés DNS y vuelve a ejecutar dig +dnssec TLSA (debe volver con la marca ad), compara el hash con el certificado en uso y ejecuta de nuevo posttls-finger. Envía un email desde un buzón externo a tu dominio y busca una conexión TLS en el registro del servidor de correo. Haz también una prueba en Delivmail desde tu servidor para confirmar que el envío sigue funcionando. Vuelve a comprobarlo tras cada renovación de certificado.