Le problème : expédier du courrier transactionnel depuis son propre domaine, et savoir ce qu'il devient — pas « délivré à 98 % », mais « refusé chez orange.fr avec le code 550 5.1.1, et plus personne n'ouvre depuis mardi ».
LeTock construit et signe lui-même chaque message : MIME, DKIM avec une clé propre au domaine du client, liste de suppression, chronologie. Aucune API propriétaire dans la chaîne.
LeTock remet lui-même. Il résout le MX du destinataire, ouvre la connexion SMTP vers son serveur, et lit son code de retour. C'est ce qui permet de rendre le texte exact du serveur distant, adresse par adresse — ce qu'aucun webhook de tiers ne donne.
Le port 25 sortant a été débloqué par notre hébergeur le 23 septembre 2026. Le relais qui servait de dernier saut jusque-là est retiré, et l'état relaye n'est plus produit.
## ⚠ Une adresse IP d'envoi neuve doit se chauffer C'est la seule chose qui compte les premières semaines, et elle ne se rattrape pas. Notre adresse d'expédition est neuve : pour les grands fournisseurs de boîtes, elle n'a aucune histoire, et ils traitent l'absence d'histoire comme un risque. Mesure du premier jour, sur deux cent cinquante remises réelles : Google, OVH, IONOS, Outlook et SFR acceptent normalement ; Orange et Wanadoo refusent la connexion (« Adresse IP source bloquée ») ; trois domaines d'entreprise répondent5.7.1 Client host blocked. L'ordre qui marche. Les messages *attendus* d'abord — confirmations d'inscription, reçus, liens de connexion. Ils sont ouverts, rarement signalés, et construisent une réputation propre. Les relances ensuite. La prospection en dernier, une semaine après. Trois cents messages froids par jour depuis une adresse de deux heures est le moyen le plus sûr de la faire classer durablement — et une réputation perdue se reconstruit en mois, pas en jours. Le bac à sable (bac_a_sable: true) ne coûte rien et ne touche pas à la réputation : éprouve tout dessus avant le premier vrai envoi. ### ⚠ Et le pendant, côté retours : ne traite pas ces refus comme des rebonds Les premiers jours, une partie des refus vise notre adresse d'expédition et non tes destinataires — « Client host blocked », « cannot find your reverse hostname », « Adresse IP source bloquée ». Ce sont des refus qui disparaîtront d'eux-mêmes. Si ton code brancherefusetrebond_dursur « retirer l'adresse », il supprimera des adresses parfaitement valides, le premier jour, au moment précis où tu n'as aucune raison de te méfier. C'est arrivé : vingt-cinq entreprises en une heure, dont trois enseignes du cœur de cible et l'adresse personnelle du propriétaire du site. Lis `cause`. Chaque remise et chaque événement le portent :destinataire,expediteuroutransport. Ne retire une adresse que surdestinataire. C'est une seule condition à écrire, et elle rend ce piège impossible.
Les paliers de chauffe
« Monte doucement » ne veut rien dire : personne ne sait si trois cents par jour c'est doucement. Voici les chiffres.
| Jour | Remises recommandées, pour toute la plateforme |
|---|---|
| 1 | 50 |
| 2 | 100 |
| 3 | 200 |
| 4 | 400 |
| 5 | 800 |
| 6 | 1 500 |
| 7 | 2 500 |
| 8 | 4 000 |
| 9 | 6 000 |
| 10 | 8 000 |
| 11 | 12 000 |
| 12 et après | chauffe terminée, le quota du forfait reprend seul |
Le compte est celui des destinataires remis, pas des messages mis en file : c'est ce que voit le serveur d'en face, et c'est lui qui juge. Un message à trois destinataires vaut trois connexions vers trois serveurs. Le bac à sable n'y entre pas.
Le palier est global, et c'est le point qu'aucun guide de chauffe ne traite. Tous les domaines expédient depuis la même adresse IP. Un client qui envoie trois cents messages froids le premier jour ne brûle pas sa réputation : il brûle celle de tout le monde, y compris celle des liens de connexion de la plateforme.
C'est pour ça que le dépassement est signalé à tous, pas seulement à celui qui dépasse. Chacun a le droit de savoir que l'adresse qu'il emprunte est mise sous tension par quelqu'un d'autre.
On reporte, on ne refuse pas. POST /api/v1/mails répond toujours 202. Au-delà du palier du jour, le message est accepté et reporté au lendemain — il part, plus tard, sans perdre de tentative et sans que tu aies à le renvoyer :
```json { "id": "…", "etat": "en_attente", "envoyer_a": "2026-09-24T00:05:00Z", "avertissements": [
"Adresse d'expédition en chauffe, jour 3 : 312 remises aujourd'hui pour 200 recommandées. …" ] }
```
envoyer_a dit quand. Un report tu est un report qu'on découvre en constatant que rien n'est arrivé.