Fehler „Server Returned 400 4.4.7 Message Delayed“ in Exchange Server beheben

Bleibt eine E-Mail im Exchange Server hängen und der Absender erhält einen Non-Delivery Report (NDR) mit dem Hinweis „Server Returned 400 4.4.7 Message Delayed“, handelt es sich um eines der häufigsten Zustellprobleme in lokalen Exchange-Umgebungen. Der Fehler tritt vor allem auf, wenn eine oder mehrere Nachrichten an externe Empfänger unterwegs sind. Die gute Nachricht: Meist handelt es sich um ein vorübergehendes Problem, das sich mit wenigen gezielten Prüfungen eingrenzen und beheben lässt. Dieser Beitrag erklärt, was der Fehlercode bedeutet, welche Ursachen typischerweise dahinterstecken und wie Sie das Problem in Exchange Server Schritt für Schritt lösen.

Was bedeutet der Fehler „400 4.4.7 Message Delayed“?

Nach dem Versand einer E-Mail an einen externen Empfänger erscheint zunächst eine NDR-Meldung mit etwa folgendem Wortlaut:

Die Zustellung wird bei folgenden Empfängern oder Gruppen verzögert:

<Empfänger> (<Empfänger-E-Mail-Adresse>)

Betreff: <E-Mail-Betreff>

Diese Nachricht wurde noch nicht zugestellt. Es werden weiterhin Zustellversuche unternommen.

Der Server versucht, diese Nachricht in den nächsten 1 Tag, 19 Stunden und 57 Minuten zuzustellen.

Sie werden benachrichtigt, falls die Zustellung in dieser Zeit nicht gelingt.

Im Diagnoseteil der Meldung steht anschließend die eigentliche Fehlerursache, meist in dieser Form:

Remote-Server meldete: „400 4.4.7 Message delayed“

Um den Code richtig einzuordnen, lohnt sich ein Blick auf seinen Aufbau. Erweiterte SMTP-Statuscodes folgen laut RFC 3463 dem Schema Klasse.Thema.Detail. Die führende Ziffer 4 (wie in 4.4.7) kennzeichnet einen vorübergehenden Fehler – im Unterschied zur 5, die einen endgültigen Zustellfehler markiert. Der Teilcode „.7“ steht für „Delivery time expired“: Die Nachricht befindet sich noch in der Warteschlange, hat aber das konfigurierte Zeitfenster für einen erfolgreichen Zustellversuch überschritten. Die vorangestellte „400“ ist streng genommen kein von RFC 5321 definierter dreistelliger SMTP-Antwortcode – gültige temporäre Codes wären dort etwa 421, 450, 451 oder 452. In der Exchange-Warteschlangenanzeige und in Verzögerungsmeldungen taucht „400 4.4.7“ trotzdem regelmäßig auf: Es zeigt an, dass eine Nachricht weiterhin aktiv zugestellt werden soll und noch nicht endgültig gescheitert ist.

Kurz gefasst bedeutet der Fehler also zunächst nur: Exchange konnte die Nachricht bislang nicht zustellen und versucht es weiter – meist wegen eines Protokoll-Timeouts oder eines erreichten Grenzwerts, etwa bei der Anzahl der Kopfzeilen-Hops. Ob daraus ein dauerhaftes Problem wird, hängt von der zugrunde liegenden Ursache ab. Ein typischer Auszug aus den Original-Kopfzeilen einer solchen Nachricht sieht so aus:

Empfangen: von srv01.meinunternehmen.lan (192.168.x.x) durch

mail.meinunternehmen.lan (192.168.x.x) mit Microsoft SMTP Server

(TLS); Mi, 12 Aug 2026 09:15:00 +0200

Empfangen: von srv01.meinunternehmen.lan ([IPv6-Adresse]) durch

srv01.meinunternehmen.lan ([IPv6-Adresse]) mit MAPI id

12.11.353.010; Mi, 12 Aug 2026 09:15:00 +0200

Von: <Absender> <Absender-E-Mail-Adresse>

An: <Empfänger> <Empfänger-E-Mail-Adresse>

Mögliche Ursachen für den Fehler 400 4.4.7

Da der Fehler unmittelbar mit der Zustellung zusammenhängt, kommen mehrere Ursachen infrage:

