Exchange-Ratgeber › Authentifizierung und SMTP-Fehler

Unzustellbarkeitsberichte für externe Absender hinter einem POP3-Connector: unbekannte Empfänger, zu große Mails und Provider, die leere Absender blockieren

Wird Mail aus einem Provider-Postfach abgeholt, hat der Provider die Nachricht bereits angenommen. Ein externer Absender erfährt von einem unbekannten Empfänger oder einer Größenablehnung deshalb nur, wenn Exchange die Nachricht vom Connector annimmt und anschließend selbst einen Unzustellbarkeitsbericht (NDR) erzeugt – und wenn Ihr Ausgangsrelay das leere MAIL FROM dieses Berichts durchlässt. Eine Ablehnung in der SMTP-Sitzung zwischen Connector und Exchange erreicht den Connector und sonst niemanden. Ein POP3-/IMAP-Connector wie POPcon erzeugt selbst keine Unzustellbarkeitsberichte.

Aktualisiert am 2026-10-03

Das Verhalten von Exchange auf dieser Seite stammt aus Microsoft Learn und ist dort für Exchange Server 2016, 2019 und Subscription Edition dokumentiert; die Connector-Seite stammt aus der Knowledge Base zu POPcon und MultiSendcon, deren Artikel zu diesem Thema für Exchange 2003 bis 2016 geschrieben wurden. Wo beide Quellen voneinander abweichen, stehen beide da.

Warum ein Unzustellbarkeitsbericht hinter einem Connector anders entsteht

Stellt ein Mailserver aus dem Internet direkt an Exchange zu, geht eine Ablehnung in der SMTP-Sitzung an den sendenden Server zurück, und dieser informiert seinen Benutzer. Hinter einem Connector hat der sendende Server seine Arbeit erledigt, als der Provider die Nachricht entgegennahm. Alles Weitere spielt sich zwischen drei Beteiligten ab: dem Connector, der sich am Provider-Postfach anmeldet und jede Nachricht per SMTP an Exchange übergibt; Exchange, das die Nachricht in dieser Sitzung ablehnt oder annimmt; und dem Weg, auf dem Exchange seine eigene Mail nach außen schickt. Einen Bericht für den ursprünglichen Absender gibt es nur, wenn Exchange ihn erzeugt, und er kommt nur an, wenn dieser Ausgangsweg ihn transportiert.

Den Bericht selbst beschreibt Microsoft unter DSNs und NDRs in Exchange Server: Tritt bei der Zustellung ein Problem auf, sendet Exchange dem Absender einen NDR mit einem Code, der den Grund nennt. Für einen nicht vorhandenen Empfänger lautet der erweiterte Statuscode 5.1.1, „RESOLVER.ADR.ExRecipNotFound; not found“ oder „User unknown“.

Die drei Fälle

Fall	Wenn Exchange in der SMTP-Sitzung ablehnt	Wenn Exchange die Nachricht annimmt	Was der Absender standardmäßig erfährt
Empfänger existiert nicht	Die Nachricht bleibt in der POPcon-Warteschlange (Knowledge Base) – es sei denn, POPcon leitet unbekannte Empfänger an den Postmaster um; dann wird sie dort zugestellt	Exchange erzeugt den Unzustellbarkeitsbericht, Status 5.1.1	In den ersten beiden Varianten nichts, in der dritten den Bericht
Nachricht ist zu groß	Am Empfangsconnector abgelehnt; POPcon verschiebt sie in den Ordner TOOLARGE	Am Limit der Organisation oder des Postfachs abgewiesen; Exchange sendet den Unzustellbarkeitsbericht	Nichts, solange die Nachricht in TOOLARGE wartet; sonst den Bericht
Empfänger ist abwesend	Entfällt: Die Nachricht wird zugestellt	Exchange sendet die automatische Antwort, wenn die Einstellungen der Remotedomäne es erlauben	Die Antwort, sofern sie erlaubt ist und das Ausgangsrelay sie annimmt

Unbekannte Empfänger: Postmaster, Warteschlange oder Bericht

Dieser Fall hat die meisten Varianten, weil sowohl der Connector als auch Exchange eine Einstellung dafür haben.

