Port 25 bloqué : comment envoyer des e-mails sans astuces douteuses

janvier 18, 2026 • février 3, 2026 • Lecture : 26 min • Views: 5

Cet article vous a aidé ?

Vous provisionnez une nouvelle VM. Vous déployez votre application. Vous déclenchez un e-mail de réinitialisation de mot de passe. Rien n’arrive.
Vos journaux montrent des tentatives, des timeouts, et une petite vérité : le TCP sortant sur le port 25 est bloqué.

Si vous pensez « je vais juste ouvrir le port 25 », bienvenue dans l’internet moderne où les abus ont gâché la fête.
La bonne nouvelle : vous pouvez toujours envoyer des mails de manière fiable — sans tunnel sinistre, et sans devenir votre propre service délivrabilité.

Ce qu’est le port 25 (et pourquoi il est bloqué)

Le port 25 est le port SMTP classique utilisé principalement pour la livraison d’e-mails serveur-à-serveur :
votre agent de transfert de mail (MTA) parle au serveur MX du domaine destinataire et transfère le message.
Ce modèle « direct-to-MX » existe toujours, mais ce n’est plus la manière recommandée d’envoyer des e-mails depuis des ressources de calcul aléatoires en 2026.

Les fournisseurs cloud et beaucoup de FAI bloquent par défaut le 25 sortant pour une raison : le spam.
Les nouvelles plages d’IP sont rapidement abusées. Bloquer le port 25 réduit les abus, protège la réputation du fournisseur et évite que leur espace IP n’apparaisse sur des listes noires.
Vous n’êtes pas ciblé personnellement ; vous habitez un quartier où quelqu’un met régulièrement le feu aux canapés.

Le modèle moderne est : votre serveur envoie le mail via un point de soumission authentifié (généralement le port 587 avec STARTTLS, ou le port 465 avec TLS implicite),
ou via une API d’envoi d’e-mails. Le service relais gère ensuite la délivrabilité : réputation IP, limitation de débit, boucles de rétroaction, signature DKIM, etc.

Une citation à coller au-dessus de votre écran (idée paraphrasée) : Gene Kranz : « Soyez résilient et compétent. » Le travail de fiabilité, c’est surtout de la compétence sous pression.

Playbook de diagnostic rapide

Quand l’e-mail échoue, tout le monde se dispute immédiatement SPF vs DKIM vs « le fournisseur est en panne ».
Stop. Diagnosez comme un SRE : réduisez d’abord le périmètre, puis localisez le goulot d’étranglement.

Première étape : confirmez qu’il s’agit bien d’un blocage réseau (pas d’un bug applicatif)

Depuis l’hôte qui envoie le mail, testez la connectivité TCP vers un serveur SMTP connu sur 25, 587 et 465.
Vérifiez si votre application tente du direct-to-MX ou utilise déjà un relais.
Cherchez « connection timed out » (blocage réseau) vs « authentication failed » (identifiants) vs « rejected » (politique / délivrabilité).

Deuxième étape : identifiez qui bloque

Le fournisseur cloud bloque-t-il le 25 sortant au niveau de l’hyperviseur ?
Votre VPC/NACL/groupe de sécurité restreint-il l’egress ?
Un pare-feu local (ufw/iptables/nftables) empêche-t-il la sortie ?

Troisième étape : choisissez l’alternative propre

Si vous avez besoin d’e-mails transactionnels : utilisez la soumission SMTP authentifiée sur 587/465 vers un relais réputé.
Si vous avez besoin de volume élevé ou d’une forte télémétrie : utilisez une API e-mail (souvent soutenue par SMTP en interne).
Si ce sont des notifications internes uniquement : routez vers un relais interne ou un outil de collaboration, pas vers l’Internet public.

Quatrième étape : vérifiez la délivrabilité, pas seulement la connexion

Vérifiez que votre domaine d’expéditeur est authentifié (SPF/DKIM/DMARC) et aligné avec l’expéditeur.
Confirmez la gestion des rebonds. Les échecs silencieux sont les plus coûteux.

Blague n°1 : Le port 25, c’est comme le micro-ondes du bureau — si vous le laissez sans surveillance, quelqu’un y mettra du poisson et tout le monde en pâtira.

Que faire à la place du port 25

Option A (recommandée pour la plupart) : relais SMTP authentifié sur le port 587 (STARTTLS)