• DNS-Probleme bei der Zieldomäne – insbesondere fehlerhafte oder nicht auflösbare MX- oder SPF-Einträge
• Eingeschränkte Serverleistung: hohe Auslastung bei I/O, Netzwerkdurchsatz oder CPU, wodurch die Warteschlange nicht schnell genug abgearbeitet wird
• Fehlerhafte Hardware oder Konflikte mit Drittanbieter-Software wie Virenscannern oder Backup-Agenten, die den Transportdienst ausbremsen
• Eine durch Massenversand überlastete Warteschlange, etwa bei sehr vielen Empfängern oder großen Anhängen in kurzer Zeit
• Der Back-Pressure-Schutz von Exchange: Bei zu wenig freiem Festplatten- oder Arbeitsspeicher drosselt der Server bewusst die Verarbeitung ein- und ausgehender Nachrichten, um sich selbst zu schützen
• Falsch konfigurierte Sende- oder Empfangs-Connectors
• Firewall- oder Antiviren-Software, die ausgehende SMTP-Verbindungen blockiert oder verzögert
• Fehlende Schattenserver für die Shadow Redundancy bei internen Zustellproblemen (siehe Schritt 4)

So diagnostizieren und beheben Sie den Fehler Schritt für Schritt

Grenzen Sie zunächst ein, ob das Problem ein einzelnes Postfach, eine bestimmte externe Domain oder den gesamten Server betrifft. Die folgenden Schritte führen systematisch durch die Diagnose.

Schritt 1: MX-Eintrag der Zieldomäne mit nslookup prüfen

Prüfen Sie, ob der lokale Exchange Server den MX-Eintrag der Empfängerdomain überhaupt auflösen kann:

• Öffnen Sie die Eingabeaufforderung als Administrator auf dem Server, auf dem Exchange läuft.
• Geben Sie nslookup ein und bestätigen Sie mit der Eingabetaste.

• Geben Sie anschließend set type=mx ein und bestätigen Sie erneut.

• Geben Sie den Domainnamen des Empfängers ein und drücken Sie die Eingabetaste.

Das Ergebnis zeigt die für die Domain hinterlegten MX-Einträge. Erscheint stattdessen eine Meldung wie „<Domain> kann nicht gefunden werden: Non-existent domain“, lässt sich der MX-Eintrag nicht auflösen – ein Hinweis auf ein Problem mit dem lokalen DNS, dem weiterleitenden DNS-Server oder dem DNS-Dienst der Zieldomain. Testen Sie in diesem Fall testweise den Versand von einer anderen externen Quelle an denselben Empfänger, um die Fehlerquelle weiter einzugrenzen.

Schritt 2: Warteschlange prüfen

Öffnen Sie die Verwaltungskonsole der Exchange Toolbox und klicken Sie auf Warteschlangenanzeige (Queue Viewer). Dort sehen Sie, wie viele eingehende und ausgehende Nachrichten aktuell verarbeitet werden und ob sich Nachrichten für eine bestimmte Domain stauen. Alternativ liefert das Cmdlet Get-Queue in der Exchange Management Shell dieselben Informationen direkt im Terminal.

Schritt 3: Serverressourcen und Back Pressure prüfen

Kontrollieren Sie mit Ressourcenmonitor und Ereignisanzeige, ob Arbeitsspeicher, freier Festplattenspeicher oder CPU-Auslastung auffällig sind. Bei knappen Ressourcen aktiviert Exchange automatisch den Back-Pressure-Schutz und drosselt bewusst die Verarbeitung von Nachrichten – erkennbar an entsprechenden Warnungen der Quelle MSExchangeTransport in der Ereignisanzeige. Meist genügt es, ausreichend Festplattenspeicher auf dem Laufwerk mit der Transport-Datenbank freizugeben, damit die Verarbeitung wieder normal läuft.

Schritt 4: Message Tracking Log auswerten

Führen Sie in der Exchange Management Shell den Befehl Get-MessageTrackingLog aus, um den Weg der betroffenen Nachricht nachzuvollziehen. Erscheint dabei ein Eintrag wie der folgende:

ServerHostname : MailServer

SourceContext  : No suitable shadow servers

