Port 25 Sperre bei Cloud-Hostern: Übersicht, Freischaltung und Relays

Alle ausgehenden Port-25-Richtlinien für Cloud- und Bare-Metal-Server im Vergleich — mit Links zur Freischaltung pro Anbieter.

Stand: Juli 2026

Zusammenfassung: Fast jeder moderne Cloud- und Bare-Metal-Hoster blockiert den ausgehenden E-Mail-Versand über TCP-Port 25 standardmäßig, um Spam zu verhindern und IP-Reputationen zu schützen. Diese Übersicht zeigt die Richtlinien von 13 großen Anbietern, erklärt die jeweiligen Entsperrungswege und zeigt, warum Smarthost-Relays über Port 587 oft die bessere Lösung sind.

Wenn du auf einem virtuellen Server (VPS, Cloud Compute) oder einem dedizierten Server einen eigenen Mailserver (z. B. Postfix, Mailcow, Microsoft Exchange) installierst, laufen Verbindungen zu externen Empfängern fast immer ins Leere. Der Grund dafür ist keine Fehlkonfiguration auf deinem Server, sondern eine netzwerkseitige Port-25-Sperre deines Hosters.

Warum Hoster den Port 25 sperren

Rechenzentrums-IPs werden dynamisch vergeben und häufig von missbräuchlichen Akteuren für automatisierte Spam- und Phishing-Kampagnen missbraucht. Ohne netzwerkseitige Filter würden ganze IP-Subnetze eines Anbieters innerhalb kürzester Zeit auf globalen Blocklisten (DNSBLs) wie Spamhaus oder UCEPROTECT landen. Die Port-25-Sperre schützt somit die Zustellbarkeit des gesamten Infrastrukturnetzwerks.

Die 13 Hoster-Richtlinien im Detail

Jeder Anbieter regelt die Freischaltung nach eigenen Kriterien – von der automatischen Entsperrung im Server-Control-Panel bis hin zu strengen Stichtags- und Abonnement-Prüfungen. Wähle deinen Hoster aus der folgenden Liste, um zur spezifischen Anleitung mit allen Voraussetzungen und Zitaten zu gelangen:

Deutsche und europäische Hoster

Globale Cloud-Plattformen und US-Hoster

Das Grundproblem: Schlechte IP-Reputation trotz Freischaltung

Selbst wenn dein Hoster den Port 25 auf deinen Antrag hin freischaltet, stehst du vor einer noch größeren Hürde: der Reputation von Rechenzentrums-IPs. Große E-Mail-Anbieter wie Gmail, Yahoo, Apple und Outlook.com bewerten E-Mails aus dynamischen oder häufig wechselnden Cloud-Subnetzen extrem kritisch.

Auch bei perfekt konfigurierten SPF-, DKIM- und DMARC-Records landen E-Mails von direkt versendenden Root- und Cloud-Servern häufig im Spam-Ordner oder werden auf Basis von Blacklisten (z. B. Spamhaus oder UCEPROTECT) abgelehnt.

Die Lösung: Smarthost-Relaying über Port 587

Um sowohl die Port-25-Sperren der Hoster als auch die Reputationsrisiken von Rechenzentrums-IPs zu umgehen, solltest du ausgehende E-Mails über Port 587 (Submission) an ein externes Smarthost-Relay senden. Port 587 dient dem authentifizierten und verschlüsselten Client-Versand und wird von fast allen Hostern (mit Ausnahme von DigitalOcean und initial Scaleway) uneingeschränkt durchgelassen.

Ein typischer Auszug in deiner Postfix-Konfigurationsdatei /etc/postfix/main.cf für ein Smarthost-Relay lautet:

relayhost = [smtp.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

Oder zuverlässig über Dispatch versenden. Wenn du dir Support-Anträge, KYC-Verifizierungen, Blacklist-Probleme und die Wartung eigener Relays komplett sparen willst, kannst du deinen E-Mail-Versand auch einfach und abgesichert über Dispatch abwickeln.

Konfiguration prüfen

Sobald dein Versandweg aktiv ist, überprüfe deine E-Mail-Authentifizierung (SPF, DKIM, DMARC) sowie deine Zustellbarkeit mit dem kostenlosen Kuveris-Scanner.