Automatisierte Workflows scheitern leise: Kontaktdaten als schwächste Stelle

Der stille Fehlerfall: „erfolgreich versendet“ ist kein Zustellnachweis

Sobald ein Automatisierungsschritt eine Nachricht an den Mailserver übergibt und von dort ein positiver Antwortcode zurückkommt, gilt der Schritt im Log als erledigt. Genau an dieser Stelle reißt die Kette. Der Code 250 bestätigt, dass der annehmende Server die Verantwortung für die weitere Behandlung übernommen hat, mehr nicht. RFC 5321 formuliert es in Abschnitt 2.1 so: Der Server muss die Nachricht entweder zustellen oder das Scheitern ordentlich melden. Beide Wege sind zulässig, und beide sehen für den aufrufenden Prozess im Moment der Übergabe identisch aus.

Die Meldung des Scheiterns kommt später und über einen anderen Kanal. Stellt der Server fest, dass die Zieladresse nicht existiert oder das Postfach die Nachricht ablehnt, erzeugt er nach Abschnitt 3.6.3 eine Unzustellbarkeitsnachricht und schickt sie an den Reverse-Path, also an die Absenderadresse im Envelope. Diese Nachricht landet in einem Postfach. Sie landet nicht im Workflow. Zwischen Übergabe und Eintreffen des Bounce vergehen Sekunden, bei verzögerten Zustellversuchen mehrere Tage.

Damit arbeitet der Prozess mit zwei Zuständen, die er nicht auseinanderhalten kann: versendet und zugestellt. Sein Log kennt nur den ersten. Ein Monitoring, das auf die Fehlerrate von Tasks schaut, zeigt eine saubere Kurve, während ein Teil der Nachrichten nirgends ankommt. Eine Vorabfrage im Protokoll selbst hilft dabei kaum, weil die dafür vorgesehenen Kommandos VRFY und EXPN auf den meisten Servern aus Sicherheitsgründen abgeschaltet sind. RFC 5321 sieht diese Abschaltung in Abschnitt 7.3 ausdrücklich vor. Wer den Zustand eines Empfängers kennen will, muss die E-Mail-Adresse also außerhalb des Sendevorgangs prüfen.

Wo Kontaktdaten in einer Prozesskette altern

Kontaktdaten altern nicht gleichmäßig, sondern an wenigen, gut benennbaren Stellen. Im Onboarding entstehen persönliche Adressen, die mit dem Austritt eines Mitarbeiters wertlos werden, oft ohne dass ein Prozess davon erfährt. Der Lieferantenstamm trägt Ansprechpartner, die seit Jahren nicht mehr im Unternehmen sind, während die Sammeladresse daneben weiterhin funktioniert und deshalb keinen Verdacht erzeugt. Der Bewerbungseingang sammelt private Adressen mit kurzer Lebensdauer, teilweise Wegwerfadressen. Im Ticketsystem schließlich landen Adressen aus Freitextfeldern, mit Tippfehlern in der Domain, die kein Formular abgefangen hat.

Wie schnell das geht, lässt sich für den deutschen Arbeitsmarkt beziffern. Nach den Zahlen des Statistischen Bundesamts zur Dauer der Beschäftigung beim aktuellen Arbeitgeber gaben 2025 mehr als ein Drittel der befragten Erwerbstätigen (38,6 Prozent) eine Beschäftigungsdauer von weniger als fünf Jahren an, 20,1 Prozent waren fünf bis zehn Jahre am selben Arbeitsplatz (Stand: 23. Juli 2026). Ein Lieferantenkontakt, der vor vier Jahren erfasst wurde, hat damit eine spürbare Wahrscheinlichkeit, ins Leere zu zeigen.

Eine belastbare Quote für den Zerfall von Kontaktdaten lässt sich daraus nicht ableiten, weil jeder Bestand seiner eigenen Fluktuation folgt. Die Richtung ist trotzdem eindeutig: Ein Datenbestand, der zwei Jahre lang nicht angefasst wurde, enthält Adressen, die kein Postfach mehr erreichen, und nichts im Datensatz selbst zeigt das an.

Was ein ins Leere laufender Schritt kostet