ConnectorId    : <id>

Source         : SMTP

EventId        : HAREDIRECTFAIL

…deutet das auf ein Problem mit der Shadow Redundancy hin – allerdings mit einer wichtigen Einschränkung: Betreiben Sie einen einzelnen, eigenständigen Exchange-Server ohne Database Availability Group (DAG), ist HAREDIRECTFAIL mit der Ursache „No suitable shadow servers“ ein erwartetes und in der Regel unbedenkliches Verhalten, da schlicht kein zweiter Server für eine Schattenkopie zur Verfügung steht. In diesem Fall ist es meist nicht die eigentliche Ursache für 400-4.4.7-Fehler beim Versand an externe Empfänger. Relevant wird der Eintrag vor allem dann, wenn er gehäuft auftritt und tatsächlich mit hängenden internen Nachrichten zusammenfällt.

Schritt 5: Shadow Redundancy deaktivieren (nur bei eigenständigem Server)

Steht Schritt 4 in einem eigenständigen Setup nachweislich im Zusammenhang mit echten Zustellproblemen, können Sie die Shadow Redundancy in der Exchange Management Shell (EMS) deaktivieren:

Set-TransportConfig -ShadowRedundancyEnabled $False

Starten Sie anschließend den Transportdienst neu, damit die Änderung wirksam wird:

net stop MSExchangeTransport && net start MSExchangeTransport

Prüfen Sie danach, ob die betroffenen Nachrichten zugestellt werden.

Schritt 6: Transport-Warteschlange neu aufbauen (letztes Mittel)

Hilft keiner der vorherigen Schritte und die Warteschlange bleibt dauerhaft blockiert, können Sie die Transport-Warteschlangendatenbank neu aufbauen: Transportdienst stoppen, den Ordner Queue im Installationsverzeichnis (standardmäßig unter …\TransportRoles\data\Queue) umbenennen, etwa in Queue.old, und den Transportdienst anschließend neu starten. Exchange legt danach automatisch eine neue, leere Warteschlangendatenbank an.

Wichtig: Dabei gehen alle zu diesem Zeitpunkt in der Warteschlange befindlichen Nachrichten verloren. Nutzen Sie diesen Schritt daher nur als letztes Mittel und informieren Sie betroffene Absender gegebenenfalls darüber, dass sie wichtige E-Mails erneut versenden müssen.

Wenn der Fehler auf einem Serverproblem beruht: Datenwiederherstellung

Lässt sich der Fehler auf keine der oben genannten Ursachen zurückführen, kann ein tieferliegendes Problem mit dem Exchange-Server selbst vorliegen. In solchen Fällen bleibt manchmal nur die Neuinstallation des Servers oder die Einrichtung eines neuen Servers übrig. Technisch ist das meist unkompliziert – die eigentliche Herausforderung liegt in der verlustfreien Wiederherstellung der vorhandenen Postfachdaten auf dem neuen System. Hierfür eignen sich spezialisierte Tools zur EDB-Wiederherstellung, etwa Stellar Converter for EDB: Die Software liest Datenbankdateien (EDB) auch von einem nicht mehr laufenden Server, öffnet Offline-Datenbanken ohne Größenbeschränkung und exportiert Postfächer, freigegebene Postfächer, deaktivierte Postfächer, Archive und öffentliche Ordner granular nach PST oder in andere Formate – bei laufendem Betrieb und ohne die Originaldaten zu verändern.

Fazit

Der Fehler „Server Returned 400 4.4.7 Message Delayed“ ist zunächst kein Grund zur Sorge: Er zeigt lediglich an, dass eine Nachricht ihre vorgesehene Zustellzeit überschritten hat und Exchange weiterhin versucht, sie auszuliefern. In den meisten Fällen genügt eine systematische Prüfung von DNS- und MX-Einträgen, Warteschlange, Serverressourcen und Message Tracking Log, um die Ursache einzugrenzen und zu beheben. Bleibt das Problem trotz aller Maßnahmen bestehen oder deutet es auf einen tieferliegenden Serverfehler hin, sind eine Neuinstallation und eine gezielte, verlustfreie Wiederherstellung der Postfachdaten der sicherste Weg nach vorn.

FAQs