SMTP-Port 25 blockiert: „Connection timed out“ bei AWS, Azure, GCP, VPS

Was das bedeutet

Um eine E-Mail zuzustellen, verbindet sich dein Server auf Port 25 mit dem Mailserver des Empfängers. Bekommt diese Verbindung nie eine Antwort, blockiert wahrscheinlich dein Netzwerk oder dein Hoster ausgehenden Verkehr auf Port 25. Nachrichten bleiben in der Warteschlange und kommen nach einigen Tagen schließlich zurück.

Je nach Software sieht der Fehler meist so aus:

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“ (gar keine Antwort) deutet auf eine Sperre hin. „Connection refused“ oder eine 5xx-Antwort ist ein anderes Problem auf der Gegenseite.

Warum das passiert

Spammer mieten gern billige Server, deshalb sperren die meisten Anbieter ausgehenden Port 25 standardmäßig. Die Regeln ändern sich, also prüfe die aktuelle Dokumentation deines Anbieters. Zum Zeitpunkt des Schreibens:

• Amazon EC2 und Lightsail beschränken ausgehenden Port 25 standardmäßig. Du kannst AWS über ihr Antragsformular bitten, die Beschränkung aufzuheben, und deinen Einsatzzweck erklären. Amazon SES auf Port 587 oder 465 ist die Alternative.
• Google Cloud (Compute Engine) sperrt ausgehende Verbindungen auf Port 25 zu externen Adressen. Google empfiehlt einen Mail-Dienst auf einem anderen Port.
• Microsoft Azure sperrt ausgehenden Port 25 für die meisten Abonnementtypen; nur manche Enterprise-Verträge dürfen direkt senden. Microsoft empfiehlt ein authentifiziertes Relay.
• DigitalOcean sperrt SMTP auf Droplets standardmäßig; laut Berichten aus der Community kann die Sperre auch die Ports 465 und 587 umfassen.
• Internetanschlüsse zu Hause und im Büro sperren Port 25 meist ebenfalls. Private IPs stehen außerdem auf Blocklisten, direktes Senden von zu Hause klappt also ohnehin selten.

So prüfst du es

Teste vom Server selbst Port 25 zu einem großen Mailserver und danach einen Submission-Port:

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

Verbindet sich 587 und läuft 25 in einen Timeout, liegt die Sperre bei deinem Netzwerk oder Anbieter, nicht bei Google. Prüfe auch deine eigene Firewall (ufw status, iptables -L OUTPUT) und die Regeln deiner Cloud-Firewall oder Security Group für ausgehenden Verkehr.

Bei Postfix listet postqueue -p hängende Nachrichten mit dem Grund auf. Sobald du einen funktionierenden Weg hast, schick einen Test an die einmalige Adresse auf der Startseite von Delivmail, um den gesamten Pfad zu prüfen.

So behebst du es

Option 1: den Anbieter bitten, Port 25 freizugeben

Manche Anbieter (zum Beispiel AWS) nehmen einen Antrag an. Meist musst du erklären, was du versendest, einen Reverse-DNS-Namen setzen und die Beschwerden niedrig halten. Lies vorher die Checkliste für den eigenen Mailserver: Eine neue Cloud-IP hat keine Reputation.

Option 2: über einen Mail-Dienst auf Port 587 weiterleiten

Das ist die übliche Lösung. Dein Server sendet mit Anmeldung auf Port 587 an einen E-Mail-Dienst (deinen Postfach-Anbieter oder einen Transaktionsdienst), und dieser Dienst stellt auf Port 25 von seinen eigenen IPs mit gutem Ruf zu. Viele Dienste akzeptieren auch Port 2525 oder eine HTTP-API, falls 587 ebenfalls gesperrt ist. Postfix-Beispiel, in 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

Und in /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

In einer Anwendung (nodemailer, PHPMailer…) nimm den Host des Dienstes mit port: 587 und STARTTLS statt einer direkten Verbindung.

Dann das Relay authentifizieren

Das Relay sendet von neuen IPs, also nimm es in SPF auf und aktiviere seine DKIM-Signatur für deine Domain; siehe Deine Domain in Versand-Tools authentifizieren. Sonst bekommst du ein SPF fail: Server nicht autorisiert.

Prüfe, ob es behoben ist

Leere die Warteschlange (postqueue -f) und beobachte das Log: Du solltest status=sent mit deinem Relay-Host sehen. Mach einen neuen Delivmail-Test und prüfe, dass SPF, DKIM und DMARC für das Relay bestehen, und sende dann erneut an die Adresse, die fehlgeschlagen ist.