Auf 12,9 Millionen US-Dollar pro Organisation und Jahr beziffert Gartner die durchschnittlichen Kosten schlechter Datenqualität (2021). Diese Summe bleibt abstrakt, solange sie nicht auf einzelne Prozessschritte heruntergebrochen wird. Der Rechenweg ist im Einzelfall simpler, als die Zahl vermuten lässt.

Ein Freigabeschritt, dessen Benachrichtigung nicht ankommt, blockiert den gesamten Vorgang dahinter. Die Uhr für interne Reaktionszeiten läuft trotzdem weiter, weil das System die Aufgabe als zugestellt führt. Nach Ablauf der Frist eskaliert der Vorgang, jemand sucht die Ursache, findet einen Empfänger, der das Unternehmen vor acht Monaten verlassen hat, und stößt den Schritt manuell erneut an. Bezahlt wird dieser Ablauf zweimal: in Bearbeitungszeit und in Durchlaufzeit. Bei Rechnungs- oder Mahnläufen kommt ein direkter Zahlungsverzug dazu.

Der zweite Kostenblock ist regulatorisch. Artikel 5 Absatz 1 Buchstabe d DSGVO verlangt, dass personenbezogene Daten sachlich richtig und erforderlichenfalls auf dem neuesten Stand sind, und dass unrichtige Daten unverzüglich gelöscht oder berichtigt werden. Ein Adressbestand, der seit Jahren ungeprüft mitgeschleppt wird, erfüllt diese Anforderung schlecht. Der Aufwand für die Korrektur wächst dabei mit jedem Monat, den der Bestand unbeobachtet bleibt.

Zur Einordnung im deutschen Markt: Bitkom hat 2024 unter 603 Unternehmen ab 20 Beschäftigten erhoben, dass nur 6 Prozent das Potenzial ihrer verfügbaren Daten nach eigener Einschätzung vollständig ausschöpfen. Zwei Jahre zuvor nannten 42 Prozent der befragten Industrieunternehmen die mangelnde Datengrundlage als größtes Hemmnis beim KI-Einsatz. Automatisierung verschärft das Problem, weil sie die fehlerhafte Adresse nicht einmal, sondern in jedem Durchlauf verwendet.

Prüfung als Kontrollpunkt statt als Aufräumaktion

Statt einer jährlichen Bereinigung, die einen Bestand kurz auf Stand bringt und ihn danach wieder altern lässt, gehören zwei feste Kontrollpunkte in den Ablauf. Sie haben unterschiedliche Aufgaben und lassen sich nicht gegeneinander eintauschen.

Der erste sitzt bei der Erfassung, im Formular oder in der Schnittstelle, die den Datensatz anlegt. Er beantwortet die Frage, ob die eingegebene Adresse überhaupt Aussicht hat zu funktionieren: Schreibweise, existierende Domain, hinterlegter MX-Eintrag, bekannte Wegwerfdomain. Der Vorteil dieser Position liegt im Zeitpunkt. Der Nutzer sitzt noch vor dem Formular und kann den Tippfehler in der Domain selbst korrigieren. Jede Korrektur, die hier ausbleibt, kostet später ein Ticket.

Der zweite Kontrollpunkt sitzt unmittelbar vor dem Versand, insbesondere vor Schritten, die selten laufen und deren Empfängerliste aus dem Bestand kommt. Erfassung und Versand liegen bei Freigaben, Jahresmeldungen oder Vertragsverlängerungen häufig Jahre auseinander. Der Bestand kann bei der Anlage sauber gewesen sein und trotzdem heute falsch sein. Eine Prüfung an dieser Stelle betrifft nur die Adressen, die tatsächlich angeschrieben werden, und bleibt damit im Volumen überschaubar.

Den Zustand speichern statt eines Ja-Nein-Werts

Speichert ein System nur ein Häkchen „geprüft“, geht die halbe Information verloren. Ein boolescher Wert kennt kein Alter. Er kann nicht sagen, ob die Prüfung von gestern oder von 2021 stammt, und er zwingt jeden nachgelagerten Prozess dazu, dieselbe Annahme über Gültigkeit zu treffen.

