Principaux FAI Bloquant le Port 25 : Ce que les Utilisateurs d'E-mail Doivent Savoir en 2026

Comprendre le port 25 et son rôle traditionnel dans le courrier électronique

Pour comprendre pourquoi le blocage du port 25 est important, il est essentiel de saisir comment l'infrastructure de messagerie fonctionnait traditionnellement. Le courrier électronique sur Internet repose principalement sur le protocole SMTP (Simple Mail Transfer Protocol), un protocole textuel qui a permis l'échange de messages entre serveurs de messagerie depuis le début des années 1980. Le port 25 a servi de port « SMTP » standard enregistré auprès de l’Internet Assigned Numbers Authority (IANA) pour le transport des messages entre serveurs.

Dans l’architecture classique du courrier électronique, lorsque Gmail délivre un message à Outlook.com ou à tout autre fournisseur, cette connexion s’établit presque toujours via le port 25, les enregistrements DNS MX déterminant le serveur à contacter. Ce rôle de transport entre serveurs reste fondamental pour la livraison des emails encore aujourd’hui, selon l’analyse technique de SMTP.com.

L’évolution : ports de soumission vs ports de relais

Avec la montée des abus par email, la communauté internet a introduit une séparation importante entre la soumission des messages par les utilisateurs finaux et le relais des messages entre serveurs de messagerie. la RFC 6409 a formellement réservé le port 587 comme port de « soumission de message », précisant que les agents utilisateurs et agents de soumission de courrier doivent utiliser le port 587 avec authentification et application des politiques adaptées, tandis que le port 25 reste dédié au relais serveur à serveur.

Les recommandations modernes des fournisseurs d’infrastructures mail reflètent clairement cette séparation. Mailgun qualifie le port 25 de port relais par défaut pour les serveurs, tout en recommandant le port 587 pour la soumission client. De même, Twilio (SendGrid) décrit le port 25 comme adapté uniquement au trafic serveur à serveur et conseille aux applications clientes d’utiliser le port 587 ou, si nécessaire, le 465.

Cette distinction architecturale est cruciale : le port 25 gère la livraison « en coulisses » entre serveurs de messagerie, tandis que les ports 587, 465 et 2525 assurent la soumission authentifiée depuis les clients et applications de messagerie. Comprendre cette différence est essentiel pour naviguer les restrictions modernes des emails.

Couches de sécurité : TLS, STARTTLS et chiffrement

Initialement, SMTP transmettait les messages en clair, rendant les emails vulnérables à l’interception et à la falsification. L’industrie a progressivement adopté le chiffrement SSL et TLS selon deux principales méthodes : TLS implicite (où les connexions démarrent chiffrées, comme avec le classique « smtps » sur le port 465) et TLS explicite via la commande STARTTLS sur les ports 25 ou 587.

Selon la RFC 3207, qui a défini l’extension SMTP pour un SMTP sécurisé sur TLS, clients et serveurs négocient le chiffrement via STARTTLS après avoir établi une connexion non chiffrée. En pratique, les connexions au port 25 entre serveurs de messagerie utilisent souvent le STARTTLS « opportuniste » — chiffrant lorsque c’est possible mais revenant au texte clair si le pair ne supporte pas TLS — tandis que les ports de soumission requièrent généralement STARTTLS ou TLS implicite ainsi qu’une authentification.

Pourquoi les principaux FAI et fournisseurs cloud bloquent-ils le port 25

La frustration de découvrir le blocage du port 25 est accentuée par la question : Pourquoi les FAI limiteraient-ils délibérément une fonction fondamentale de la messagerie ? La réponse réside dans l'ampleur massive du spam et des abus de logiciels malveillants qui ont ravagé les infrastructures de messagerie pendant des décennies.

Restrictions des FAI résidentiels : le problème du spam et des logiciels malveillants

Les fournisseurs d'accès à Internet pour les particuliers bloquent de plus en plus le port 25 pour lutter contre le spam et les malwares provenant de dispositifs clients compromis. Xfinity de Comcast explique dans sa documentation de support que le port 25 n'est plus supporté pour la soumission des emails, soulignant que beaucoup de l'utilisation actuelle du port 25 provient d'ordinateurs infectés par des malwares envoyant du spam à l'insu de l'utilisateur.

