Associer le serveur, le port et le mode de chiffrement
Les paramètres de courriel Lexoh relient les messages sortants pris en charge à un service de messagerie par SMTP, le protocole de transfert de courrier. Les messages, réglages et autorisations d’envoi disponibles dépendent de votre installation. Ouvrez la configuration avec un administrateur autorisé et confirmez les processus qui l’utilisent.
Obtenez le nom d’hôte SMTP, le port, le mode de chiffrement, la méthode d’authentification et l’expéditeur autorisé auprès de l’administrateur de messagerie. Saisissez le nom d’hôte sans préfixe https:// ni chemin de page Web. Utilisez le nom documenté par le fournisseur plutôt qu’une adresse IP de remplacement.
Associez toujours le port au mode de chiffrement. Avec TLS implicite, le chiffrement commence dès l’ouverture; avec STARTTLS, la connexion SMTP passe à TLS avant la transmission des identifiants ou du contenu. Exigez une négociation TLS et une validation du certificat réussies. Une connexion sécurisée au serveur d’envoi ne démontre pas un chiffrement de bout en bout.
587 et STARTTLS
Une combinaison courante pour la soumission de messages, si le fournisseur et votre installation Lexoh la prennent en charge. Confirmez que TLS est exigé, et pas seulement tenté.
465 et TLS implicite
Utilisez cette combinaison seulement si le fournisseur la documente. Un réglage nommé SSL/TLS peut désigner TLS implicite; vérifiez son sens au lieu de changer le port sans adapter le mode.
25 ou 2525
Le port 25 sert aussi entre serveurs de messagerie et aux relais configurés; il n’est pas simplement obsolète. Le port 2525 est une option propre à certains fournisseurs. Aucun numéro seul ne garantit le chiffrement ou l’autorisation.
Utiliser l’authentification approuvée pour le compte
Confirmez les méthodes prises en charge par votre version de Lexoh et le fournisseur avant de saisir des identifiants. Un formulaire avec nom d’utilisateur et mot de passe ne démontre pas la prise en charge d’OAuth. Un mot de passe de boîte, un mot de passe d’application et un identifiant SMTP ne sont pas nécessairement interchangeables.
Utilisez une identité d’envoi dédiée avec les autorisations requises pour l’expéditeur choisi. Saisissez les secrets uniquement par le processus de configuration approuvé. Un champ masqué ne prouve pas le chiffrement du stockage; demandez la documentation de sécurité applicable si le stockage ou la gestion des clés doit être vérifié.
Coordonnez le renouvellement avec l’administrateur : mettez à jour la configuration, testez-la, puis révoquez l’ancien identifiant selon la procédure du compte. Retirez mots de passe, jetons et codes d’accès actifs des captures et demandes de soutien. Résolvez une incompatibilité d’authentification avec le fournisseur et Lexoh plutôt que de désactiver les protections du compte.
Vérifier l’expéditeur et la destination des réponses
Choisissez un nom d’affichage reconnaissable et une adresse De que votre organisation est autorisée à utiliser. Le nom aide à reconnaître le message; il n’authentifie pas l’expéditeur.
L’adresse De visible, le compte de connexion SMTP, l’expéditeur d’enveloppe utilisé pour les échecs de livraison et l’adresse Répondre à peuvent avoir des rôles différents. Si Répondre à est configuré, les réponses peuvent y aller plutôt qu’à De. Testez leur destination réelle. Nommer une adresse noreply n’empêche pas, à lui seul, les réponses.
Le domaine de l’adresse De n’a pas à être identique au nom d’hôte SMTP du fournisseur. Faites vérifier l’autorisation d’envoi et les exigences SPF, DKIM et DMARC par l’administrateur. SPF contrôle l’infrastructure d’envoi autorisée; DKIM signe les messages; DMARC vérifie l’alignement avec le domaine De visible et définit une politique de traitement. Leur réussite ne garantit pas le placement dans la boîte de réception.
Vérifier le déclencheur avant l’envoi automatique
Pour une option d’envoi de carte d’accès, confirmez l’état enregistré, la source du destinataire et le déclencheur : création, attribution, renvoi ou autre action. Vérifiez les types d’identifiants et les dossiers clients ou opérateurs concernés. Ne supposez pas que l’option est active par défaut ou couvre toutes les méthodes de création.
Examinez un vrai message de test : langue, site, consignes d’entrée, contact de soutien et période de validité applicable. Si un code QR ou un lien est inclus, testez la lisibilité et la destination avec un identifiant de test. Vérifiez dans votre installation les modèles disponibles et les champs insérés.
Créer un identifiant, générer un message, le recevoir et être autorisé au lecteur sont des étapes distinctes. Une carte envoyée ne contourne pas ses règles d’accès, son horaire ou son expiration. Renvoyer un message ne crée pas nécessairement un nouvel identifiant et ne révoque pas automatiquement l’ancien.
Avant un envoi groupé, testez avec des dossiers contrôlés et vérifiez le nombre de destinataires, les doublons et les limites du fournisseur. Confirmez le fonctionnement de la file et des reprises avant de renvoyer après un retard. Désactiver les futurs avis ne rappelle pas nécessairement les messages en attente ou déjà reçus. Prévoyez une autre procédure de remise pour les visiteurs sans accès aux courriels.
Tester la soumission, la réception et le processus réel
Un test réussi couvre le trajet et le destinataire testés. Il ne démontre pas le fonctionnement de tous les modèles, destinataires ou déclencheurs. Utilisez une boîte de test autorisée et un dossier sans effet opérationnel; les étapes suivantes décrivent une vérification, sans garantir un délai de réception.
- Consignez l’environnement, les réglages de messagerie sans secrets, l’expéditeur et le destinataire prévu. Confirmez si le test utilise les réglages enregistrés ou les valeurs actuelles du formulaire.
- Envoyez un seul test avec la commande disponible. Notez l’heure, le résultat de l’application et la référence du message, si fournie. Évitez les clics répétés pendant l’attente.
- Comparez le résultat aux journaux disponibles du fournisseur. Distinguez connexion, TLS, authentification, soumission, mise en file, rejet et livraison au serveur destinataire.
- Vérifiez la boîte de réception, les indésirables et la quarantaine de l’organisation. Examinez expéditeur, destination des réponses, langue, liens et pièces jointes. Notez l’heure réelle d’arrivée sans supposer un délai fixe.
- Testez le déclencheur automatique concerné avec un dossier contrôlé. Pour un identifiant d’accès, vérifiez séparément le lecteur prévu, l’horaire et la validité selon la procédure du site.
- Vérifiez un cas d’échec approuvé, comme une adresse ou un mode de test du fournisseur, avant de compter sur la gestion des erreurs. Déterminez qui suit les échecs et si les reprises peuvent doubler les messages. N’utilisez pas l’adresse d’une personne étrangère au test.
| Observation | Ce qu’elle démontre |
|---|---|
| Identifiant créé | Le dossier de test existe. Ni la réception ni l’autorisation au lecteur n’ont encore été démontrées. |
| L’application indique envoyé | Vérifiez le sens de cet état et la référence du fournisseur. Il peut désigner la soumission plutôt que la livraison finale. |
| Le fournisseur confirme l’acceptation par le serveur destinataire | Le système destinataire a accepté le message. Le placement en boîte, la lecture et l’identité restent des vérifications distinctes. |
| Message visible dans la boîte de test | La réception dans cette boîte est vérifiée. Examinez le contenu et la destination des réponses. |
| Identifiant de test accepté au lecteur prévu | Cet identifiant a fonctionné dans les conditions testées. Les autres lecteurs, horaires et l’expiration nécessitent leurs propres vérifications. |
Confirmer les exigences actuelles du fournisseur
Références fournisseurs vérifiées le 30 septembre 2026. Ces notes décrivent leurs exigences, sans certifier une intégration Lexoh. Confirmez la politique du compte, la région, les limites d’envoi et les méthodes d’authentification disponibles dans votre installation.
Comptes Google
Les mots de passe d’application nécessitent la validation en deux étapes et peuvent être indisponibles selon le compte ou l’organisation. Google privilégie Se connecter avec Google lorsque cette option est prise en charge. Confirmez une méthode compatible approuvée plutôt que de supposer que tout compte peut générer un mot de passe d’application.
Microsoft 365 / Exchange Online
Microsoft documente smtp.office365.com avec STARTTLS sur le port 587 pour la soumission cliente et recommande OAuth. Vérifiez les politiques de la boîte et de l’organisation ainsi que la compatibilité de l’application. Les comptes personnels Outlook.com ont des consignes distinctes. Un mot de passe de boîte n’est pas une configuration universelle.
Twilio SendGrid
SendGrid documente smtp.sendgrid.net, le nom d’utilisateur apikey et une clé API avec les autorisations nécessaires comme mot de passe SMTP. Confirmez la combinaison TLS/port et l’autorisation de l’expéditeur. Le mot de passe de connexion au compte n’est pas cet identifiant SMTP.
Mailgun
Utilisez les identifiants SMTP du domaine d’envoi sélectionné et le serveur documenté. Confirmez la région du compte et la combinaison TLS/port. Ne remplacez pas le mot de passe SMTP du domaine par une clé API et ne supposez pas qu’un environnement d’essai autorise les destinataires de production.
Examiner l’étape qui échoue
Gardez un bref journal de test avec le résultat attendu, le résultat observé, l’heure et la référence du message. Transmettez les éléments pertinents au soutien sans secrets. Après correction, répétez le cas d’échec et un processus réussi avant d’élargir le changement à d’autres destinataires.
Échec de connexion ou de TLS
Vérifiez le nom d’hôte, la combinaison port/mode approuvée, le DNS, les règles réseau sortantes, l’heure système et la validation du certificat depuis le système d’envoi. Ne contournez pas les contrôles de certificat et ne passez pas en mode non chiffré pour masquer l’erreur.
Authentification ou expéditeur refusé
Conservez la réponse exacte sans identifiants. Vérifiez le type de secret, l’état du compte, l’authentification permise et les autorisations Envoyer en tant que ou de validation d’expéditeur. Un mot de passe correct ne résout pas un refus de politique ou d’autorisation.
Accepté, mais non reçu
Vérifiez le destinataire, la référence du fournisseur, la file, les avis d’échec, les exclusions d’envoi et la quarantaine. Revoyez l’authentification du domaine avec l’administrateur. Identifiez la cause avant un renvoi pour éviter les doublons.
Le test arrive, mais pas le message automatique
Vérifiez le déclencheur, l’option enregistrée, le champ destinataire, le modèle et la file du processus réel. Un test générique peut ne pas exercer ces éléments.
Contenu erroné ou identifiant inutilisable
Comparez le dossier de test associé, la langue, la validité, la destination et la configuration du lecteur. Corrigez le modèle ou la règle d’accès responsable; un nouvel envoi seul peut laisser le problème intact.