So sieht die Meldung aus
550 5.1.1 <anna@example.com>: Recipient address rejected: User unknown in virtual mailbox tableHäufige Ursachen
- Tippfehler in der Adresse oder Postfach wurde gelöscht.
- Adresse fehlt in
virtual_mailbox_mapsbzw. Alias fehlt invirtual_alias_maps. - Hash-Datei nach der Änderung nicht mit
postmapneu gebaut. - Domain steht in
mydestinationund gleichzeitig invirtual_mailbox_domains– Postfix sucht dann lokale Unix-Benutzer („User unknown in local recipient table“). - Nach einer Migration zeigt der MX noch auf den alten Server, der die Postfächer nicht mehr hat.
Prüfen
- Domain-Klassen und Maps von Postfix anzeigen
postconf mydestination virtual_mailbox_domains virtual_mailbox_maps virtual_alias_maps - Prüfen, ob die Adresse als Postfach bekannt ist
postmap -q anna@example.com $(postconf -h virtual_mailbox_maps) - Prüfen, ob es einen Alias für die Adresse gibt
postmap -q anna@example.com $(postconf -h virtual_alias_maps) - Abgelehnte Empfänger im Log finden
journalctl -u postfix --since '1 hour ago' | grep 'User unknown'
Lösung
- Adresse beim Absender prüfen lassen – oft ist es nur ein Tippfehler.
- Postfach oder Alias anlegen und bei Hash-Maps
postmap /etc/postfix/virtualsowiepostfix reloadausführen. - Jede Domain genau einer Klasse zuordnen: lokale Domains in
mydestination, virtuelle nur invirtual_mailbox_domains. - Nach Migrationen MX-Eintrag und TTL prüfen, damit Mail nicht auf dem alten Server landet.
- Keine Catch-all-Adresse als Workaround: Sie zieht Spam an und versteckt echte Fehler.
Häufige Fragen
Ist 550 5.1.1 ein Spam-Problem?
Nein. Der Code betrifft nur den Empfänger. Ihre Reputation ist nicht betroffen, solange Sie nicht massenhaft an ungültige Adressen senden.
Warum lehnt Postfix ab, obwohl der Benutzer in der Datenbank steht?
Meist liefert die SQL-Abfrage in der Map kein Ergebnis, z. B. wegen eines Tippfehlers in der Query oder eines falschen Feldes. Testen Sie mit postmap -q direkt gegen die Map-Datei.