Pourquoi ne puis-je pas envoyer d’e-mails depuis TrekMail ?

Les échecs d’envoi ont quelques causes courantes. Effectuez ces vérifications dans l’ordre. Si le compte et le domaine sont prêts mais qu’un seul destinataire rejette le message, examinez le serveur de messagerie du destinataire.

Vérification 1 : l’adresse du propriétaire du compte n’est pas validée

Si vous avez créé un compte TrekMail le 19 février 2026 ou après et n’avez pas cliqué sur le lien de validation, l’envoi est bloqué après un délai de grâce de 7 jours. Le tableau de bord affiche une bannière rouge : L’envoi d’e-mails sortants est suspendu.

Les mêmes 7 jours recommencent quand vous remplacez une adresse de connexion vérifiée par une nouvelle : confirmez la nouvelle adresse dans les 7 jours pour continuer à envoyer.

Cela concerne l’adresse de connexion du propriétaire du compte, pas les boîtes aux lettres. Si elle n’est pas validée, toutes les boîtes cessent d’envoyer jusqu’à la validation.

Par API, les envois et les envois programmés sont refusés avec le code account_email_unverified jusqu’à la validation de l’adresse.

Solution :

• Cherchez dans la boîte de l’adresse de connexion l’e-mail de validation envoyé par TrekMail lors de l’inscription, puis ouvrez son lien.
• Vous l’avez perdu ? Cliquez sur Renvoyer l’e-mail de validation dans la bannière.
• Avec une connexion sociale, vérifiez l’état dans le Tableau de bord au lieu de supposer que le fournisseur l’a validé.
• Si le lien ne fonctionne plus, demandez un nouvel e-mail au lieu de réutiliser l’ancien.

Les comptes créés avant le 19 février 2026 ne sont pas soumis à ce blocage.

Vérification 2 : le DNS du domaine n’est pas validé

Le domaine doit être prêt avant d’utiliser la route d’envoi gérée. La page DNS indique le registre manquant, en conflit ou en cours de contrôle. SPF, DKIM et DMARC aident aussi les destinataires à évaluer vos messages.

Symptôme : état « Domaine non validé » sur la page Domaines, messages qui partent puis rebondissent ou arrivent dans les indésirables.

Solution : ouvrez Domaines, sélectionnez le domaine et son état DNS. Comparez chaque registre, corrigez-le chez le fournisseur DNS puis utilisez Vérifier le DNS. Le résultat peut rester en attente pendant la propagation. Voir Vérification de l’état DNS.

Vérification 3 : vous utilisez Nano

Le forfait Nano définit can_send: false. L’authentification SMTP aboutit, mais chaque envoi est refusé à la soumission.

Symptôme : le client affiche « Échec de l’envoi » avec une erreur 5xx, le message passe brièvement par la boîte d’envoi puis revient.

Solution : choisissez un forfait avec envoi géré sur la page Forfaits, puis vérifiez le forfait actif et l’état du domaine avant de réessayer.

Si vous devez rester sur Nano, configurez BYO SMTP pour le domaine. Le SMTP personnalisé est disponible sur tous les forfaits. Vous fournissez les identifiants d’un prestataire externe et TrekMail utilise cette route. La réception IMAP reste indépendante.

Vérification 4 : limite quotidienne ou horaire atteinte

Chaque forfait impose des maximums quotidiens par boîte et par compte, une limite horaire et un plafond de destinataires par message :

(Nano peut s’authentifier, mais sa route gérée est désactivée. Les limites peuvent être inférieures pour un nouveau domaine, un compte sans paiement antérieur, un essai ou les 24 premières heures après le premier paiement du compte. Ce tableau donne le maximum du forfait ; le Tableau de bord affiche le quota quotidien du compte réellement en vigueur aujourd’hui, et l’onglet SMTP de chaque domaine indique les limites de ce domaine pour aujourd’hui, y compris le préchauffage d’un nouveau domaine et les dates auxquelles elles augmentent.)

Symptôme : l’envoi fonctionne, puis en cours de journée les nouveaux messages ne partent plus et vous voyez l’un de ces signes :

• Dans le webmail, une fenêtre s’ouvre au-dessus de votre message, qui reste ouvert. Elle indique la part de la limite déjà utilisée, pourquoi la limite est plus basse en ce moment (un essai, le premier jour après le premier paiement ou un nouveau domaine) et quand elle se renouvelle, dans votre fuseau horaire.
• Dans une application de messagerie, l’envoi échoue avec une réponse temporaire en anglais qui contient le code 4.7.1, la limite atteinte, les chiffres et l’heure de renouvellement, par exemple « Daily sending limit reached for this account (50 of 50 today; trial account). Sending resumes at 00:00 UTC. » ou « Hourly sending limit reached for this account (15 per hour; trial account). Sending resumes at 14:00 UTC. » Pendant les 24 premières heures après le premier paiement, la réponse le précise et indique l’heure à laquelle les limites complètes commencent, par exemple « (150 of 150 today; first payment under 24 hours ago, full limits from 2026-10-13 07:00 UTC) ».