C’est la configuration « ennuyeuse et correcte ». Votre hôte envoie le mail à un relais en utilisant des identifiants.
Le relais parle SMTP au reste du monde, gère la réputation et s’occupe des aspects ingrats.

Utilisez le port 587 avec STARTTLS sauf si le fournisseur recommande explicitement le port 465. Le port 587 est le port de soumission standard,
et il s’intègre bien aux politiques de sécurité modernes.

Option B : relais SMTP sur le port 465 (TLS implicite)

Le port 465 est largement supporté et, en pratique, fonctionne bien. C’est du « SMTPS » où TLS est établi immédiatement.
Si vous êtes dans un environnement verrouillé qui bloque ou casse STARTTLS, le 465 peut être plus simple.

Option C : API e-mail du fournisseur (HTTP)

Si votre environnement bloque totalement le SMTP sortant, ou si vous voulez une instrumentation et une idempotence plus propres,
une API HTTPS est souvent plus facile. Elle évite aussi les messages d’erreur souvent ambigus de SMTP.

L’inconvénient : vous couplez la logique applicative à l’API d’un fournisseur. C’est acceptable si vous la traitez comme toute autre dépendance externe :
timeouts, retries avec backoff, coupe-circuit et files d’attente.

Option D : relais interne + passerelle de sortie

En environnement d’entreprise, la bonne réponse est souvent « n’envoyez pas d’e-mails depuis les serveurs d’application ».
Envoyez à un relais interne (même sur le port 25 à l’intérieur du réseau), et laissez une passerelle durcie gérer la livraison externe.

Option E : demander le déblocage du port 25 (rarement le meilleur premier choix)

Certains fournisseurs cloud débloquent le 25 sortant après preuve que vous n’êtes pas une source de spam.
Cela peut être justifié pour des systèmes hérités ou pour exploiter un vrai MTA. Ce n’est pas une solution miracle pour la délivrabilité.
La réputation d’une nouvelle IP est implacable, et « on a ouvert le port 25 » n’est pas une stratégie mail.

Tâches pratiques et commandes (avec décisions)

Voici des tâches opérationnelles à exécuter aujourd’hui. Chaque tâche inclut : commande, ce que signifie la sortie, et la décision à prendre.
Ces exemples ciblent des hôtes Linux exécutant Postfix, mais les diagnostics s’appliquent plus largement.

Task 1: Prove TCP/25 is blocked (timeout vs refuse matters)

cr0x@server:~$ nc -vz -w 3 gmail-smtp-in.l.google.com 25
nc: connect to gmail-smtp-in.l.google.com port 25 (tcp) timed out: Operation now in progress

Signification : Un timeout indique généralement une politique réseau (bordure du fournisseur, pare-feu, ou filtrage d’egress).
Un « refused » signifierait que vous avez atteint l’hôte mais que le port est fermé (rare pour un MX public).

Décision : Ne perdez pas de temps à bricoler Postfix. Passez à un relais sur 587/465 ou corrigez la politique d’egress.

Task 2: Check if 587 works (your escape hatch)

cr0x@server:~$ nc -vz -w 3 smtp.relay.example 587
Connection to smtp.relay.example 587 port [tcp/submission] succeeded!

Signification : Le chemin réseau vers le port de soumission existe.

Décision : Configurez votre MTA/app pour s’authentifier auprès de ce relais sur 587 avec TLS.

Task 3: Validate STARTTLS negotiation (don’t assume encryption)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect smtp.relay.example:587 -servername smtp.relay.example < /dev/null
CONNECTED(00000003)
---
250-STARTTLS
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

Signification : Le serveur annonce STARTTLS et vous avez négocié un TLS moderne.

Décision : Si STARTTLS manque ou si TLS échoue, basculez sur le port 465 ou corrigez les problèmes d’interception/proxy TLS.

Task 4: Check if your application is trying direct-to-MX (bad default)

cr0x@server:~$ grep -R "smtp" -n /etc | head
/etc/postfix/main.cf:relayhost =
/etc/postfix/main.cf:inet_interfaces = loopback-only

Signification : Un relayhost vide signifie que Postfix tentera la livraison directe vers les enregistrements MX.

Décision : Définissez relayhost vers votre smart host authentifié à moins que vous n’exploitiez intentionnellement un MTA sortant.