Am Connector. POPcon kann ab Version 3.00 in den POP3-Einstellungen die Funktion „Mail an unbekannte Empfänger umleiten an...“ aktivieren; dort tragen Sie einen Postmaster oder Administrator als Empfänger für diese Mails ein (Knowledge Base). Die Nachricht erreicht einen Menschen, der sie weiterleiten kann; der Absender erfährt nichts. Wie ein Connector die Empfänger von Mail aus einem Catch-all-Postfach überhaupt ermittelt, steht im Ratgeber Catch-all-Postfach oder ein POP3-Postfach pro Benutzer.

In Exchange. Ist die Umleitung ausgeschaltet, versucht POPcon, die Mail an die ursprüngliche (unbekannte) Adresse zuzustellen, und Exchange entscheidet. Nach Microsofts Beschreibung der akzeptierten Domänen nimmt die Exchange-Organisation für eine autoritative Domäne Nachrichten an und ist dafür verantwortlich, Unzustellbarkeitsberichte für nicht vorhandene Empfänger zu erstellen (Akzeptierte Domänen in Exchange Server). Ob Exchange so weit kommt, hängt von der Empfängerfilterung ab. Prüft der Empfängerfilter-Agent die Empfänger, wird eine Nachricht an einen nicht gefundenen Empfänger schon in der SMTP-Sitzung beantwortet: Der Exchange-Server sendet dem sendenden Server den Sitzungsfehler 550 5.1.1 User unknown (Empfängerfilterung auf Edge-Transportservern). Hinter einem Connector ist der „sendende Server“ der Connector, und die Nachricht bleibt in seiner Warteschlange.

Der Knowledge-Base-Artikel Wie kann ich Unzustellbarkeitsnachrichten wegen nicht-existierender Mailadressen versenden lassen? nennt deshalb zwei Schritte: in POPcon die Umleitung an den Postmaster ausschalten und in Exchange die Ablehnung im SMTP-Protokoll abschalten, damit die Nachricht angenommen und mit einem Bericht beantwortet wird. Für die älteren Versionen nennt er die Stellen:

Exchange 2007 und 2010: Exchange-Verwaltungskonsole › Organisationskonfiguration › Antispam › Eigenschaften der Empfängerfilterung, Seite Blockierte Empfänger: den Haken bei „Nachrichten blockieren, die an Empfänger gesendet wurden, die es im Verzeichnis nicht gibt“ entfernen. Laut Artikel lehnt Exchange 2010 Mail an nicht existierende Empfänger standardmäßig im SMTP-Protokoll ab.
Exchange 2003 und 2000: Exchange-System-Manager › Globale Einstellungen › Nachrichtenübermittlung › Eigenschaften, Seite Empfängerfilterung: den Haken bei „Empfänger filtern die nicht im Verzeichnis vorhanden sind“ entfernen. Zusätzlich muss unter Globale Einstellungen › Internetnachrichtenformate auf der Registerkarte Erweitert „Unzustellbarkeitsberichte zulassen“ aktiviert sein (Artikel mit Bildern).

Exchange 2016, 2019 und SE. Bei diesen Versionen wird die Empfängerfilterung nur in der Exchange-Verwaltungsshell verwaltet, und Microsofts Dokumentation weist in die andere Richtung als die älteren Standardwerte. Der Parameter, mit dem der Agent Nachrichten an Empfänger blockiert, die in der Organisation nicht vorhanden sind, heißt RecipientValidationEnabled am Cmdlet Set-RecipientFilterConfig, und sein Standardwert ist $false. Für Postfachserver warnt Microsoft ausdrücklich: Der Empfängerfilter-Agent ist dort zwar verfügbar, sollte aber nicht konfiguriert werden, denn entdeckt die Empfängerfilterung auf einem Postfachserver einen ungültigen oder gesperrten Empfänger in einer Nachricht, die auch gültige Empfänger enthält, wird die ganze Nachricht zurückgewiesen. Der Agent wird aktiviert, wenn die Antispam-Agents auf einem Postfachserver installiert werden, ist dann aber nicht so konfiguriert, dass er Empfänger blockiert (Vorgehensweisen zur Empfängerfilterung). Auf einem Server, an dem das niemand geändert hat, nimmt Exchange die Nachricht an, und der Unzustellbarkeitsbericht folgt. Auf einem Server, der über Jahre migriert oder gehärtet wurde, lesen Sie den Zustand aus, bevor Sie ihn voraussetzen:

