Port SMTP 25 bloqué : « Connection timed out » sur AWS, Azure, GCP, VPS

Ce que ça veut dire

Pour livrer un email, votre serveur se connecte au serveur mail du destinataire sur le port 25. Si cette connexion n'obtient jamais de réponse, votre réseau ou votre hébergeur bloque probablement le port 25 en sortie. Les messages restent dans la file d'attente et finissent par vous être retournés au bout de plusieurs jours.

Selon le logiciel, l'erreur ressemble généralement à ceci :

connect to gmail-smtp-in.l.google.com[142.250.27.26]:25: Connection timed out
Error: connect ETIMEDOUT 203.0.113.50:25
SMTP ERROR: Failed to connect to server: Connection timed out (110)

« Timed out » (aucune réponse du tout) indique un blocage. « Connection refused » ou une réponse 5xx est un problème différent, de l'autre côté.

Pourquoi cela arrive

Les spammeurs aiment louer des serveurs bon marché, donc la plupart des hébergeurs bloquent le port 25 en sortie par défaut. Les politiques changent : consultez la documentation actuelle de votre hébergeur. Au moment où nous écrivons :

• Amazon EC2 et Lightsail restreignent le port 25 sortant par défaut. Vous pouvez demander à AWS de lever la limite via leur formulaire, en expliquant votre usage. Amazon SES sur le port 587 ou 465 est l'alternative.
• Google Cloud (Compute Engine) bloque les connexions sortantes vers le port 25 des adresses externes. Google recommande un service d'envoi sur un autre port.
• Microsoft Azure bloque le port 25 sortant pour la plupart des types d'abonnement ; seuls certains contrats entreprise peuvent envoyer directement. Microsoft recommande un relais authentifié.
• DigitalOcean bloque le SMTP sur les Droplets par défaut ; selon des retours de la communauté, le blocage peut inclure les ports 465 et 587.
• Les connexions internet domestiques et de bureau bloquent généralement aussi le port 25. Les IP résidentielles figurent en plus sur des listes de blocage, donc envoyer directement depuis chez soi fonctionne rarement de toute façon.

Comment vérifier

Depuis le serveur lui-même, testez le port 25 vers un grand serveur mail, puis un port de soumission :

nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.gmail.com 587

Si le 587 se connecte et que le 25 expire, le blocage se situe sur votre réseau ou chez votre hébergeur, pas chez Google. Vérifiez aussi votre propre pare-feu (ufw status, iptables -L OUTPUT) et les règles sortantes de votre pare-feu cloud ou de votre security group.

Sur Postfix, postqueue -p liste les messages bloqués avec la raison. Une fois que vous avez une route qui fonctionne, envoyez un test à l'adresse unique affichée sur la page d'accueil de Delivmail pour vérifier tout le parcours.

Comment corriger

Option 1 : demander à l'hébergeur de débloquer le port 25

Certains hébergeurs (AWS par exemple) acceptent une demande. Il faut généralement expliquer ce que vous envoyez, régler un nom de reverse DNS et garder un faible taux de plaintes. Avant cela, lisez la checklist pour votre propre serveur mail : une nouvelle IP cloud n'a aucune réputation.

Option 2 : relayer via un service d'envoi sur le port 587

C'est la solution habituelle. Votre serveur envoie vers un service d'email (votre fournisseur de messagerie ou un service transactionnel) sur le port 587 avec un identifiant, et ce service livre sur le port 25 depuis ses propres IP bien réputées. Beaucoup de services acceptent aussi le port 2525 ou une API HTTP si le 587 est bloqué lui aussi. Exemple pour Postfix, dans main.cf :

relayhost = [smtp.your-provider.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Et dans /etc/postfix/sasl_passwd :

[smtp.your-provider.com]:587   username:password

chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
systemctl reload postfix

Dans une application (nodemailer, PHPMailer…), utilisez l'hôte du service avec port: 587 et STARTTLS au lieu d'une connexion directe.

Authentifiez ensuite le relais

Le relais envoie depuis de nouvelles IP : ajoutez-le au SPF et activez sa signature DKIM pour votre domaine ; voir authentifier votre domaine dans vos outils d'envoi. Sinon, vous obtiendrez un SPF fail : serveur non autorisé.

Vérifiez que c'est corrigé

Videz la file d'attente (postqueue -f) et surveillez le journal : vous devez voir status=sent avec votre hôte de relais. Lancez un nouveau test Delivmail et vérifiez que le SPF, le DKIM et le DMARC passent pour le relais, puis renvoyez votre message à l'adresse qui avait échoué.