Ein brauchbares Datenmodell hält drei Felder: den Status, den Zeitstempel der letzten Prüfung und die Herkunft des Ergebnisses. Der Status sollte mehr als zwei Werte kennen. Neben gültig und ungültig braucht es mindestens einen dritten Wert für Fälle, in denen die Zielinfrastruktur keine belastbare Antwort liefert, etwa bei Catch-All-Domains, die jede Adresse annehmen und erst später verwerfen. Wer solche Fälle als gültig ablegt, baut sich eine Fehlerquelle ein, die sich später nicht mehr von echten Treffern trennen lässt.

Mit Status und Zeitstempel kann jeder Prozess seine eigene Gültigkeitsdauer festlegen, ohne dass eine zentrale Regel alle Fälle gleich behandelt. Ein interner Freigabeschritt an einen aktiven Mitarbeiter verträgt eine lange Frist, weil ein Austritt ohnehin über das Verzeichnis gemeldet wird. Eine externe Ansprechpartneradresse im Lieferantenstamm verträgt deutlich weniger. Ein Bestand, der ein Jahr lang unbenutzt lag, wird vor dem nächsten Versand ohnehin neu angesehen. Die Regel steht damit dort, wo das fachliche Wissen sitzt, und nicht in einer globalen Einstellung.

Was sich mit Bordmitteln prüfen lässt und wo eine externe Kontrolle nötig wird

Technisch lässt sich ein guter Teil der Arbeit ohne fremde Hilfe erledigen. Die Syntax einer Adresse folgt der Grammatik aus RFC 5321 und lässt sich lokal validieren. Ob die Domain existiert und einen MX-Eintrag hat, beantwortet eine DNS-Abfrage in wenigen Millisekunden. Eine gepflegte Liste bekannter Wegwerfdomains und eine kurze Tabelle häufiger Vertipper bei großen Freemail-Anbietern fangen einen weiteren Teil ab. Diese drei Schritte kosten wenig Rechenzeit und gehören in jede Erfassungsmaske.

Die eigentliche Frage bleibt danach offen: Ob hinter einer korrekt geschriebenen Adresse mit gültiger Domain noch ein Postfach steht, das Nachrichten annimmt. Diese Antwort liefert nur ein Dialog mit dem Zielserver, und der ist heikel. Greylisting, Rate Limits und die Reputation der anfragenden IP-Adresse entscheiden mit darüber, ob die Antwort überhaupt aussagekräftig ist. Ein Server, den eine unbekannte IP-Adresse in kurzer Folge nach vielen Empfängern fragt, antwortet ausweichend oder blockt. Wer diese Kontrolle im eigenen Rechenzentrum aufbaut, riskiert außerdem, dass die eigene sendende IP-Adresse auf Blocklisten landet und die Zustellbarkeit der produktiven Mails darunter leidet. Wer eine E-Mail-Adresse an dieser Stelle belastbar prüfen will, braucht also fremde Infrastruktur mit sauberer Reputation.

Für den Einzelfall reicht ein Tool zum Prüfen von E-Mail-Adressen, das Syntax, Domain und Postfach in einem Durchgang kontrolliert. Für den laufenden Betrieb gehört dieselbe Kontrolle als API-Aufruf an die beiden oben beschriebenen Stellen im Workflow, mit dem Ergebnis als Status und Zeitstempel im Datensatz.

Was eine solche Prüfung liefert, ist eng umrissen und sollte auch so kommuniziert werden: Sie sagt, ob das Postfach hinter einer E-Mail-Adresse Nachrichten entgegennimmt. Sie sagt nicht, ob jemand sie liest, ob der Empfänger noch zuständig ist oder ob die Nachricht im Spam-Ordner landet. Für die Zustellbarkeit genügt das trotzdem, weil ein großer Teil der harten Bounces auf Postfächer zurückgeht, die es nicht mehr gibt. Wer die Empfängerliste vor dem Versand prüfen lässt und die toten Einträge aussortiert, senkt die Bounce-Rate, schont die Reputation der eigenen Absenderdomain und nimmt den automatisierten Prozessen die Möglichkeit, monatelang Erfolg zu melden, wo nichts angekommen ist.

Der Aufwand dafür ist überschaubar. Zwei Kontrollpunkte, drei Felder im Datenmodell, eine Gültigkeitsdauer je Prozess. Das ist weniger Arbeit als die Suche nach der Ursache, wenn ein Vorgang nach sechs Wochen auffällt, weil ein Kunde nachfragt.

Bildquelle: OpenAI