Get-RecipientFilterConfig | Format-List Enabled,RecipientValidationEnabled zeigt, ob der Filter eingeschaltet ist und ob er nicht vorhandene Empfänger blockiert (Microsofts eigene Prüfung ist derselbe Befehl nur mit Enabled).
Get-AcceptedDomain | Format-List Name,AddressBookEnabled zeigt die Einstellung je akzeptierter Domäne: Standardmäßig ist die Empfängerfilterung für autoritative Domänen aktiviert und für interne wie externe Relaydomänen deaktiviert.
Set-RecipientFilterConfig -RecipientValidationEnabled $false schaltet das Blockieren nicht vorhandener Empfänger wieder ab.

Microsofts Warnung zu Postfachservern hat hinter einem Connector eine praktische Seite: Eine aus dem Provider-Postfach abgeholte Nachricht kann mehrere Empfänger Ihrer Domäne tragen, und ein Tippfehler in einer dieser Adressen sollte die übrigen nicht um ihre Kopie bringen.

Zu große Nachrichten

Für die Größe gilt dieselbe Zweiteilung. Eine Nachricht, die der Empfangsconnector ablehnt, bleibt bei POPcon im Ordner TOOLARGE, und der Absender hört nichts. Soll er es erfahren, verlegt die Knowledge Base (Wie kann ich dem Absender eine Unzustellbarkeitsnachricht schicken wenn die Email zu groß ist?) die Entscheidung hinter den Empfangsconnector: Dessen Limit wird sehr hoch gesetzt, damit zu große Mails nicht schon dort abgelehnt werden, und die gewünschte Obergrenze wird als maximale Empfangsgröße der Organisation eingestellt. Exchange nimmt die Nachricht dann vom Connector an, stellt fest, dass sie zu groß ist, und sendet selbst eine korrekte Unzustellbarkeitsnachricht an den Absender. Die Limits, Microsofts Standardwerte und die Befehle stehen im Ratgeber Nachrichten über 10 MB kommen nicht an.

Abwesenheitsnotizen

Eine automatische Antwort ist kein Unzustellbarkeitsbericht, aber sie ist die dritte Nachricht, die Exchange von sich aus an externe Absender schickt, und sie nimmt denselben Weg. Die Knowledge Base ist bei der Zuständigkeit eindeutig: Abwesenheitsmeldungen zu versenden „ist ein Exchange Feature das von POPcon nicht beeinflusst wird“ (Artikel). Bei Exchange 2003 ist der Schalter „Abwesenheitsbenachrichtigungen zulassen“ auf der Registerkarte Erweitert des Standardeintrags unter Globale Einstellungen › Internetnachrichtenformate.

Bei späteren Versionen gehört die Einstellung zur Remotedomäne und wird mit Set-RemoteDomain geändert. Microsofts Cmdlet-Referenz führt drei Parameter auf, auf die es hier ankommt:

Parameter	Was er steuert	Standardwert laut Microsoft
`AllowedOOFType`	Den Typ der automatischen Antworten oder Abwesenheitsbenachrichtigungen (OOF), die an Empfänger in der Remotedomäne gesendet werden können; gültige Werte sind External, ExternalLegacy, InternalLegacy und None	External: Nur als extern gekennzeichnete automatische Antworten werden gesendet
`AutoReplyEnabled`	Automatische Antworten aus E-Mail-Clientprogrammen in Ihrer Organisation, zum Beispiel Antworten, die Regeln in Outlook erzeugen	`$false` für die integrierte Remotedomäne Default in lokalem Exchange
`NDREnabled`	Ob Unzustellbarkeitsberichte Ihrer Organisation an Empfänger in der Remotedomäne zugelassen sind	`$true`

Die aktuellen Werte lesen Sie mit Get-RemoteDomain | Format-List Name,DomainName,AllowedOOFType,AutoReplyEnabled,NDREnabled. Ist die externe Antwort eines Benutzers in Outlook eingerichtet und geht trotzdem nicht hinaus, wurde entweder AllowedOOFType irgendwann auf None oder InternalLegacy gestellt, oder die Antwort wird erzeugt und auf dem Weg nach außen aufgehalten – dazu der nächste Abschnitt.

Der Rückweg: leerer Absender und Ausgangsrelay