La raison de sécurité est convaincante : En bloquant le port 25, les FAI empêchent les machines compromises de participer à des campagnes de spam, réduisant ainsi le volume global des emails indésirables et protégeant leur réputation IP contre les listes noires étendues. L'analyse de Varidata souligne que les spammeurs ciblent souvent le port 25 pour envoyer des messages en masse depuis des machines infectées, faisant du blocage du port 25 une nécessité défensive.

Les forums communautaires de Verizon décrivent le port 25 comme « non sécurisé » et « terriblement non sécurisé », avec des contributeurs notant que Verizon bloque le port 25 sur les comptes résidentiels et ne prévoit pas de le débloquer, conseillant aux utilisateurs de basculer sur le port 587 ou 465 avec TLS pour SMTP. Les pratiques publiées par AT&T pour son réseau haut débit listent le port 25 parmi plusieurs ports que la société peut bloquer pour prévenir le trafic malveillant ou perturbateur, aux côtés du partage de fichiers Windows et d'autres services à haut risque.

Restrictions des plates-formes cloud : Azure et fournisseurs VPS

Les restrictions du port 25 vont bien au-delà du haut débit résidentiel. Les principales plates-formes cloud ont renforcé leurs politiques SMTP sortantes pour protéger leur réputation IP et réduire les abus. La documentation officielle de Microsoft Azure indique que la plate-forme Azure bloque les connexions SMTP sortantes sur le port TCP 25 pour la plupart des machines virtuelles déployées, en particulier pour les types d'abonnement tels que Pay-As-You-Go, les essais gratuits et beaucoup d'autres — et que les demandes de suppression de cette restriction pour ces abonnements ne sont pas accordées.

Azure autorise principalement des exceptions pour les abonnements de niveau entreprise. Pour les abonnements Enterprise Agreement (EA) et certains accords clients Microsoft pour entreprises (MCA-E), le port 25 sortant n'est pas bloqué par défaut, bien qu'Azure avertisse que les domaines externes peuvent toujours rejeter ou filtrer les courriels provenant de ces IP en fonction de leurs propres politiques et évaluations de réputation.

Les fournisseurs d'hébergement mutualisé adoptent des postures similaires. La base de connaissances de DreamHost explique qu'il bloque le port 25 pour le SMTP sortant sur les serveurs mutualisés, mais pas sur les VPS ou serveurs dédiés, avertissant que de nombreux FAI bloquent également le port 25 comme technique anti-spam.

Bonnes pratiques industrielles : les recommandations du M3AAWG

Le Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) offre une perspective des meilleures pratiques industrielles, recommandant que les fournisseurs d'accès Internet et de services de messagerie bloquent l'accès au port 25 depuis tous les hôtes sur leurs réseaux, sauf ceux explicitement autorisés à opérer comme relais SMTP. M3AAWG recommande également de fournir des services de soumission sur les ports 465 et 587, d'exiger une authentification pour la soumission d'emails, et de permettre aux clients de se connecter aux serveurs de soumission sur ces ports tant au sein de leur propre réseau que sur d'autres réseaux.

Ces directives visent à canaliser tous les emails émis par les utilisateurs via des canaux de soumission authentifiés, où les fournisseurs peuvent appliquer des limites de débit, un filtrage de contenu, et une gestion de la réputation, tout en réservant le port 25 pour le trafic serveur à serveur contrôlé, ce qui contribue à atténuer le blocage du port 25 pour les e-mails.

La barre qui monte : exigences d'authentification des e-mails en 2026

Le blocage du port 25 ne se produit pas isolément — il fait partie d'une transformation plus large des normes de sécurité et de délivrabilité des e-mails. Même lorsque le port 25 est techniquement disponible, la livraison moderne des e-mails requiert désormais des mécanismes d'authentification sophistiqués qui étaient optionnels il y a seulement quelques années.

SPF, DKIM et DMARC : de l’optionnel au obligatoire

Les normes d'authentification des e-mails — Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) et Domain-based Message Authentication, Reporting and Conformance (DMARC) — ont été introduites pour vérifier que les messages proviennent d'expéditeurs autorisés et n'ont pas été altérés. La présentation de Cloudflare explique que DMARC exige une correspondance entre le domaine visible dans le champ "From" et les domaines utilisés dans SPF et/ou DKIM, et que la configuration correcte de SPF, DKIM et DMARC ensemble réduit considérablement les risques d'usurpation et de phishing.

