Vultr bloque le port SMTP 25 — Ils nous ont même dit non. Voici comment envoyer des e-mails quand même
Si votre application sur Vultr ne peut pas envoyer d’email, ce n’est pas un bug dans votre code. Vultr bloque le port SMTP sortant 25 par défaut sur les nouveaux comptes — et d’après notre expérience, ils ne supprimeront pas ce blocage même pour un expéditeur bien documenté et transactionnel uniquement.
Nous le savons parce que nous avons demandé. Nous gérons une entreprise d’infrastructure email. Nous avons soumis une demande de suppression du blocage du port SMTP avec pratiquement le meilleur dossier qu’un expéditeur puisse faire valoir, et Vultr a dit non. Deux fois — la deuxième fois après escalade auprès de la direction.
Cet article partage les réponses réelles de Vultr textuellement, explique pourquoi le blocage existe (et pourquoi, honnêtement, c’est la bonne décision pour eux), et montre comment envoyer des emails depuis une instance Vultr malgré tout.
Ce que nous avons demandé
En juillet 2026, nous avons ouvert un ticket intitulé « Suppression du blocage du port SMTP » sur une instance Vultr nouvelle destinée à un nœud de livraison de courrier sortant. La demande était aussi transparente que possible :
- Email transactionnel uniquement — vérifications de compte, réinitialisations de mot de passe, codes 2FA, confirmations de commande, reçus. Pas de marketing, pas d’infolettre, interdits par nos propres conditions de service.
- Authentification complète — chaque message signé DKIM (signature double Ed25519 + RSA), aligné SPF et conforme DMARC, avec suppression automatisée des rebonds définitifs et des plaintes de spam.
- Notre propre espace IP — un bloc /24 dédié que nous possédons, annoncé via BGP depuis notre compte Vultr, de sorte que notre réputation d’envoi serait entièrement la nôtre. Les IPs de Vultr ne transporteraient aucun de nos messages.
- Un plan de préchauffage documenté — commençant à 50–100 messages par jour et augmentant sur plusieurs semaines tout en surveillant l’état des listes de blocage.
La réponse de Vultr, textuellement
Voici la première réponse de l’équipe des comptes de Vultr, mot pour mot :
Bonjour,
Merci de nous avoir fourni les informations demandées. Nous avons examiné en détail votre demande, mais malheureusement, nous ne pouvons pas supprimer le blocage SMTP sur votre compte. D’après les informations que vous avez fournies, il semble que les activités décrites ne sont pas compatibles avec notre plateforme. Il est crucial que nous respections strictement notre politique afin de garantir des performances optimales et de préserver l’intégrité de nos services.
Nous comprenons que ce ne soit pas la nouvelle que vous espériez, et nous nous excusons pour tout inconvénient. Cependant, nous restons déterminés à vous aider à trouver une solution adaptée. Nous vous recommandons d’explorer des solutions logicielles tierces spécialisées dans les services de courrier électronique. Ces plateformes sont conçues pour répondre aux exigences spécifiques et offrent les fonctionnalités et la flexibilité nécessaires pour vos opérations de courrier.
Nous comprenons que ce ne soit peut-être pas le résultat que vous attendiez, et nous apprécions sincèrement votre compréhension et votre coopération. Notre équipe de support dévouée est là pour vous aider de toute manière possible. Si vous avez d’autres questions ou si nous pouvons vous aider autrement, n’hésitez pas à nous contacter.
Cordialement,
Équipe des comptes Vultr
Nous avons répondu et posé une question de clarification : la détermination changerait-elle si nous nous limitions à envoyer uniquement à partir de nos propres adresses IP annoncées via BGP — de sorte que notre bloc IP, et non celui de Vultr, porterait chaque conséquence de notre comportement d’envoi ?
Vultr a pris la question au sérieux et l’a escaladée :
Bonjour Jonathan,
Veuillez nous accorder un peu plus de temps pour examiner votre demande.
En attendant, vous pouvez toujours répondre ici pour ajouter des informations supplémentaires.
Quelques heures plus tard, la réponse finale est arrivée :
Bonjour Jonathan,
Merci de votre patience lors de cette escalade auprès de la direction.
Malheureusement, en raison de votre utilisation prévue, nous ne pouvons pas débloquer SMTP pour vous.
Nous vous recommandons d’explorer des solutions logicielles tierces spécialisées dans les services de courrier électronique, conçues pour répondre aux exigences spécifiques de vos opérations de courrier. Merci de votre compréhension dans cette affaire.
C’est un non ferme et définitif — pour un expéditeur avec authentification complète, espace IP propre, plan de préchauffage et politique transactionnelle uniquement. Si votre demande est « Je voudrais envoyer des emails depuis mon VPS », attendez-vous à la même réponse ou à une version plus discrète.
Pourquoi Vultr bloque le port 25 en premier lieu
Il serait facile de lire ces emails comme malhelpful. Ils ne le sont pas. Ils sont rationnels, et comprendre pourquoi vous en dit beaucoup sur le fonctionnement réel du courrier en 2026.
Le port 25 est le port que les serveurs de courrier utilisent pour communiquer entre eux. C’est aussi le port dont les spammeurs ont besoin. Un fournisseur de cloud qui le laisse ouvert devient un canon à spam en quelques jours : quiconque possède une carte de crédit volée peut déployer cent instances, envoyer du spam jusqu’à ce que les IPs brûlent, et disparaître. Le fournisseur est laissé avec les dégâts — et les dégâts sont collectifs. Les listes de blocage comme Spamhaus ne listent pas seulement une seule mauvaise IP ; elles listent des plages. Un seul client abusif peut obtenir qu’un entier /24 de l’espace d’adresses d’un fournisseur soit bloqué, ce qui signifie que tous les autres courriers légitime du client commencent à rebondir.
Donc chaque grand cloud fait une version de ce que Vultr fait. AWS bloque le port 25 par défaut. Google Cloud, Azure, DigitalOcean et Hetzner aussi. La vérité blunt dans la réponse de Vultr — « les activités décrites ne sont pas compatibles avec notre plateforme » — est un cloud généraliste qui reconnaît correctement que la livraison de courrier n’est pas son métier, et que même un bon expéditeur sur son réseau est une responsabilité qu’il n’est pas équipé pour superviser. Vultr ne peut pas à bas coût faire la distinction entre un expéditeur transactionnel discipliné et un spammeur avec un ticket bien rédigé, donc la politique prudente est de refuser tout le monde et, selon leurs propres termes, de recommander « des solutions logicielles tierces spécialisées dans les services de courrier ».
Ils ont raison. Nous en sommes une.
Pourquoi la délivrabilité est devenue un métier de spécialiste
Voici le paradoxe élégant au cœur de cette histoire : la chose qui rend la livraison de courrier difficile est la même chose qui rend nécessaire de s’y spécialiser.
Livrer du courrier de manière fiable a cessé d’être un problème de réseau il y a des années — c’est un problème de réputation. Les fournisseurs de boîte de réception jugent chaque message par rapport à l’historique de l’IP qui l’a envoyé et du domaine qui l’a signé : taux de plainte, taux de rebond, engagement, authentification, cohérence du volume. Cette réputation s’acquiert lentement (les nouvelles IPs doivent être préchauffées sur des semaines), s’épuise rapidement (un seul mauvais lot peut défaire des mois), et se maintient continuellement (boucles de rétroaction, listes de suppression, surveillance des listes de blocage et particularités par fournisseur chez Gmail, Microsoft et Yahoo exigent tous une attention quotidienne).
Aucun cloud généraliste ne veut y souscrire en votre nom — comme l’équipe des comptes de Vultr vient de le démontrer. Un fournisseur spécialisé, en revanche, fonde l’intégralité de son entreprise dessus. Notre infrastructure, notre espace IP, notre surveillance et notre application de l’anti-abus existent tous pour protéger un actif : la réputation d’envoi sur laquelle le courrier de nos clients chemine. Cet alignement est l’ensemble du produit. C’est difficile à livrer — ce qui est précisément pourquoi cela vaut la peine de payer un spécialiste pour le livrer.
Comment envoyer des emails depuis Vultr (le moyen qui fonctionne)
Voici la bonne nouvelle : Vultr bloque seulement le port 25 — le port serveur-à-serveur. Le port 587, le port de soumission standard que votre application utilise pour remettre du courrier à un service de courrier, est grand ouvert. Ce qui signifie que Mailer To Go fonctionne parfaitement à partir de toute instance Vultr, sans tickets, sans attendre, et sans préchauffage.
Inscrivez-vous sur mailertogo.com, vérifiez votre domaine d’envoi, et pointez votre application vers vos identifiants SMTP :
# Rails — config/environments/production.rb
config.action_mailer.smtp_settings = {
address: ENV["MAILERTOGO_SMTP_HOST"],
port: 587,
user_name: ENV["MAILERTOGO_SMTP_USER"],
password: ENV["MAILERTOGO_SMTP_PASSWORD"],
authentication: :plain,
enable_starttls_auto: true
}
// Node.js — avec Nodemailer
const transporter = nodemailer.createTransport({
host: process.env.MAILERTOGO_SMTP_HOST,
port: 587,
auth: {
user: process.env.MAILERTOGO_SMTP_USER,
pass: process.env.MAILERTOGO_SMTP_PASSWORD,
},
});
La signature DKIM, l’alignement SPF, DMARC, la gestion des rebonds et des plaintes, les listes de suppression et la réputation IP sont tous gérés de notre côté — les éléments que Vultr a correctement décidé de ne pas être en affaires de superviser.
Votre instance Vultr continue à faire ce pour quoi Vultr est vraiment excellent : exécuter votre application. Votre courrier chemine sur une infrastructure qui existe pour un seul but — le faire livrer.