MTA-STS, TLS-RPT y BIMI: los siguientes pasos después de DMARC

MTA-STS: entrega cifrada o ninguna

Los servidores de correo cifran con STARTTLS cuando ambos lados lo admiten, pero vuelven al texto plano si falta la oferta, y un atacante en el camino puede quitarla. MTA-STS (RFC 8461) publica una promesa: «mis hosts MX siempre tienen certificados válidos; no entregues sin TLS». Hace falta un registro DNS y un pequeño archivo de texto en un servidor web:

; announces the policy; change id whenever the policy file changes
_mta-sts.example.com.  3600 IN TXT   "v=STSv1; id=20261013T1200"
; the web host that serves the policy file over HTTPS
mta-sts.example.com.   3600 IN CNAME static-host.example.

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

• mode: testing informa de los fallos pero sigue entregando; enforce se niega a entregar sin TLS válido; none retira la política.
• mx: una línea por host MX, exactamente como en tus registros MX. Un *. inicial coincide con una etiqueta, útil para proveedores con muchos hosts.
• max_age: cuánto tiempo guardan los remitentes la política, en segundos. Una semana (604800) mientras pruebas; varios meses cuando sea estable.

1. Consigue un certificado válido para mta-sts.example.com y sirve el archivo en /.well-known/mta-sts.txt; vale cualquier alojamiento estático.
2. Publica _mta-sts con un id nuevo (una marca de tiempo es cómoda).
3. Añade el registro TLS-RPT de la sección siguiente y funciona en testing durante dos a cuatro semanas.
4. Cuando los informes estén limpios, cambia mode a enforce y actualiza el id.

TLS-RPT: informes de cifrado fallido

TLS-RPT (RFC 8460) pide a los servidores remitentes que te envíen un resumen diario de sus conexiones TLS con tus servidores de correo: cuántas salieron bien y por qué fallaron las demás: certificado caducado, nombre que no coincide, falta de STARTTLS, error al obtener la política.

_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Google, Microsoft y otros grandes proveedores envían estos informes como archivos JSON. El registro por sí solo no cambia nada en la entrega, así que es seguro publicarlo primero. Con MTA-STS en testing, es la forma de saber si enforce rompería algo.

BIMI: tu logotipo en la bandeja de entrada

BIMI (Brand Indicators for Message Identification) permite que los buzones compatibles muestren tu logotipo en lugar de una inicial junto a los mensajes que superan DMARC. El registro apunta al logotipo y, normalmente, a un certificado que demuestra que puedes usarlo:

default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"

• DMARC debe estar en aplicación: p=quarantine o p=reject en el dominio, sin pct inferior a 100 y sin sp=none.
• El logotipo es un SVG cuadrado en el perfil restringido «SVG Tiny Portable/Secure», servido por HTTPS. Una exportación SVG normal suele ser rechazada.
• Gmail solo muestra el logotipo con certificado: un VMC (Verified Mark Certificate), que exige una marca registrada, o un CMC (Common Mark Certificate), que exige que el logotipo lleve al menos un año en uso. Yahoo puede mostrarlo sin él.

En qué orden

1. SPF, DKIM y DMARC con p=none e informes (consulta Cómo configurar DMARC).
2. TLS-RPT: gratis, inofensivo e informativo desde el primer día.
3. MTA-STS en testing y después enforce, cuando los informes TLS estén limpios.
4. DMARC subido a p=quarantine y luego a p=reject.
5. BIMI, si un logotipo en la bandeja de entrada te compensa el certificado.