Le calendrier d'application s'est considérablement accéléré : l'analyse de Proofpoint détaille comment, dès février 2024, Google et Yahoo ont introduit des exigences obligatoires d'authentification des e-mails pour les expéditeurs en masse, incluant SPF et DKIM sur tous les courriers sortants, un enregistrement DMARC publié avec au moins p=none, une correspondance entre le domaine From et les domaines SPF/DKIM, une désinscription en un clic pour les messages promotionnels, ainsi que des taux de plainte pour spam faibles.

En novembre 2025, Google a commencé à rejeter strictement les messages non conformes au niveau SMTP, tandis que Outlook.com et Microsoft 365 de Microsoft ont également exigé SPF, DKIM et DMARC pour les expéditeurs à volume élevé à partir de mai 2025.

Pressions réglementaires : PCI DSS, NIS2 et obligations de conformité

L'analyse de DuoCircle pour 2026 affirme que l'authentification des e-mails est devenue une exigence obligatoire pour les organisations qui envoient d'importants volumes d'e-mails ou manipulent des données sensibles, DMARC étant même intégré dans des normes comme PCI DSS v4.0 en tant qu'obligation de conformité. Les cadres européens de cybersécurité tels que NIS2 et DORA reconnaissent l'authentification des e-mails comme un contrôle requis.

Pour les opérateurs d'e-mails auto-hébergés, cela signifie que sécuriser l'ouverture du port 25 ne constitue que le début. Sans une configuration appropriée de SPF, DKIM et DMARC — ainsi qu'une réputation IP propre, un DNS inversé correct et des pratiques d'envoi cohérentes — les messages risquent d'être mis en quarantaine ou rejetés indépendamment de la disponibilité du port, rendant encore plus cruciale la gestion dans le contexte du blocage du port 25 pour les e-mails.

Vérification de la réalité : Comment le blocage du port 25 affecte les e-mails auto-hébergés

Pour les particuliers et les petites entreprises qui tentent de gérer leurs propres serveurs de messagerie, le blocage du port 25 représente un obstacle fondamental qui transforme ce qui était autrefois simple en un défi architectural complexe.

Auto-hébergement résidentiel : impossibilité pratique

La communauté Mail-in-a-Box, qui vise à simplifier l’auto-hébergement des e-mails, affirme clairement que les ordinateurs sur la plupart des réseaux résidentiels sont bloqués par leur FAI pour l’envoi de mails via le port 25, et que même si l’envoi était possible, les serveurs destinataires mettent souvent sur liste noire les plages d’adresses IP résidentielles car ces ordinateurs sont fréquemment détournés pour envoyer du spam.

Le rêve de l’auto-hébergement résidentiel est effectivement terminé pour la plupart des utilisateurs. Les responsables de Mail-in-a-Box et les utilisateurs expérimentés déconseillent généralement d’essayer d’héberger des e-mails directement depuis une connexion Internet résidentielle, recommandant plutôt l’utilisation de fournisseurs VPS hébergés qui autorisent le SMTP ou des services d’hébergement mail externes.

Un exemple concret vient de Bryan Chan, qui décrit la mise en place d’un serveur mail auto-hébergé sur un NAS à domicile mais ayant rencontré le problème que son FAI résidentiel bloque le port 25 sortant, empêchant son serveur de livrer les mails directement sur Internet. Pour résoudre cela, il a acheté un VPS peu coûteux chez un fournisseur d’hébergement, configuré Postfix comme relais SMTP (smarthost), et a redirigé le courrier sortant de son serveur domestique via ce VPS, qui a alors délivré les messages en port 25 depuis une IP de centre de données.

Hébergement VPS et cloud : politiques mixtes et restrictions cachées

Pour les utilisateurs qui auto-hébergent leurs e-mails sur des VPS ou serveurs dédiés, la situation est un peu plus favorable mais toujours limitée. De nombreux fournisseurs VPS autorisent le port 25 sortant depuis des IP de centre de données, parfois seulement après validation manuelle ou pour des clients payants avec identité vérifiée, tandis que d’autres le bloquent complètement.