Solution : lisez d’abord le message : il indique quelle limite est atteinte et quand elle se renouvelle. Ensuite :

• Attendez le renouvellement plutôt que de relancer l’envoi. Les limites quotidiennes se renouvellent à 00:00 UTC, et la limite horaire au début de chaque heure (UTC).
• Pendant un essai, la personne qui gère la facturation peut y mettre fin plus tôt depuis Facturation → Mettre fin à l’essai et démarrer l’abonnement maintenant. L’abonnement payant démarre et les limites de l’essai sont relevées aussitôt ; les limites complètes du forfait s’appliquent 24 heures après ce premier paiement.
• Pendant les 24 premières heures après le premier paiement, chaque boîte et l’ensemble du compte peuvent écrire à 150 destinataires par jour, un message peut être adressé à 50 personnes et les applications de messagerie peuvent envoyer 60 messages par heure. Au bout de 24 heures, les limites complètes du forfait s’appliquent d’elles-mêmes ; le Tableau de bord indique l’heure exacte.
• Un nouveau domaine suit un préchauffage pendant ses 7 premiers jours (40 % les jours 1 à 3, 70 % les jours 4 à 7, la limite complète à partir du jour 8). Seuls ce domaine et ses boîtes sont concernés ; vos autres domaines gardent leur quota complet.
• Le courrier transféré compte aussi. Les messages transférés qui quittent TrekMail consomment le même quota quotidien du compte que vos propres envois.
• Passer à un forfait supérieur augmente le quota du forfait. Pendant un essai, cela ne lève pas les limites de l’essai (seule la fin de l’essai les lève), pendant les 24 premières heures après le premier paiement tous les forfaits ont les mêmes limites du premier jour, et cela ne renvoie jamais les messages déjà refusés : renvoyez-les dès qu’il y a de la place.

Vérification 5 : nombre de destinataires par message

Le plafond par message est de 50 pour Nano, 100 pour Starter, 250 pour Pro et 500 pour Agency. Tout message au-dessus peut être refusé avant l’envoi. Pendant un essai, le plafond est de 10 destinataires par message jusqu’au premier paiement, puis de 50 pendant les 24 heures qui suivent ; le webmail vous avertit avant d’envoyer un message qui le dépasse et refuse de le programmer.

Solution : divisez-le en lots conformes ou changez de forfait.

Vérification 6 : la boîte ne peut pas envoyer

La boîte doit être active et autorisée à envoyer. Elle peut être désactivée, perdre cette capacité après un changement de forfait ou de domaine, ou voir ses envois temporairement suspendus pour contrôle de sécurité. Lisez le message du Tableau de bord ou de l’application avant de modifier les réglages.

Symptôme : une boîte échoue tandis qu’une autre du même compte fonctionne.

Solution : ouvrez la boîte dans le Tableau de bord et confirmez qu’elle est active. Si le message cite le compte, le forfait ou le domaine, réglez cela d’abord. Une suspension de connexion bloque normalement la connexion, mais n’arrête pas à elle seule le courrier entrant.

Par API, l’envoi depuis une boîte dont l’envoi n’est plus disponible après un changement d’offre ou de domaine est refusé avec le code mailbox_send_disabled. La pause temporaire d’envoi décrite ci-dessous a son propre code.

Pause temporaire des envois

Seuls les envois d’une boîte peuvent être suspendus tandis que réception et lecture continuent. Cela arrive si l’activité laisse penser que les identifiants ont été exposés et protège le domaine pendant la vérification des accès.

Symptôme : le courrier arrive et reste lisible, mais les messages sortants ne partent pas :

• Dans le webmail : « Les envois depuis cette boîte sont suspendus après une activité inhabituelle. Contactez l’assistance pour les rétablir. »
• Dans une application : l’envoi échoue, la réception fonctionne et l’application signale que le serveur refuse votre adresse comme expéditeur.
• Par API : l’envoi est refusé avec le code mailbox_sending_paused.

Solution : une vérification par l’assistance est nécessaire. Les contrôles ordinaires de la boîte ne lèvent pas cette pause.

1. Changez le mot de passe de la boîte, voir Sécurité de la boîte.
2. Reconnectez chaque téléphone, application de messagerie ou script SMTP avec un nouveau mot de passe d’application, ou celui de la boîte si elle l’accepte encore. Une réinitialisation par un administrateur révoque tous les mots de passe d’application ; dans le webmail, cochez Révoquer aussi tous les mots de passe d’application lorsque vous changez votre propre mot de passe après une compromission.
3. Ouvrez un ticket sur la page Assistance, indiquez le changement, l’adresse et l’heure approximative, mais jamais le mot de passe.