Task 5: Inspect Postfix queue (is mail stuck?)

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F1A12C0A9     1542 Fri Jan  3 10:41:12  alerts@yourdomain.example
(connect to gmail-smtp-in.l.google.com[142.250.0.27]:25: Connection timed out)
                                         user@gmail.com

-- 1 Kbytes in 1 Request.

Signification : Postfix tente la livraison directe-to-MX sur le 25 et timeoute.

Décision : Arrêtez l’hémorragie : configurez relayhost et videz la file après vérification des identifiants.

Task 6: Identify who is blocking egress (local firewall check)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}

Signification : La chaîne output a une politique accept ; le pare-feu local ne bloque probablement pas.

Décision : Si vous voyez des drops explicites pour tcp dport 25/587/465, corrigez ces règles ou coordonnez avec la sécurité.

Task 7: Check cloud egress rules (security group / NACL equivalent via instance tooling)

cr0x@server:~$ ip route
default via 10.0.0.1 dev eth0
10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.12.34

Signification : Vous êtes dans un réseau privé ; l’egress passe probablement par du NAT ou des appliances pare-feu.

Décision : Validez que le NAT/politiques permettent 587/465. N’assumez pas que « route par défaut » signifie « SMTP fonctionne sur Internet ».

Task 8: Configure Postfix relayhost (core fix)

cr0x@server:~$ sudo postconf -e 'relayhost = [smtp.relay.example]:587'
cr0x@server:~$ sudo postconf -e 'smtp_tls_security_level = encrypt'
cr0x@server:~$ sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'

Signification : Les crochets forcent Postfix à utiliser l’hôte tel quel (pas de lookup MX). Le port 587 est précisé explicitement. TLS requis.

Décision : Procédez seulement si vous pouvez vous authentifier (tâche suivante). Sinon vous échangerez timeouts contre erreurs d’auth.

Task 9: Enable SASL authentication for the relay

cr0x@server:~$ sudo postconf -e 'smtp_sasl_auth_enable = yes'
cr0x@server:~$ sudo postconf -e 'smtp_sasl_security_options = noanonymous'
cr0x@server:~$ sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'

Signification : Postfix s’authentifiera avec les identifiants stockés dans /etc/postfix/sasl_passwd.

Décision : Verrouillez les permissions du fichier de mot de passe. Si vous ne pouvez pas le protéger, n’ayez pas d’identifiants SMTP sur cette machine.

Task 10: Create credentials map and verify it compiles

cr0x@server:~$ sudo bash -c 'printf "[smtp.relay.example]:587 username:app-specific-password\n" > /etc/postfix/sasl_passwd'
cr0x@server:~$ sudo chmod 0600 /etc/postfix/sasl_passwd
cr0x@server:~$ sudo postmap /etc/postfix/sasl_passwd
cr0x@server:~$ ls -l /etc/postfix/sasl_passwd*
-rw------- 1 root root  63 Jan  3 10:52 /etc/postfix/sasl_passwd
-rw------- 1 root root 122 Jan  3 10:52 /etc/postfix/sasl_passwd.db

Signification : Le fichier .db est la map compilée utilisée par Postfix. Les permissions sont strictes.

Décision : Si postmap renvoie une erreur, corrigez le format ou la chaîne d’outils de hachage avant de redémarrer Postfix.

Task 11: Reload Postfix and watch logs live during a test send

cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo tail -f /var/log/mail.log
Jan  3 10:54:11 server postfix/smtp[22119]: 3F1A12C0A9: to=<user@gmail.com>, relay=smtp.relay.example[203.0.113.10]:587, delay=12, delays=0.1/0.02/2.1/9.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as ABC123)

Signification : Le mail est maintenant relayé via le smart host sur 587 et accepté (DSN 2.0.0).

Décision : Videz la file si elle est en retard ; puis surveillez les taux de rebond et les tableaux de bord du fournisseur.

Task 12: Flush the queue (only after you fix the root issue)

cr0x@server:~$ sudo postfix flush
cr0x@server:~$ mailq | tail -n 3
Mail queue is empty

Signification : Les messages en attente sont retentés immédiatement ; la file est maintenant vide.

Décision : Si les messages se replacent avec des erreurs d’auth, arrêtez et corrigez les identifiants. Ne surchargez pas le relais et n’atteignez pas les limites de débit.

Task 13: Confirm you’re not accidentally an open relay (yes, people still do this)