Unzustellbarkeitsberichte und automatische Antworten haben eines gemeinsam: Exchange schickt sie standardkonform ohne Absender im SMTP-Envelope, also mit leerem MAIL FROM. Sie verlassen Exchange über denselben Sendeconnector und denselben Smarthost wie jede andere Nachricht. Ist dieser Smarthost ein Provider-Postfach, gelten dessen Absenderregeln auch für sie.

IONOS ist der dokumentierte Fall. Seit Januar 2024 weisen die IONOS-Postausgangsserver eine Nachricht, deren Absender nicht in der Domain des Login-Postfachs liegt, und ebenso eine Nachricht ganz ohne Absender mit Sender address is not allowed ab; IONOS beschreibt die Änderung auf seiner Hilfeseite. Die Auswirkung auf Exchange steht in unserer Knowledge Base (Abwesenheitsnotizen und Unzustellbarkeitsnachrichten gehen bei IONOS SMTP Relay nicht raus, IONOS blockiert Unzustellbarkeitsberichte und Abwesenheitsnachrichten): Berichte und Notizen werden erzeugt und dann vom Provider blockiert, und das Verhalten lässt sich weder in Exchange noch in POPcon konfigurieren.

Die Lösung liegt auf der Relay-Seite. MultiSendcon, als ausgehendes Relay zwischen Exchange und Provider geschaltet, füllt den Absender in solchen Fällen automatisch: mit der Adresse aus dem Header der Nachricht, wenn dort eine steht, sonst mit dem in der Konfiguration eingestellten festen Absender. Der Provider nimmt die Nachricht dann an. Für ein einzelnes Provider-Login genügt die günstigere Lite-Version. Den Hintergrund und die Einrichtung für mehrere Domains hinter einem Provider beschreibt der Ratgeber IONOS, Strato oder GMX als Smarthost für Exchange.

Ein Relay im Ausgangsweg hat eine eigene Einstellung für Berichte. Die Registerkarte NDR Handling von MultiSendcon (Hilfeseite in englischer Sprache) legt fest, wie Unzustellbarkeitsberichte der Relayserver behandelt werden und wer sie erhält: der ursprüngliche Absender, eine festgelegte Postmaster-Adresse oder beide.

Postmaster oder Bericht: die Entscheidung je Fall

Anordnung	Was mit der Nachricht geschieht	Wer es erfährt	Einstellungen
Unbekannte Empfänger an den Postmaster umleiten	Wird dem Postmaster-Postfach zugestellt	Der Postmaster; der Absender nicht	POPcon: „Mail an unbekannte Empfänger umleiten an...“ ein, Postmaster eingetragen
Unzustellbarkeitsbericht für unbekannte Empfänger	Von Exchange angenommen und nicht zugestellt	Der Absender, durch den Bericht	POPcon: Umleitung aus. Exchange: kein Blockieren nicht vorhandener Empfänger; `NDREnabled` auf `$true`; das Ausgangsrelay akzeptiert den leeren Absender
Bericht für den Absender und Kopie für den Administrator	Wie oben	Beide	Wie oben, zusätzlich Microsofts `Set-TransportConfig -GenerateCopyOfDSNFor` mit den zu überwachenden Statuscodes und ein Postfach, das dem Exchange-Empfänger zugewiesen ist (Verfahren für DSNs und NDRs)
Zu große Mail bleibt für den Administrator liegen	Wartet als `.msg`-Datei in TOOLARGE	Wer in den Ordner oder ins Log sieht	Limit des Empfangsconnectors nicht höher als das Limit der Organisation
Zu große Mail geht an den Absender zurück	Von Exchange nach der Annahme abgewiesen	Der Absender, durch den Bericht	Limit des Empfangsconnectors hoch, Limit der Organisation auf der gewünschten Größe

Zur dritten Zeile gehört ein Hinweis von Microsofts Seite: Standardmäßig ist dem Exchange-Empfänger kein Postfach zugewiesen, sodass alle an ihn gesendeten Nachrichten verworfen werden. Ohne dieses Postfach gehen die Kopien ins Leere.

Wenn der Absender nichts hört: wo Sie nachsehen

