So sieht die Meldung aus
550 5.7.1 <info@beispiel.de>: Relay access deniedHäufige Ursachen
- Mailprogramm oder Anwendung versendet ohne SMTP-AUTH.
- Versand über Port 25 statt Submission-Port 587 (bzw. 465) mit Anmeldung.
- Empfängerdomain fehlt in
virtual_mailbox_domains,mydestinationoderrelay_domains. - IP des Applikationsservers steht nicht in
mynetworks. - Der Zielserver (z. B. Exchange-Empfangsconnector) lehnt Absender oder IP per Richtlinie ab.
Prüfen
- Relay-Einstellungen von Postfix anzeigen
postconf -n | grep -E 'mynetworks|relay_domains|smtpd_relay_restrictions|virtual_mailbox_domains' - Abgelehnte Versuche mit Client-IP im Log finden
journalctl -u postfix --since '1 hour ago' | grep 'Relay access denied' - Versand mit Anmeldung über Port 587 testen (fragt das Passwort ab)
swaks --to test@example.com --from info@beispiel.de --server mail.beispiel.de --port 587 --tls --auth LOGIN --auth-user info@beispiel.de - Prüfen, ob Port 587 lauscht
ss -ltnp | grep -E ':(25|465|587) '
Lösung
- Im Client SMTP-AUTH aktivieren und Port 587 mit STARTTLS verwenden.
- Eigene Domains in
virtual_mailbox_domainsbzw.relay_domainseintragen, danachpostfix reload. - Relay-Regeln sauber setzen:
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination. - Feste interne Server gezielt per /32 in
mynetworksaufnehmen – nie ganze Netze. - Bei Ablehnung durch fremde Server den vollständigen Bounce-Text lesen und die genannte Richtlinie beim Empfänger klären.
Häufige Fragen
Bedeutet 550 5.7.1 immer „Relay access denied“?
Nein. 5.7.1 ist ein allgemeiner Policy-Code. Auch Microsoft 365, Spamfilter oder Absenderbeschränkungen nutzen ihn. Entscheidend ist der Text nach dem Code.
Kann ich das Problem lösen, indem ich mynetworks erweitere?
Nur für einzelne, vertrauenswürdige Hosts. Ein Eintrag wie 0.0.0.0/0 macht den Server zum offenen Relay, der innerhalb von Stunden auf Blocklisten landet.