cr0x@server:~$ sudo postconf mynetworks smtpd_recipient_restrictions | sed -n '1,3p'
mynetworks = 127.0.0.0/8 [::1]/128
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Signification : Seule la localhost est de confiance ; le relais sortant non authentifié est rejeté. Bien.

Décision : Si vous voyez des règles permissives (comme de larges plages RFC1918) sur un hôte exposé à Internet, corrigez cela immédiatement.

Task 14: Check DNS for SPF (basic but mandatory)

cr0x@server:~$ dig +short TXT yourdomain.example
"v=spf1 include:spf.relay.example -all"

Signification : SPF existe et délègue au provider relais.

Décision : Si SPF manque ou est trop permissif, corrigez avant d’augmenter le volume. La dette de délivrabilité s’accumule vite.

Task 15: Check DMARC policy (your domain’s safety rails)

cr0x@server:~$ dig +short TXT _dmarc.yourdomain.example
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.example; adkim=s; aspf=s"

Signification : DMARC existe et applique un alignement strict dans cet exemple.

Décision : Si vous n’avez pas de DMARC, commencez par p=none pour observer, puis passez progressivement à une politique d’application une fois l’alignement vérifié.

Task 16: Confirm the server isn’t trying IPv6 and failing (surprisingly common)

cr0x@server:~$ postconf inet_protocols
inet_protocols = all

Signification : Postfix utilisera IPv4 et IPv6. Si l’egress IPv6 est cassé, vous pouvez voir des échecs SMTP intermittents.

Décision : Si les journaux montrent des timeouts IPv6, corrigez le routage/DNS IPv6 ou définissez temporairement inet_protocols = ipv4.

Référence Postfix : relais via un smart host

Si vous exécutez Postfix sur le serveur (ou si votre application remet les mails à localhost), la configuration d’un smart host relais est la solution la plus propre.
L’objectif est simple : votre machine ne doit pas négocier avec des MX aléatoires sur Internet. Elle doit parler à un seul relais de confiance.

A sane minimal `main.cf` shape

Voici les réglages qui importent pour ce problème. Gardez le fichier petit. Gardez-le compréhensible. La complexité est là où naissent les incidents.

cr0x@server:~$ sudo postconf -n | egrep '^(relayhost|smtp_tls|smtp_sasl|inet_interfaces|myhostname|myorigin)'
myhostname = server.yourdomain.example
myorigin = /etc/mailname
inet_interfaces = loopback-only
relayhost = [smtp.relay.example]:587
smtp_tls_security_level = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

Quelques avis, puisque vous êtes venu pour des décisions :

Définissez inet_interfaces = loopback-only sur les serveurs applicatifs. Vous n’offrez pas SMTP entrant au monde. Ne faites pas semblant d’être un MTA.
Utilisez smtp_tls_security_level = encrypt pour ne pas rétrograder silencieusement en clair.
Encadrez le relayhost pour que Postfix ne le résolve pas en MX. Vous voulez une destination explicite.
Stockez les identifiants de façon sécurisée. Si cet hôte est éphémère, utilisez la gestion de secrets et générez la map au démarrage.

Ne divulguez pas les identifiants dans les logs ou l’historique shell

Utilisez des mots de passe spécifiques d’application ou des clés API limitées à l’envoi. Faites-les tourner. Traitez les identifiants SMTP comme des identifiants de base de données : volés = abus, abus = listes noires.

Envoi depuis l’application : SMTP vs API

Vous pouvez envoyer des e-mails depuis votre application de deux manières principales :
SMTP (vers un relais) ou une API HTTP (vers des fournisseurs du même type). Aucune n’est moralement pure.
Choisissez en fonction de vos modes d’échec et de votre maturité opérationnelle.

SMTP depuis les applications : simple, mais surveillez les timeouts et le pooling

Les bibliothèques SMTP varient énormément dans la gestion de STARTTLS, de la réutilisation de connexion et des échecs partiels.
Vous voulez :

Hôte/port explicite (587 ou 465), jamais de logique « envoyer au MX ».
Timeouts de connexion et de lecture raisonnables (pas infinis).
Retries avec backoff pour les réponses transitoires 4xx.
Une file d’attente (même locale simple) si le mail est critique pour la mission.

API e-mail : meilleure observabilité, moins de cas limites du protocole