Le guide étape par étape de DuoCircle souligne l’importance de choisir un fournisseur qui autorise explicitement le SMTP sortant sur le port 25, et recommande de vérifier cela via la documentation ou le support avant de s’engager. La liste "awesome-mail-server-providers" sur GitHub, établie par le projet Forward Email, met en avant des hébergeurs comme Linode et DartNode comme options économiques offrant un port 25 ouvert dès l’installation, bien que beaucoup d’autres hôtes ne le fassent pas.

L’impact caché sur les applications web

Le blocage du port 25 se manifeste de manière inattendue pour les applications web qui dépendent de l’envoi local de mails. De nombreux systèmes de gestion de contenu, forums et applications web — tels que WordPress, Discourse et des applications personnalisées — partent du principe qu’ils peuvent envoyer des mails soit par un agent de transfert local relayant directement via le port 25, soit par des connexions SMTP directes aux hôtes MX distants sur le port 25.

Lorsque le réseau sous-jacent bloque le port 25 sortant, ces messages échouent silencieusement ou génèrent des erreurs de temporisation de connexion, empêchant les réinitialisations de mot de passe, les notifications et d’autres flux transactionnels. Les administrateurs découvrent que la messagerie WordPress échoue dans les environnements où le port 25 est bloqué, car WordPress ou la fonction PHP mail() essaie généralement d’utiliser le port 25 par défaut pour le SMTP sortant.

Ces problèmes sont particulièrement critiques pour les petites entreprises qui hébergent leurs propres serveurs web sur des VPS génériques sans se rendre compte que le port 25 sortant est bloqué. Elles peuvent constater que les formulaires de contact et les confirmations de commande n’atteignent jamais les clients, nuisant à l’expérience utilisateur et au chiffre d’affaires.

Solutions Pratiques : Comment Envoyer des Emails Lorsque le Port 25 est Bloqué

Bien que le blocage du port 25 crée des défis importants, l'industrie de l'email a développé plusieurs solutions pratiques qui permettent aux utilisateurs de maintenir la fonctionnalité des emails même dans des environnements restreints.

Solution 1 : Relais SMTP Authentifié (Smarthost)

La solution la plus recommandée est l'utilisation d'un relais SMTP authentifié, parfois appelé "smarthost". Dans cette architecture, une application ou un serveur de messagerie auto-hébergé envoie les messages sortants à un fournisseur relais sur le port 587, 465 ou 2525 en utilisant l'authentification SMTP et TLS. Le relais, opérant depuis un espace IP bien géré et à forte réputation, délivre ensuite les messages aux domaines destinataires via le port 25.

Les recommandations d'Azure préconisent explicitement cette approche, indiquant que pour la plupart des types d’abonnement où le port 25 sortant est bloqué, les clients doivent utiliser des services de relais SMTP authentifiés fonctionnant sur le port TCP 587, et précisant que les connexions vers ces services ne sont pas restreintes quel que soit le type d’abonnement.

Le marché des services de relais SMTP et d’API email est mature et compétitif. Des fournisseurs tels que SendGrid, Amazon SES, Brevo, SMTP2Go, SendPulse, MailerSend, Mailjet et Maileroo offrent des paliers gratuits généreux adaptés aux utilisateurs à faible volume, avec un support de soumission sur les ports 587 et 465, certains proposant également le port 2525 en alternative.

Solution 2 : Services de Stockage et Renvoi de Courriels Entrants

Lorsque le port 25 entrant est bloqué—soit par le fournisseur d’accès Internet, soit par absence de contrôle sur le réseau de périmètre—les utilisateurs peuvent employer des services de stockage et renvoi pour recevoir les emails. Le service Email Store/Forward de Dynu est un exemple notable : il permet aux propriétaires de domaine de pointer leurs enregistrements MX vers les serveurs de Dynu, qui reçoivent les emails via le port 25 depuis Internet, les stockent, puis les renvoient vers le serveur de messagerie de l’utilisateur sur un port personnalisé configuré par l’utilisateur, comme le 26 ou le 2525.

Cette approche permet aux clients dont les FAI bloquent le port 25 de faire fonctionner des serveurs email sur des ports alternatifs tout en participant à l’échange mondial d’emails. Cependant, les services de stockage et renvoi ne traitent que le transport entrant ; pour les emails sortants, les utilisateurs ont toujours besoin soit d’un smarthost soit d’une infrastructure distincte avec un port 25 ouvert.

Solution 3 : Choisir des Fournisseurs d’Hébergement Compatibles avec les Emails

