Utiliser le serveur SMTP de Proximus ou Telenet pour le courrier de l'entreprise : pourquoi ça coince
Le serveur SMTP de votre fournisseur d'accès est conçu pour la boîte privée d'une famille, pas pour le courrier d'une entreprise. Dès que votre boutique en ligne, votre logiciel de facturation ou votre CRM l'utilisent, vous butez sur des limites d'envoi, sur une réputation partagée avec des milliers d'autres clients et sur l'absence d'authentification pour votre propre domaine. Pour tout ce qui envoie du courrier automatiquement, la solution est un relais SMTP avec un identifiant distinct par application.
Pourquoi on essaie quand même
C'est tentant. Les paramètres figurent sur le site du fournisseur, ils fonctionnent tout de suite sur l'ordinateur du gérant et ils ne coûtent rien de plus. Quelqu'un saisit donc le même nom de serveur dans la caisse, la boutique et le programme de facturation. Les premières semaines, tout semble aller. Les ennuis arrivent quand le volume augmente ou quand un destinataire devient plus strict.
Problème 1 : les limites d'envoi
Des fournisseurs comme Proximus et Telenet plafonnent en général le nombre de messages qu'un client peut envoyer par heure ou par jour via leur serveur, et parfois le nombre de destinataires par message. Ces plafonds suffisent largement à quelqu'un qui écrit à sa famille, et sont bien trop bas pour une boutique un jour de forte activité ou un logiciel qui expédie cent factures le premier du mois. Ce qui dépasse est refusé ou discrètement retardé. Votre client constate que sa facture n'est pas arrivée ; vous, vous le découvrez quand il appelle.
Problème 2 : une réputation qui n'est pas la vôtre
Le serveur sortant d'un fournisseur envoie au nom de centaines de milliers d'abonnés en même temps. La réputation de cette adresse IP dépend de tous ces clients réunis, y compris l'ordinateur infecté qui envoie du spam à l'insu de son propriétaire. Si ce serveur est temporairement bloqué chez un grand destinataire, votre confirmation de commande n'arrive pas non plus. Vous n'y pouvez rien, et personne ne vous prévient.
Problème 3 : aucune authentification pour votre domaine
C'est le cœur du sujet. Si vous envoyez depuis info@votreentreprise.be via le serveur du fournisseur, le message prétend venir de votre domaine tout en partant d'un serveur qui ne figure pas dans votre enregistrement SPF. Quant à la signature DKIM pour votre domaine, ce serveur n'en pose aucune. Pour Gmail, Outlook et la plupart des serveurs d'entreprise, c'est exactement le profil d'une usurpation. Le message part en indésirables ou est refusé, sans que votre texte y soit pour rien. Le fonctionnement de ces trois enregistrements est expliqué sur notre page SPF, DKIM et DMARC.
Problème 4 : vous ne voyez rien
Un serveur de fournisseur ne vous donne aucun journal. Vous ignorez quels messages ont été acceptés, lesquels ont rebondi et lesquels ont fini en quarantaine chez le destinataire. En cas de réclamation, vous n'avez rien à vérifier. Pour du courrier privé, ce n'est pas gênant ; pour une entreprise qui envoie des factures et des confirmations, ça l'est.
Problème 5 : ça ne marche que depuis votre propre connexion
Beaucoup de fournisseurs n'acceptent leur serveur SMTP que depuis leur propre réseau, ou exigent sinon un identifiant séparé. Si votre boutique déménage chez un hébergeur ou si votre CRM tourne dans le cloud, la connexion tombe. C'est souvent à ce moment-là qu'on découvre que le courrier de l'entreprise dépendait depuis des mois d'une connexion domestique.
Quand un relais est la solution
Dès que ce n'est plus un humain qui envoie. Un relais est un serveur d'envoi que vos applications utilisent avec leur propre identifiant, et qui envoie avec une authentification SPF et DKIM correcte pour votre domaine. Concrètement :
- Pas de limite horaire ou journalière qui bloque votre facturation le premier du mois, mais une tranche de volume adaptée à votre entreprise.
- Un identifiant par application : boutique, comptabilité et CRM reçoivent chacun leur accès, révocable séparément si un prestataire change.
- Un journal par message : accepté, livré, rebondi ou refusé, avec le motif.
- L'authentification mise en place depuis le tableau de bord, pour que votre domaine prouve au destinataire que le message vient bien de vous.
- Une connexion depuis n'importe où, y compris depuis l'hébergement de votre boutique ou une application cloud.
Vos collaborateurs, eux, continuent d'utiliser leur programme de messagerie habituel. Le relais sert au courrier automatique, pas à la correspondance quotidienne.
Ce que vous pouvez vérifier aujourd'hui
Ouvrez les paramètres de votre boutique, de votre logiciel de facturation et de votre CRM et regardez quel serveur sortant y figure. Si c'est celui de votre fournisseur d'accès, vous tenez la cause de vos problèmes de livraison, même si cela semble encore fonctionner. Envoyez ensuite un message de test vers une adresse Gmail et une adresse Outlook et regardez où il atterrit. Votre propre boîte n'est pas un bon test : elle fait déjà confiance à votre domaine.
Questions fréquentes
Je ne peux donc plus du tout utiliser le SMTP de mon fournisseur ?
Pour le courrier d'une connexion familiale, il convient très bien. Pour le courrier automatique d'une entreprise, avec votre propre domaine en expéditeur, non.
Dois-je changer de fournisseur d'accès ?
Non. Votre connexion internet reste la même. Vous changez uniquement le serveur sortant dans les applications qui envoient automatiquement.
Dois-je modifier mes DNS ?
Oui : le relais doit figurer dans votre SPF et signer votre courrier en DKIM. Les deux se préparent depuis le tableau de bord ; c'est un travail unique.