Was Sie sehen	Ursache	Wo es beschrieben ist
Mail an falsch geschriebene Adressen landet im Postmaster-Postfach	POPcon leitet unbekannte Empfänger um	Knowledge Base
Mail an unbekannte Adressen bleibt in der POPcon-Warteschlange	Exchange lehnt den Empfänger in der SMTP-Sitzung ab	Knowledge Base, Optionen A und B
Große Nachrichten sammeln sich in TOOLARGE	Größenlimit des Empfangsconnectors	Ratgeber Größenlimits
Exchange erzeugt Berichte und Abwesenheitsnotizen, externe Absender erhalten sie nie, der Provider antwortet Sender address is not allowed	Der Provider weist den leeren Absender ab	Ratgeber Provider-Smarthost
Abwesenheitsnotizen erreichen nur interne Benutzer	Einstellungen der Remotedomäne	Abschnitt oben; Knowledge Base

Die Antwort, die Exchange dem Connector gegeben hat, steht im Log von POPcon, der Datei POPconSrv.log im Programmverzeichnis; die Codes erklärt die Übersicht der Exchange-SMTP-Fehlercodes.

Häufige Fragen

Kann der POP3-Connector die Unzustellbarkeitsnachricht selbst verschicken?

POPcon kann das nicht. Die Knowledge Base nennt den Grund: Um etwas zurück ins Internet zu senden, müsste POPcon die Zugangsdaten zum SMTP-Relayserver (Smarthost) Ihres Providers kennen. Unzustellbarkeitsnachrichten sind eine Funktion von Exchange. Aufgabe des Connectors ist es, die Nachricht so an Exchange zu übergeben, dass Exchange den Bericht erzeugen kann.

Warum landet Mail an eine falsch geschriebene Adresse beim Postmaster statt zurückzugehen?

Weil in POPcon die Funktion „Mail an unbekannte Empfänger umleiten an...“ eingeschaltet ist. Dann geht Mail für eine Adresse, die in Exchange nicht existiert, an den dort eingetragenen Postmaster oder Administrator. Die Nachricht ist nicht verloren, aber der Absender erfährt nichts. Soll stattdessen eine Unzustellbarkeitsnachricht hinausgehen, schalten Sie die Umleitung aus und lassen Exchange die Nachricht annehmen und beantworten.

Mail an unbekannte Adressen bleibt in der Warteschlange des Connectors hängen. Woran liegt das?

Exchange lehnt den Empfänger schon in der SMTP-Sitzung ab, statt die Nachricht anzunehmen. Microsoft dokumentiert die Antwort des Empfängerfilter-Agents als 550 5.1.1 User unknown. Eine Ablehnung an dieser Stelle erreicht nur den Connector; er kann die Nachricht nicht zustellen und behält sie in der Warteschlange. Entweder schalten Sie in Exchange das Blockieren nicht vorhandener Empfänger ab, damit Exchange die Nachricht annimmt und den Bericht erzeugt, oder Sie lassen POPcon unbekannte Empfänger an den Postmaster umleiten.

Exchange erzeugt den Bericht, aber der externe Absender bekommt ihn nie. Warum?

Eine Unzustellbarkeitsnachricht verlässt Exchange mit leerem Envelope-Absender und nimmt denselben Weg wie alle andere ausgehende Mail. Ist der Smarthost ein IONOS-Postfach, wird sie dort abgewiesen: IONOS lehnt Nachrichten ohne Absender seit Januar 2024 mit „Sender address is not allowed“ ab. In Exchange lässt sich das nicht ändern. Ein Relay zwischen Exchange und Provider, das eine Absenderadresse einsetzt, etwa MultiSendcon, macht den Bericht zustellbar. Prüfen Sie außerdem, ob NDREnabled an der Remotedomäne noch auf $true steht.

Sind Abwesenheitsnotizen an externe Absender eine Einstellung des Connectors?

Nein. Abwesenheitsmeldungen sind eine Exchange-Funktion, die von POPcon nicht beeinflusst wird; eingestellt werden sie an der Remotedomäne. Microsoft nennt External als Standardwert des Parameters AllowedOOFType und für lokales Exchange $false als Standardwert von AutoReplyEnabled an der integrierten Remotedomäne Default, was automatische Antworten aus Outlook-Regeln betrifft. Wie Unzustellbarkeitsnachrichten haben die Notizen einen leeren Envelope-Absender und brauchen ein Relay, das ihn akzeptiert.

Mehr in den Exchange-Ratgebern, auf den Produktseiten POPcon und MultiSendcon, der POPcon-Download-Seite und der MultiSendcon-Download-Seite oder in der Knowledge Base. In English: NDRs for external senders behind a POP3 connector.