Avec une API vous obtenez typiquement des IDs de message, des réponses d’erreur structurées et des webhooks pour rebonds/plainte.
Il est plus simple d’implémenter l’idempotence (« ne pas envoyer deux fois un e-mail de réinitialisation ») et d’instrumenter.

Le piège : si vous traitez l’API comme « toujours disponible », votre application flanchera quand le fournisseur aura un mauvais jour.
Utilisez une file, fixez un budget de retries et dégradez gracieusement.

Notions de délivrabilité incontournables

Le blocage du port 25 est un problème de transport. Mais une fois le transport réparé, la délivrabilité devient votre prochain incident.
C’est là que les équipes sont surprises : les messages sont « envoyés » (acceptés par le relais) mais jamais vus par les humains.

Utilisez un véritable enveloppe sender et gérez les rebonds

Configurez un domaine/adresse de rebond que vous surveillez. Si vous ignorez les rebonds, vous continuerez d’envoyer à des adresses mortes,
votre taux de plaintes augmentera et votre fournisseur vous limitera ou suspendra.

SPF, DKIM, DMARC : l’alignement plutôt que les superstitions

SPF indique quels serveurs peuvent envoyer pour votre domaine.
DKIM signe les messages pour que les destinataires puissent vérifier qu’ils n’ont pas été altérés.
DMARC rassemble le tout avec des règles d’alignement et des rapports.

La règle opérationnelle : le domaine dans l’en-tête From doit être aligné avec SPF et/ou DKIM, et DMARC doit exprimer une politique volontaire.
Si votre relais signe DKIM pour vous, parfait — publiez les enregistrements de sélecteur fournis et vérifiez leur propagation.

Les limites de débit existent ; ce n’est pas personnel

Même les bons relais imposent des limites par compte et par domaine. Traitez les réponses SMTP/API comme faisant partie du contrat.
Si vous bombardez le relais avec une boucle de retries bloquée, vous découvrirez la limite de façon désagréable.

Blague n°2 : Les codes d’erreur SMTP sont le seul endroit où un serveur vous dira poliment « je ne peux pas faire ça » tout en vous jugeant.

Mini-récits d’entreprise

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise SaaS de taille moyenne a migré des workloads d’un colo vers un grand cloud. L’application envoyait les e-mails d’inscription et de réinitialisation via une instance Postfix locale.
En colo, ils avaient une plage IP statique avec une réputation décente et le 25 sortant était ouvert. Dans le cloud, l’équipe a supposé la même chose.

La semaine de lancement est arrivée. L’app était saine, la base de données aussi, le trafic a augmenté — et la file de support a pris feu.
Les utilisateurs ne pouvaient pas vérifier leurs comptes, ni réinitialiser leurs mots de passe, et le churn a commencé en quelques heures.
L’ingénieur on-call a vu la croissance de la file Postfix et a supposé « le MX destinataire est lent ».

Ils ont scale-up la machine Postfix. Deux fois. La file a grossi plus vite, parce que chaque nouvelle instance était aussi bloquée sur le 25.
La mauvaise hypothèse n’était pas seulement « le port 25 est ouvert ». C’était « l’e-mail fait partie de la logique applicative, pas de l’infrastructure ».

La solution a été ennuyeuse : configurer relayhost vers un relais authentifié réputé sur 587, publier SPF/DKIM, vider la file, et ajouter un test d’intégration qui vérifie la connectivité de soumission SMTP au déploiement.
La recommandation du postmortem était encore plus ennuyeuse : traiter l’e-mail comme une dépendance externe avec des SLOs explicites et alertes sur la profondeur de la file.

Mini-récit 2 : L’optimisation qui a mal tourné

Une équipe d’entreprise voulait réduire la latence des e-mails transactionnels. Quelqu’un a proposé de garder une connexion SMTP persistante ouverte depuis chaque pod applicatif vers le fournisseur de relais,
la réutilisant pour des centaines de messages afin d’économiser les handshakes TCP et TLS. Sur le papier, c’était élégant.

En pratique, cela a créé un nouveau mode de défaillance : lorsque le relais a fait tourner ses certificats ou imposé des timeouts d’inactivité, les pods continuaient d’écrire sur des sockets morts.
Certaines bibliothèques SMTP indiquaient un succès jusqu’au flush final ; d’autres lançaient des exceptions opaques ; quelques-unes restaient bloquées.
La latence s’est améliorée jusqu’au moment où elle ne l’était plus, et les livraisons sont devenues non déterministes.