Une autre alternative au blocage du port 25 consiste à choisir des fournisseurs de connectivité qui n’imposent pas ces restrictions, ou qui les lèvent sur demande. Le blog de NoIP conseille aux utilisateurs de contacter explicitement leur fournisseur d’accès pour savoir si le port 25 entrant ou sortant est bloqué, soulignant que certains FAI peuvent débloquer le port 25 sur demande pour certains types de comptes.

Pour des résultats plus prévisibles, les auto-hébergeurs se tournent souvent vers des fournisseurs VPS ou serveurs dédiés qui supportent explicitement le SMTP. La liste "awesome mail-server-providers" de Forward Email mentionne des hébergeurs comme Linode et DartNode comme options économiques où le port 25 est ouvert par défaut et disposant d’une documentation adaptée aux cas d’usage de serveurs mail.

Comment les utilisateurs de Mailbird gèrent les restrictions du port 25

Comprendre comment le blocage du port 25 affecte les clients de messagerie de bureau nécessite de clarifier la place des clients de messagerie dans l'infrastructure globale des e-mails. C’est là que de nombreux utilisateurs se retrouvent confus—et où l’architecture de Mailbird offre des avantages considérables.

La position de Mailbird dans la pile de messagerie

Mailbird est un client de messagerie de bureau pour Windows et macOS, conçu pour réunir plusieurs comptes e-mail — notamment Gmail, Outlook, Exchange et comptes IMAP — dans un espace de travail unifié. Il se connecte aux serveurs de messagerie en utilisant des protocoles standard tels que IMAP et POP pour le courrier entrant et SMTP pour le courrier sortant, avec prise en charge des méthodes d'authentification modernes comme OAuth 2.0 pour des services tels que Microsoft 365.

Il est crucial de noter que Mailbird ne gère pas sa propre infrastructure de transport d’e-mails. Il agit plutôt comme une interface frontale qui se synchronise avec les serveurs de messagerie que l’utilisateur configure, qu’il s’agisse de gros fournisseurs, de serveurs d’entreprise ou d’instances auto-hébergées. En termes de connectivité, Mailbird attend des utilisateurs qu’ils fournissent les paramètres des serveurs entrants et sortants : noms d’hôtes, ports, types de chiffrement (SSL/TLS ou STARTTLS), noms d’utilisateur et méthodes d’authentification.

Pourquoi le blocage du port 25 affecte rarement les utilisateurs de Mailbird

Pour les utilisateurs typiques de Mailbird utilisant une connexion résidentielle, leurs comptes e-mail sont hébergés par des fournisseurs tels que Gmail, Outlook.com, Yahoo, iCloud ou des serveurs d’entreprise accessibles sur Internet. Ces fournisseurs exposent des ports de soumission (généralement 587 avec STARTTLS ou 465 avec TLS implicite) pour permettre aux clients des utilisateurs d’envoyer des e-mails, tandis que leur propre infrastructure se charge de la livraison aux serveurs MX des destinataires via le port 25.

Comcast/Xfinity, Verizon, AT&T et d’autres FAI qui bloquent le port 25 sortant le font généralement pour les connexions arbitraires depuis les terminaux client vers Internet, pas pour les connexions de ces terminaux aux ports 587 ou 465 des fournisseurs de messagerie reconnus. Ainsi, lorsque Mailbird se connecte à smtp.gmail.com:587 ou smtp.mail.me.com:587, ces flux ne sont pas affectés par les restrictions liées au port 25 car ils utilisent des ports différents explicitement autorisés par les FAI.

En effet, la documentation des FAI recommande souvent explicitement de configurer les clients de messagerie pour le port 587 ou 465. Le guide de configuration de Mailbird pour les comptes iCloud, par exemple, montre la connexion aux serveurs IMAP sur le port 993 avec SSL et SMTP sur le port 587 avec TLS — exactement la configuration qui contourne les restrictions du port 25.

Utilisateurs de serveurs auto-hébergés : compréhension de la répartition des responsabilités

La situation devient plus nuancée lorsque Mailbird se connecte à des serveurs de messagerie auto-hébergés. Dans ces cas, Mailbird se connecte généralement au serveur auto-hébergé via IMAP sur le port 993 et par soumission SMTP via des ports tels que 587 ou 465, comme avec un fournisseur commercial.