Le courrier peut toujours arriver. Enregistrez localement les brouillons importants jusqu’au rétablissement.

Vérification 7 : le compte est suspendu

Une suspension du compte peut bloquer les envois et d’autres actions. Une bannière en explique la cause :

• « Votre compte présente un problème de facturation. Mettez à jour vos données de paiement ou contactez l’assistance. » Mettez les données à jour puis vérifiez l’état de facturation. Voir Corriger les paiements échoués.
• « Nous avons temporairement suspendu les envois car les serveurs destinataires ont rejeté trop de messages récents. » Ouvrez un ticket. L’équipe peut demander des informations sur la liste, l’expéditeur et un exemple expurgé.
• « Votre compte est temporairement limité. Contactez l’assistance pour plus de détails. » Pour un problème d’abus ou de sécurité, demandez une vérification.

Changer de boîte ou de domaine ne contourne pas la suspension. Elle s’applique à tout le trafic sortant jusqu’à sa levée.

Vérification 8 : l’authentification SMTP échoue

Si le client affiche « 535 Authentication failed » ou « Invalid credentials » :

• Mot de passe ou mode de connexion incorrect. SMTP exige un mot de passe d’application pour une boîte avec Mots de passe d’application uniquement. Avec Mot de passe de la boîte ou mots de passe d’application, les deux fonctionnent. N’utilisez jamais le mot de passe du tableau de bord du propriétaire du compte. Créez un mot de passe d’application dans le webmail sous Paramètres > Mots de passe d’application, ou dans le tableau de bord sous Boîtes mail > (boîte) > Sécurité > Mots de passe d’application.
• Boîte inexistante. Consultez la liste des boîtes. Une faute de configuration peut désigner une autre boîte.
• Adresse du propriétaire non validée après le délai. Voir Vérification 1. La validation est imposée lors de la soumission.

Si l’application affiche "Sign-in failed. This mailbox accepts app passwords only: create one in webmail under Settings > App passwords." (Échec de la connexion. Cette boîte accepte uniquement les mots de passe d’application : créez-en un dans le webmail sous Paramètres > Mots de passe d’application), créez un mot de passe d’application et saisissez-le pour la réception et l’envoi. Certaines applications affichent seulement « mot de passe incorrect ». Consultez Mots de passe d’application.

Une réinitialisation par un administrateur ou une récupération révoque tous les mots de passe d’application. Créez-en de nouveaux pour les applications concernées, ou mettez à jour le mot de passe de la boîte là où il est encore accepté, puis reconnectez-les. Ne relancez pas un mot de passe révoqué ou ancien.

Vérification 9 : BYO SMTP mal configuré

Si le domaine utilise un prestataire SMTP externe :

• Vérifiez ses identifiants dans l’onglet SMTP du domaine : Domaines, choisissez le domaine, puis SMTP.
• Confirmez que la soumission SMTP est activée chez ce prestataire ; certains exigent aussi leur propre validation du domaine.
• Utilisez le test de l’onglet SMTP et lisez son résultat avant un envoi réel.

Des identifiants externes invalides peuvent produire une erreur générale. Corrigez-les chez le prestataire, enregistrez la connexion et retestez.

Vérification 10 : le serveur du destinataire vous rejette

Si tout est au vert chez TrekMail mais que certains domaines rebondissent :

• Le serveur peut désapprouver votre réputation (nouveau domaine, aucun préchauffage, SPF/DKIM non alignés). Voir Taux de rebond trop élevé et Règles de préchauffage.
• Si de nombreux domaines sans lien échouent ensemble, consultez la page d’état TrekMail et joignez erreurs et horodatages au ticket.
• Certains serveurs refusent une authentification incomplète ou une politique DMARC faible. Vérifiez SPF, DKIM et DMARC avant de modifier le contenu ou de relancer un lot.

Signification des codes d’erreur courants

Toujours bloqué

Ouvrez un ticket sur la page Assistance. Indiquez :

• La boîte expéditrice (alice@yourcompany.com).
• L’adresse du destinataire, ou un exemple si plusieurs rebondissent.
• L’erreur exacte du client ou du message de rebond.
• Si le webmail peut envoyer le même message au même destinataire. (S’il échoue aussi, le problème est côté serveur.)

Pour examiner une suspension de délivrabilité, soyez prêt à expliquer le consentement des destinataires et à fournir un exemple expurgé si demandé. N’envoyez pas une liste complète, des identifiants ni des données sans rapport.

Articles connexes

• Limites d’envoi par forfait
• Erreurs d’envoi courantes et solutions
• Registres DNS requis (MX, SPF, DKIM, DMARC)
• Règles de préchauffage du domaine
• SMTP personnalisé (BYO SMTP)
• Taux de rebond trop élevé
• E-mails classés comme indésirables
• Vous ne recevez pas d’e-mails ?