L’équipe a aussi découvert que leur « optimisation » amplifiait les rafales liées aux limites de débit. Quand un job par lot démarrait, chaque pod a déversé des messages aussi vite que possible sur une connexion chaude.
Le relais a répondu par des déferrals transitoires 4xx, que leur logique de retries a interprétés comme « réessayer immédiatement », produisant une sorte d’auto-DDOS.

Ils ont remis en place un service d’envoi basé sur une file contrôlée avec concurrence bornée, timeouts explicites et backoff exponentiel.
L’architecture finale était moins astucieuse et beaucoup plus prévisible. La prévisibilité est le but.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une plateforme de services financiers réalisait des tests hebdomadaires de reprise après sinistre. Dans la checklist : confirmer l’envoi d’e-mails via le relais depuis la région DR, y compris l’authentification DNS.
Ce n’était pas du travail glamour. C’était aussi la première chose que l’on tentait d’économiser quand le planning se resserrait.

Un trimestre, le test DR a échoué : les e-mails étaient acceptés par le relais, mais arrivaient sans signatures DKIM.
L’équipe a retracé le problème à un compte relais mal scope dans l’environnement DR : il pouvait soumettre du mail, mais la configuration de signature n’était pas attachée à cet ensemble d’identifiants.

Ils ont corrigé la configuration avant que cela n’ait jamais d’impact réel, et plus tard cette année-là un incident régional a forcé le trafic vers le DR.
Quand les notifications clients ont été envoyées, elles sont arrivées proprement. Pas de panique. Pas de « pourquoi c’est dans le spam ? »

La leçon : les systèmes les plus fiables se construisent à partir de petites étapes vérifiables et ennuyeuses. Si votre chemin e-mail n’est pas dans votre plan DR, vous n’avez pas de plan DR — vous avez un vœu.

Erreurs courantes

1) Symptom: mail queue grows; logs show timeouts to recipient MX on port 25

Cause racine : le 25 sortant est bloqué ; Postfix tente la livraison directe vers les MX.

Correction : Configurez relayhost vers un smart host authentifié sur 587/465 ; exigez TLS ; videz la file ensuite.

2) Symptom: “SASL authentication failed” or “535 Authentication credentials invalid”

Cause racine : mauvais nom d’utilisateur/mot de passe, mauvais port, ou le fournisseur exige un mot de passe d’application.

Correction : Vérifiez le format des identifiants dans /etc/postfix/sasl_passwd, relancez postmap, confirmez l’endpoint de soumission et les exigences TLS du fournisseur.

3) Symptom: messages accepted by relay, but land in spam (or never seen)

Cause racine : SPF ou DKIM manquants/incorrects, From mal aligné, ou envoi depuis un domaine sans réputation.

Correction : Publiez SPF incluant le relais ; activez la signature DKIM ; ajoutez DMARC ; assurez l’alignement du From avec le domaine signé.

4) Symptom: intermittent timeouts; logs show IPv6 addresses failing

Cause racine : egress/routage IPv6 cassé, mais le système préfère parfois les enregistrements AAAA.

Correction : Réparez le chemin IPv6 ou configurez Postfix en IPv4 uniquement comme mesure d’atténuation (inet_protocols = ipv4).

5) Symptom: TLS handshake failures with STARTTLS

Cause racine : proxy d’inspection TLS, bundle CA manquant, ou fournisseur exigeant SNI/TLS moderne.

Correction : Validez avec openssl s_client ; mettez à jour les certificats CA ; utilisez le port 465 si STARTTLS est perturbé ; assurez-vous que -servername fonctionne.

6) Symptom: “Relay access denied” or “unauthorized sender”

Cause racine : le fournisseur exige que l’expéditeur d’enveloppe ou le domaine From soit vérifié, ou vous envoyez depuis un domaine non approuvé.

Correction : Vérifiez le domaine d’envoi chez le fournisseur ; alignez le From ; configurez myorigin/myhostname de façon sensée ; évitez les adresses From aléatoires.

7) Symptom: you can send from the host, but the application can’t

Cause racine : l’application utilise ses propres paramètres SMTP (direct-to-MX, mauvais port), ou les politiques réseau des conteneurs bloquent l’egress.