Pour la connexion client-serveur, la question pertinente est de savoir si le FAI de l’utilisateur autorise les connexions sortantes vers ces ports de soumission sur l'adresse IP du serveur — les FAI résidentiels ne bloquent généralement pas les ports 587/465, et les fournisseurs de VPS bloquent rarement les ports entrants 587/465, de sorte que la connectivité Mailbird est habituellement libre à ce niveau.

Cependant, une fois que Mailbird soumet un message au serveur auto-hébergé, c’est ce dernier qui doit ensuite le livrer aux hôtes MX des destinataires, ce qui se fait presque toujours via le port 25. Si le serveur auto-hébergé se trouve sur un réseau où le port 25 sortant est bloqué — comme un FAI résidentiel, un hébergeur VPS restrictif, ou un abonnement Azure sans exemption pour le port 25 — Mailbird indiquera que le message a été envoyé avec succès au serveur, mais les tentatives de livraison du serveur échoueront avec des délais d’attente ou des connexions refusées.

Du point de vue de l’utilisateur dans Mailbird, cela peut être déroutant : le client ne signale pas d’erreur, mais les destinataires ne reçoivent jamais le mail, et seule une inspection attentive des journaux serveur ou de la file d’attente révèle le blocage sous-jacent lié au port 25.

Conseils pratiques pour les utilisateurs de Mailbird

Pour les utilisateurs de Mailbird qui utilisent des fournisseurs majeurs hébergés (Gmail, Outlook, iCloud, etc.), le principal conseil pratique est de s’assurer que leurs comptes sont configurés avec les bons paramètres IMAP et SMTP, en utilisant les ports de soumission spécifiés par les fournisseurs et le TLS. Le guide de configuration de Mailbird recommande aux utilisateurs de s’appuyer sur la connexion OAuth lorsque disponible et d’accepter les paramètres détectés automatiquement lorsqu’ils correspondent à la documentation du fournisseur.

Pour les utilisateurs exploitant des serveurs auto-hébergés, Mailbird doit être configuré pour utiliser les ports de soumission (587 ou 465) avec authentification et TLS lors de l’envoi des mails, et IMAP sur des ports sécurisés (généralement 993) pour la réception. Le serveur auto-hébergé doit, à son tour, être validé pour la connectivité sortante sur le port 25 à l’aide d’outils comme telnet ou Test-NetConnection ; s’il est bloqué, il doit être configuré pour relayer via un service SMTP authentifié sur les ports de soumission.

Mailbird lui-même n’a pas besoin d’être modifié pour s’adapter à ces solutions côté serveur — seuls les paramètres SMTP du serveur doivent l’être. Cette séparation des responsabilités est l’un des points forts de Mailbird : il offre une interface cohérente et fiable, quelle que soit la complexité de l’infrastructure sous-jacente, notamment en matière de blocage du port 25 pour les e-mails.

Pourquoi un client dédié reste important en 2026

On pourrait se demander si la centralisation croissante de l’infrastructure e-mail diminue la pertinence des clients de bureau. Cependant, des analyses indépendantes soutiennent que les clients e-mail dédiés conservent leur valeur en tant qu’espaces de travail unifiés, en particulier pour les utilisateurs gérant plusieurs comptes chez différents fournisseurs et pour ceux soucieux de l’endroit où leurs données sont synchronisées.

Les caractéristiques de performance de Mailbird séduisent également les utilisateurs avancés. Des tests indépendants suggèrent que Mailbird synchronise rapidement les messages à travers plusieurs comptes IMAP tout en maintenant une consommation de ressources relativement basse par rapport à certains clients concurrents. Dans des environnements où les serveurs sont distants (VPS, cloud) et où le port 25 est restreint à une infrastructure spécifique bien gérée, un client rapide et efficace capable de gérer de nombreux comptes via des ports de soumission sécurisés reste précieux.

Pour les utilisateurs auto-hébergeurs, Mailbird offre une interface familière et riche en fonctionnalités pour une architecture serveur complexe façonnée par les politiques de blocage du port 25 et les exigences de délivrabilité. Avec les offres premium de Mailbird prenant en charge un nombre illimité de comptes et proposant des intégrations avec des applications productives, il reste attractif pour les utilisateurs ayant des configurations e-mail complexes, y compris celles impliquant des serveurs auto-hébergés.

Questions Fréquemment Posées