MTA-STS, TLS-RPT et BIMI : les étapes suivantes après DMARC

MTA-STS : livraison chiffrée, ou pas de livraison

Les serveurs de messagerie chiffrent avec STARTTLS quand les deux côtés le gèrent, mais reviennent au texte clair si l'offre manque — et un attaquant sur le chemin peut la supprimer. MTA-STS (RFC 8461) publie un engagement : « mes hôtes MX ont toujours des certificats valides ; ne livrez pas sans TLS ». Il faut un enregistrement DNS et un petit fichier texte sur un serveur 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 signale les échecs mais livre quand même ; enforce refuse de livrer sans TLS valide ; none retire la politique.
• mx : une ligne par hôte MX, exactement comme dans vos enregistrements MX. Un *. en tête correspond à un label, pour les fournisseurs aux nombreux hôtes.
• max_age : durée pendant laquelle les expéditeurs gardent la politique en cache, en secondes. Une semaine (604800) pendant les tests ; plusieurs mois une fois stable.

1. Obtenez un certificat valide pour mta-sts.example.com et servez le fichier à /.well-known/mta-sts.txt — n'importe quel hébergement statique convient.
2. Publiez _mta-sts avec un nouvel id (un horodatage est pratique).
3. Ajoutez l'enregistrement TLS-RPT de la section suivante et restez en testing deux à quatre semaines.
4. Quand les rapports sont propres, passez mode à enforce et changez l'id.

TLS-RPT : des rapports sur le chiffrement raté

TLS-RPT (RFC 8460) demande aux serveurs expéditeurs de vous envoyer chaque jour un résumé de leurs connexions TLS vers vos serveurs de messagerie : combien ont réussi, et pourquoi les autres ont échoué — certificat expiré, nom non concordant, STARTTLS absent, erreur de récupération de la politique.

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

Google, Microsoft et d'autres grands fournisseurs envoient ces rapports sous forme de fichiers JSON. À lui seul, l'enregistrement ne change rien à la livraison : vous pouvez le publier en premier sans risque. Avec MTA-STS en testing, c'est lui qui vous dira si enforce casserait quelque chose.

BIMI : votre logo dans la boîte de réception

BIMI (Brand Indicators for Message Identification) permet aux messageries compatibles d'afficher votre logo au lieu d'une initiale à côté des messages qui passent DMARC. L'enregistrement pointe vers le logo et, en général, vers un certificat prouvant que vous avez le droit de l'utiliser :

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

• DMARC doit être appliqué : p=quarantine ou p=reject sur le domaine, sans pct inférieur à 100 et sans sp=none.
• Le logo est un SVG carré au profil restreint « SVG Tiny Portable/Secure », servi en HTTPS. Un export SVG ordinaire est généralement refusé.
• Gmail n'affiche le logo qu'avec un certificat : un VMC (Verified Mark Certificate), qui exige une marque déposée, ou un CMC (Common Mark Certificate), qui exige que le logo soit utilisé depuis au moins un an. Yahoo peut l'afficher sans.

Dans quel ordre

1. SPF, DKIM et DMARC en p=none avec rapports (voir Configurer DMARC).
2. TLS-RPT — gratuit, sans risque et instructif dès le premier jour.
3. MTA-STS en testing, puis enforce une fois les rapports TLS propres.
4. DMARC passé en p=quarantine, puis en p=reject.
5. BIMI, si un logo dans la boîte de réception vaut le certificat pour vous.