Correction : Standardisez : soit l’app envoie à Postfix local, soit l’app envoie directement au relais sur 587/465. Ne mélangez pas silencieusement.

8) Symptom: high latency, occasional duplicates

Cause racine : logique de retries sans idempotence ; réutilisation de connexion SMTP défaillante ; absence de file.

Correction : Placez l’envoi d’emails derrière une file ; utilisez des IDs de message et des clés de déduplication ; bornez la concurrence et les retries.

Checklists / plan étape par étape

Plan étape par étape : de « bloqué » à « envoi fiable »

Confirmer le blocage : testez le TCP sur 25/587/465 depuis l’hôte envoyeur.
Choisir un modèle d’envoi : soumission SMTP (587/465) vers un relais, ou API HTTPS.
Arrêter la livraison directe-to-MX : configurez relayhost de Postfix ou l’hôte SMTP de l’app.
Exiger TLS : STARTTLS sur 587 ou TLS implicite sur 465.
Activer l’auth : identifiants SASL ou clé API.
Sécuriser : écoute loopback-only pour Postfix ; permissions des fichiers d’identifiants ; comptes au moindre privilège.
Envoyer un test : surveillez les journaux pour status=sent et un ID de file du fournisseur.
Corriger l’auth DNS : SPF, DKIM, DMARC alignés avec le domaine From.
Implémenter la gestion des rebonds/plainte : boîte mail ou webhook ; alerter sur les pics.
Opérationnaliser : surveillez la profondeur des files, les codes d’erreur, les déferrals du fournisseur et la latence de livraison.

Checklist on-call : quand les e-mails s’arrêtent à nouveau

Le relais est-il joignable sur 587/465 depuis les hôtes affectés ?
Les identifiants sont-ils encore valides (rotés ? expirés ?)
Le fournisseur renvoie-t-il des déferrals 4xx (limite) ou des rejets 5xx (politique) ?
La résolution DNS est-elle saine pour l’endpoint relais et vos enregistrements de domaine ?
Quelque chose a-t-il changé : pare-feu, proxy d’egress, bundle CA, synchronisation horaire ?

Checklist sécurité : évitez de transformer l’e-mail en incident

Stockez les identifiants SMTP dans un gestionnaire de secrets ; rendez-les à l’exécution ; faites-les tourner régulièrement.
N’autorisez pas le SMTP entrant depuis Internet sauf si vous exploitez intentionnellement un MTA.
Utilisez des sous-domaines dédiés pour des flux mail différents (transactionnel vs marketing) lorsque possible.
Mettez en place des alertes sensées : une montée soudaine du volume envoyé peut indiquer des identifiants compromis.

Faits intéressants et contexte historique

SMTP est antérieur à l’internet commercial : il a été standardisé au début des années 1980, quand la confiance entre hôtes était plus présumée que vérifiée.
Le port 587 existe pour une raison : c’est le port de soumission destiné aux clients pour soumettre du mail à un MSA (Mail Submission Agent), généralement avec authentification.
Le port 465 a une histoire étrange : il a été utilisé tôt pour TLS implicite, puis déprécié, puis réapparu parce qu’il fonctionne et que les clients le supportent.
Le blocage du port 25 est devenu la norme avec le haut débit : à mesure que les machines domestiques étaient infectées et que le spam explosait, les FAI ont commencé à bloquer le 25 sortant depuis les réseaux résidentiels.
Les fournisseurs cloud bloquent par défaut pour protéger la réputation IP : un seul sous-réseau abusé peut empoisonner la délivrabilité de milliers de locataires légitimes.
SPF est né d’une douleur opérationnelle : il a émergé au début des années 2000 pour réduire l’usurpation de domaine d’expéditeur, mais il n’authentifie que le chemin d’enveloppe, pas l’intégrité du message.
L’idée centrale de DKIM est la responsabilité cryptographique : un domaine signe le mail pour que les destinataires puissent vérifier, déplaçant la confiance au-delà de la seule réputation IP.
DMARC a ajouté une politique et des rapports : il indique aux récepteurs quoi faire en cas d’échec d’authentification et fournit des boucles de rétroaction via des rapports agrégés.
Le courriel reste l’un des derniers protocoles fédérés mondiaux : c’est un système ouvert où tout le monde peut exploiter un serveur — excellent pour la résilience, difficile pour lutter contre les abus.

FAQ

1) Pourquoi le port 25 est-il bloqué sur ma VM ?

