Chiffrement opportuniste ou obligatoire
Presque tout le courriel est chiffré « si possible ». La question utile n'est pas de savoir si votre fournisseur chiffre — c'est ce qu'il fait quand il ne peut pas.
Deux messagers
Le premier utilise un fourgon blindé quand il y en a un de libre. Sinon, il prend son vélo. Le colis arrive toujours ; parfois seulement, il a traversé la ville à découvert. C'est le chiffrement opportuniste, et c'est le comportement par défaut de pratiquement tous les fournisseurs de courriel au monde.
Le second n'utilise que le fourgon. Pas de fourgon, pas de livraison : le colis reste à l'entrepôt et on vous prévient. Il n'est pas perdu, il n'est pas renvoyé à l'expéditeur marqué « introuvable » — il attend. C'est le chiffrement obligatoire, et c'est ce que vous activez par clé d'API quand le contenu l'exige.
Ce que fait le second messager avec le colis compte autant que son refus de rouler à découvert. Nous y revenons plus bas : c'est là que notre comportement diffère de la plupart des autres.
Normal
le défaut
Chiffrer chaque fois que le serveur destinataire le propose. Sinon, livrer quand même — parce que ne pas livrer serait pire pour la quasi-totalité du courrier.
Requis
quand le contenu l’exige
Ne livrer que sur une connexion TLS vérifiée. À défaut, ne pas expédier du tout.
Que se passe-t-il, concrètement ?
| Le serveur destinataire… | Normal | Requis |
|---|---|---|
| offre TLS avec un certificat valide | livré, chiffré | livré, chiffré |
| n'offre aucun chiffrement | livré en clair | non expédié |
| offre TLS avec un certificat expiré, auto-signé ou au mauvais nom | livré en clair ou chiffré sans preuve d’identité | non expédié |
| est injoignable | réessais, puis échec | réessais, puis échec |
La ligne du milieu est la raison d'être du mode requis. En mode normal, l'absence de chiffrement n'est signalée nulle part : le message part, arrive, et rien n'indique qu'il a voyagé lisible.
Que veut dire « vérifié » ?
Pas seulement « chiffré ». Le serveur destinataire doit annoncer STARTTLS, présenter un certificat de confiance, non expiré et correspondant au nom de son enregistrement MX, et négocier au minimum TLS 1.2.
Un certificat auto-signé chiffre la connexion sans prouver à qui l'on parle. C'est exactement ce dont dépend une interception active : le trafic est chiffré, mais vers l'intercepteur. Le mode requis traite ces cas comme des échecs.
Et si le message ne peut pas partir ?
C'est ici que nous différons de la plupart des descriptions du chiffrement obligatoire, qui parlent d'un « retour à l'expéditeur ». Chez nous, rien ne rebondit.
Dans l'ordre : le message est retenu, jamais expédié en clair. Si l'obstacle était passager, une nouvelle tentative le livre chiffré quelques secondes plus tard et vous ne voyez qu'une livraison. S'il est permanent, nous le vérifions nous-mêmes en interrogeant le serveur du destinataire, puis l'état devient blocked — en général en moins d'une minute, sans attendre l'épuisement des tentatives.
L'adresse n'est jamais supprimée. Elle est valide et rien n'a été transmis : le destinataire n'entre pas dans votre liste de suppression, et les outils de gestion de listes qui retirent les adresses « ayant rebondi » ne le retireront pas. C'est ce qui empêche une exigence de sécurité de vous coûter des abonnés.
Et si le destinataire corrige son chiffrement ensuite, une tentative ultérieure aboutit et l'état redevient delivered tout seul.
Vous savez toujours pourquoi
Chaque blocage porte une raison lisible par machine, dans GET /v1/email/{id} et dans l'événement blocked du webhook :
| Raison | Ce qui s'est passé |
|---|---|
| no_starttls | Le serveur destinataire n'offre aucun chiffrement. |
| cert_expired | Son certificat est expiré. |
| cert_self_signed | Son certificat est auto-signé — chiffré, mais non vérifiable. |
| cert_name_mismatch | Son certificat vise un autre nom que celui de son MX. |
| cert_untrusted | Son certificat provient d'une autorité inconnue. |
| tls_version | Il ne négocie que des versions TLS antérieures à 1.2. |
| starttls_withheld | Il offre le chiffrement à d'autres expéditeurs, mais pas à nous. |
| refused | Il a refusé la connexion avant tout échange. |
| connect_failed | Injoignable — aucun serveur de courriel accessible. |
Lequel choisir ?
Normal pour les infolettres, les notifications produit, les reçus — tout ce dont la non-livraison coûte plus cher que la lecture par un tiers. C'est la quasi-totalité du courriel, et c'est pour cela que c'est le défaut.
Requis pour les dossiers médicaux, les documents juridiques, les relevés financiers, les identifiants, les alertes internes — tout ce dont vous répondez si le contenu est lu en route. Le réglage vit sur la clé d'API, pas sur le compte : une clé « facturation » peut exiger le chiffrement pendant que la clé « infolettre » reste en mode normal, même domaine, même expéditeur.
Ce que le mode requis vous coûte
Certains destinataires deviennent injoignables. Un petit serveur mal entretenu, une administration locale, une adresse chez un hébergeur qui n'a pas renouvelé son certificat : en mode requis, vous ne leur écrivez plus. C'est le but, mais c'est un coût réel et il faut le prévoir.
Vous héritez d'un problème qui n'est pas le vôtre. Le certificat à corriger appartient au destinataire. Vous ne pouvez que le lui signaler — d'où la raison précise attachée à chaque blocage.
Ce n'est pas du chiffrement de bout en bout. Cela protège le message en transit seulement. Une fois que le serveur du destinataire l'a accepté, il est entre ses mains : ce que sa messagerie en fait ensuite ne dépend plus de nous. Ce que cela élimine, c'est la lecture passive sur le réseau entre nous et lui — le trajet sur lequel vous n'avez autrement aucune visibilité.
Le réglage est sur la clé, pas sur le compte
Changez-le en une fois dans le tableau de bord, clé par clé, sans redéploiement.
Créer un compte