Aller au contenu

Procédure sécurisée pour modifier le DNS de caritasbenin.com (SMTP transactionnel)

Contexte

Suite du problème d'envoi d'emails transactionnels de jobPipeline (voir jobPipeline/decisions/explication-non-technique-echec-envoi-emails-caritasbenin et jobPipeline/architecture/procedure-cablage-auth-package). Deux domaines distincts entrent en jeu :

  • caritasbenin.org : réservé à l'administration, Bernard n'a pas de marge de manœuvre dessus. Un problème de sélecteur DKIM y a été identifié et un ticket envoyé à LWS (Documents/20260703_1846_ticket-lws-dkim-caritasbenin-org.md dans le projet jobPipeline).
  • caritasbenin.com : le vrai domaine de travail — toutes les adresses email des employés (dont celle du service de Bernard, tic@caritasbenin.com) sont dessus. Bernard a un accès DNS via cPanel sur ce domaine. C'est le domaine à corriger durablement.

caritasbenin.com a un blocage plus grave que .org : les emails sortants authentifiés y sont rejetés purement et simplement (550 classified as SPAM) par un filtre anti-spam au niveau serveur (root LWS), avant même toute vérification DKIM/SPF côté destinataire — confirmé déjà lors d'un projet précédent (veille-financement/configuration-email-deliverabilite). Un ticket a été rédigé pour LWS mais a peu de chances d'aboutir (réglage réservé au root du serveur mutualisé).

Solution retenue : contourner totalement le serveur mail LWS pour l'envoi transactionnel de l'application, en gardant tic@caritasbenin.com comme expéditeur visible, via un service dédié (Brevo ou ZeptoMail — ce dernier déjà éprouvé pour tekdhi.dev). Ça nécessite d'ajouter des enregistrements DNS (SPF include:, DKIM sous un nouveau sélecteur) sur la zone caritasbenin.com.

Consigne explicite de Bernard, à respecter absolument : ce domaine porte les emails de tous les employés de l'organisation — aucune perturbation n'est tolérée sur les comptes existants. Toute erreur serait très grave (domaine de production partagé, pas un projet perso).

Contenu

Procédure validée pour appliquer ce changement sans risque pour les autres comptes @caritasbenin.com :

Principe de sécurité

Ne jamais remplacer un enregistrement DNS existant — uniquement ajouter. Vérifier après chaque étape avant de passer à la suivante.

Étapes

  1. Sauvegarde de référence — capturer et documenter l'état DNS complet actuel de caritasbenin.com (SPF, DKIM, DMARC, MX) avant toute modification, comme point de retour arrière.

  2. SPF — Bernard modifie lui-même l'enregistrement SPF dans cPanel, en copiant-collant une valeur fournie au caractère près : l'ancien contenu intégral + le nouveau include: du fournisseur choisi à la fin. Rien d'autre ne change. (SPF actuel de .com : v=spf1 ip4:91.234.194.124 include:premiumsmtp.dnshostservices.com ip4:91.234.194.231 ip4:78.138.45.237 +a +mx ~all — ne pas remplacer par la version "suggérée" simplifiée de cPanel, qui omet des sources tierces déjà utilisées par l'organisation.)

  3. Vérification immédiate par dig après la modification SPF — confirmer que le nouvel enregistrement contient tout l'ancien contenu, inchangé, plus l'ajout. Ne pas avancer si ce n'est pas le cas.

  4. DKIM — Bernard ajoute la clé DKIM du nouveau fournisseur sous un sélecteur dédié et nouveau (ex. brevo._domainkey.caritasbenin.com), qui n'existe pas encore — aucune collision possible avec l'existant. (.com n'a actuellement aucun DKIM configuré du tout, contrairement à .org qui a un sélecteur default valide.)

  5. Test de non-régression AVANT de toucher à l'application — envoyer un email test depuis une boîte employé existante normale (webmail ou client mail habituel) pour confirmer qu'elle fonctionne exactement comme avant. Ne pas passer à l'étape suivante tant que ce n'est pas confirmé.

  6. Seulement ensuite, brancher jobPipeline sur le nouveau fournisseur (.env : SMTP_HOST/PORT/USER/PASS du fournisseur choisi, EMAIL_FROM=tic@caritasbenin.com conservé) et tester l'inscription réelle.

Pourquoi c'est sûr (justification technique)

  • SPF/DKIM/DMARC sont additifs par construction — ajouter une source autorisée de plus n'invalide ni ne modifie le comportement des sources déjà autorisées (le serveur mail LWS existant, premiumsmtp.dnshostservices.com, etc.). Les employés continuent d'envoyer/recevoir exactement comme avant.
  • La DMARC (p=quarantine) s'applique déjà uniformément à tous les emails @caritasbenin.com aujourd'hui — l'ajout d'un expéditeur autorisé de plus ne change ni ne durcit cette politique pour les autres comptes.
  • Point de vigilance résiduel (pas un risque nouveau, déjà vrai pour les sources SPF existantes) : SPF/DKIM autorisent un serveur, pas une adresse précise — quiconque a accès au compte Brevo/ZeptoMail pourrait techniquement envoyer sous n'importe quelle adresse @caritasbenin.com. Mitigation : restreindre l'accès aux identifiants de ce nouveau compte à l'application/Bernard, et si le fournisseur le permet, activer une restriction d'expéditeurs autorisés côté Brevo/ZeptoMail (limiter à tic@caritasbenin.com uniquement).

Décision / Conclusion

Procédure validée par Bernard (en attente d'exécution — reprise prévue à la prochaine session). Choix du fournisseur (Brevo vs ZeptoMail) encore à trancher avant l'étape 1.

À faire

  • Ticket LWS rédigé pour le blocage SPAM (voir jobPipeline/decisions/ticket-lws-spam-caritasbenin-com), à envoyer par Bernard — chances de succès faibles, ne bloque pas ce qui suit.
  • Choisir Brevo ou ZeptoMail.
  • Exécuter l'étape 0 (capture de l'état DNS actuel de caritasbenin.com) dès la reprise.
  • Suivre les étapes 1 à 6 dans l'ordre, sans sauter la vérification intermédiaire.
  • Suivi du ticket LWS pour le DKIM de .org (Documents/20260703_1846_ticket-lws-dkim-caritasbenin-org.md), en parallèle mais sans dépendance avec cette procédure .com.

Liens connexes