Généralement parce que votre fournisseur bloque le SMTP sortant par défaut pour prévenir le spam et protéger la réputation de sa plage IP.
Parfois c’est votre propre pare-feu ou politique d’egress, mais en cloud c’est souvent imposé en amont.

2) Puis-je simplement demander le déblocage du port 25 ?

Parfois, oui. Mais vous hériterez toujours du travail de délivrabilité : warmup IP, reverse DNS, gestion des abus, surveillance des listes noires.
Si vous avez seulement besoin d’e-mails transactionnels, utiliser un relais sur 587/465 est presque toujours la meilleure décision business.

3) Quelle est la différence entre le port 25 et le port 587 ?

Le port 25 est traditionnellement pour la livraison MTA-à-MTA. Le port 587 est pour la soumission authentifiée de mails depuis les clients/apps vers un relais (MSA),
typiquement avec STARTTLS et des identifiants.

4) Dois-je utiliser le port 465 ou 587 ?

Par défaut, privilégiez 587 avec STARTTLS. Utilisez 465 si votre environnement casse STARTTLS ou si votre fournisseur recommande 465.
L’important : utilisez TLS et l’authentification dans les deux cas.

5) Mon relais accepte le mail, mais Gmail le met en spam. Le port 25 est-il encore en cause ?

Non. C’est un problème de délivrabilité : SPF/DKIM/DMARC manquants ou mal alignés, domaine d’expéditeur récent sans réputation, contenu, ou taux élevé de rebonds/plainte.
Le port 25 est un problème de transport ; le placement en spam relève de la réputation et de l’authentification.

6) Est-il sûr de stocker des identifiants SMTP sur le serveur ?

Cela peut l’être, si vous les traitez comme tout autre secret : moindre privilège, permissions strictes, pas de logging, rotation régulière.
Préférez les gestionnaires de secrets et des identifiants à courte durée quand c’est possible.

7) Ai-je besoin de Postfix du tout ? Mon app peut-elle envoyer directement au relais ?

Vous pouvez faire l’un ou l’autre. Postfix est utile comme tampon local et point de politique (files, retries, logs standardisés).
L’envoi direct app→relais peut convenir pour des systèmes plus simples — veillez juste à implémenter des retries sensés et des timeouts.

8) Que faire si le SMTP sortant est bloqué sur tous les ports ?

Utilisez une API e-mail via HTTPS, ou routez le mail via une passerelle interne qui a l’egress autorisé.
Vérifiez aussi si votre réseau exige un proxy explicite pour le trafic sortant vers Internet.

9) Comment savoir si le problème vient du DNS ?

Si vous voyez des erreurs « host not found », des échecs intermittents vers différentes destinations, ou vos requêtes SPF/DKIM/DMARC échouent,
vous avez probablement des problèmes de résolution DNS. Testez avec dig, vérifiez la configuration du résolveur et cherchez des surprises de type split-horizon.

10) Puis-je exploiter mon propre serveur mail et éviter totalement les relais ?

Vous pouvez, et certains le font encore, mais c’est un engagement opérationnel. Vous aurez besoin d’une réputation IP stable, d’un reverse DNS correct, de gestion des abus,
de monitoring et d’un réglage constant. Si l’e-mail n’est pas votre produit, n’en faites pas votre hobby.

Conclusion : prochaines étapes qui ne vous réveilleront pas à 3h du matin

Quand le port 25 est bloqué, la bonne décision n’est pas de chercher des astuces. La bonne décision est d’arrêter la livraison direct-to-MX depuis les serveurs applicatifs.
Utilisez la soumission authentifiée sur 587/465, ou une API e-mail, et laissez un relais approprié gérer la partie « Internet public » de SMTP.

Étapes pratiques :

Exécutez les tests de connectivité pour confirmer où se situe le blocage (25 vs 587/465).
Choisissez un relais ou une approche API et standardisez-la sur tous les environnements.
Configurez Postfix (ou votre app) pour n’envoyer que vers ce relais avec TLS + auth.
Publiez et vérifiez l’alignement SPF/DKIM/DMARC pour le domaine From.
Ajoutez du monitoring : profondeur de file, déferrals du relais, taux de rebond/plainte.

Le courrier électronique est un problème de fiabilité déguisé en moyen de communication. Traitez-le comme une infrastructure de production et il se comportera.