presseportale/dev/2026-09-11-audit/kontakterreichbarkeit-mx-bounces-2026-09-15.md

Kontakterreichbarkeit: DNS-/MX-Prüfung, Bounces und Veröffentlichung

Stand: 15.09.2026

Status: Entwicklungsgrundlage aus der besprochenen Empfehlung. Dieses Dokument beschreibt den vorhandenen Code und das vorgeschlagene Zielverhalten. Die Erweiterung ist noch nicht implementiert; konkrete neue Feldnamen, API-Felder und Betriebsparameter sind Umsetzungsvorschläge.

Prüfumfang: Lesender Codeabgleich im Arbeitsverzeichnis und Gegenprüfung der Mailstandards. Die produktive Konfiguration, tatsächlich laufende Jobs und konkrete Rückläufer wurden nicht geprüft.

1. Ziel und fachliche Leitlinie

Über die API werden Pressemitteilungen mit einer Firma und gegebenenfalls Pressekontakten angelegt. Bei Veröffentlichung oder Ablehnung werden Benachrichtigungen versendet. Ungültige Adressen verursachen Bounces und erschweren journalistische Rückfragen.

Die Kontaktdaten sollen bereits beim Einreichen technisch geprüft werden. Dabei gelten folgende Grundsätze:

• Eine DNS-/MX-Prüfung erkennt Probleme der E-Mail-Domain frühzeitig.
• Ein positiver DNS-Befund bestätigt weder das einzelne Postfach noch die Identität oder Verantwortlichkeit des Kontakts.
• Bounce-Verarbeitung und Versandsperren bleiben erforderlich.
• Ein einzelner Zustellfehler führt nicht automatisch zur Ablehnung oder Depublikation einer Pressemitteilung.
• Sind sämtliche relevanten Kontaktadressen nachweislich unzustellbar, werden neue automatische Veröffentlichungen zur Kontaktkorrektur oder manuellen Prüfung zurückgehalten.
• Die inhaltliche Prüfung bleibt eigenständig: Gute Kontaktdaten ersetzen keine Inhaltsprüfung, schlechte Kontaktdaten sind kein Beweis für falsche Inhalte.

2. Vorhandener Stand im Code

Baustein	Vorhandenes Verhalten	Bedeutung für die Erweiterung
EmailSuppressionService	Speichert Bounce-Ereignisse und adressbezogene Versandsperren; Hard Bounce sperrt sofort, Soft Bounces standardmäßig ab drei Ereignissen in sieben Tagen	Weiterverwenden; keine zweite unabhängige Bounce-Sperrliste aufbauen
GateOutgoingMail	Entfernt gesperrte Empfänger unmittelbar vor dem Versand; berücksichtigt eine globale Versandpause	Auch bereits wartende Nachrichten müssen weiterhin gegen aktuelle Sperren geprüft werden
PressReleaseService::notifyAuthor()	Bei API-Einreichungen Auswahl eines Pressekontakts, danach Firmenadresse; bei fehlenden oder gesperrten Adressen keine Nachricht	Kontaktprüfung und Empfängerauswahl aufeinander abstimmen
PressReleaseService::publish()	Veröffentlichung und anschließende Benachrichtigung; bisher keine davon abgeleitete Kontaktfreigabe	Zentraler Ansatzpunkt für die neue Veröffentlichungsprüfung
BounceMailProcessor	Verarbeitet Rückläufer aus dem Postfach und unterscheidet Hard/Soft	Ursachen müssen vor einer fachlichen Sperrentscheidung genauer unterschieden werden
Scheduler	Bounce-Abholung alle zehn Minuten vorgesehen	Produktive Postfachkonfiguration und Ausführung bei Einführung separat verifizieren

Codebelege: Versandsperren, Versandprüfung, Pressemitteilungsservice, Bounce-Verarbeitung, Konfiguration, Scheduler.

Bestehende Grenzen

1. Policy-Fehler können Adresssperren auslösen. Der DSN-Prozessor behandelt unter anderem 5.7.x als Soft Bounce. Wiederholte Spamfilter-, Authentifizierungs- oder Policy-Ablehnungen können dadurch den Soft-Bounce-Schwellwert erreichen. Eine solche Sperre beweist kein ungültiges Postfach.
2. Die aktuelle Kontaktwahl prüft nicht alle Alternativen. Zuerst wird der erste Pressekontakt mit E-Mail nach ID ausgewählt und anschließend dessen Sperre geprüft. Ist dieser gesperrt, folgt die Firmenadresse; ein weiterer geeigneter Pressekontakt wird dabei nicht gesucht.
3. Ein späterer Bounce löst keine automatische Ersatzbenachrichtigung aus. Die Empfängerauswahl berücksichtigt die zum Auswahlzeitpunkt bekannten Sperren. Ein nachträglicher Rückläufer ist ein eigener Vorgang.

Diese Grenzen bei der Erweiterung berücksichtigen. Insbesondere darf die vorhandene Versandsperre nicht unverändert als Nachweis fehlender Kontakterreichbarkeit verwendet werden.

3. Was die DNS-/MX-Prüfung leisten soll

Für presse@firma.example wird die Domain firma.example geprüft. Ein MX-Eintrag nennt einen für die Domain vorgesehenen Mailserver. Zusätzlich muss dessen Hostname zu einer nutzbaren IP-Adresse auflösbar sein.

Zu unterscheidende Ergebnisse

Befund	Einordnung	Folge
Nutzbarer MX vorhanden	Mailrouting im DNS vorhanden	DNS-Prüfung bestanden; Postfach bleibt unbestätigt
Kein MX, aber A-/AAAA-Eintrag der Domain	Impliziter MX als zulässiger Fallback	Als möglichen Zustellweg berücksichtigen; keine Ablehnung allein wegen fehlendem MX
Domain existiert nicht (NXDOMAIN)	Domain zum Prüfzeitpunkt nicht vorhanden	Adresse technisch unzustellbar, bis neue Daten oder eine erneute Prüfung das Gegenteil ergeben
Gültiger Null MX (MX 0 .)	Domain erklärt ausdrücklich, keine E-Mails anzunehmen	Keine Nachricht versenden; Kontaktkorrektur erforderlich
Kein MX und kein A/AAAA bei erfolgreicher DNS-Abfrage	Kein Zustellweg im DNS vorhanden	Kontaktkorrektur erforderlich
MX vorhanden, sämtliche Ziele nachweislich nicht auflösbar	Fehlerhafte Mailkonfiguration	Technisches Kontaktproblem; bei mehreren Zielen alle berücksichtigen
Timeout, SERVFAIL oder anderer vorübergehender Resolverfehler	Ergebnis unbekannt	Erneut prüfen; nicht als ungültige Adresse oder Bounce zählen
Widersprüchliche oder nicht sicher auswertbare DNS-Antwort	Ergebnis unklar	Erneute oder manuelle Prüfung; keine Vermutung als gesicherten Befund speichern

Der A-/AAAA-Fallback gilt bei fehlenden MX-Einträgen. Ein vorhandener, aber defekter MX wird nicht durch beliebiges Zurückfallen auf die Webserver-IP umgangen. Null MX wird ebenfalls nicht durch einen vorhandenen A-Eintrag aufgehoben. Grundlage: RFC 5321, Abschnitt 5.1, RFC 7505.

Grenzen

• presse@firma.example und nichtvorhanden@firma.example können dasselbe positive DNS-Ergebnis haben.
• Ein DNS-Eintrag belegt keine aktuelle Annahmebereitschaft des Mailservers.
• Keine Bounces gesehen zu haben bedeutet nicht, dass das Postfach bestätigt wurde.
• Für diese Ausbaustufe sind keine SMTP-Probeanmeldungen und keine zusätzlichen Testmails vorgesehen.
• Eine erfolgreiche DNS-Prüfung hebt niemals eine bekannte Postfachsperre auf.

4. Drei getrennte Bewertungen

Die Umsetzung benötigt getrennte Informationen für unterschiedliche Entscheidungen:

1. Domainprüfung: Ist ein Zustellweg im DNS vorhanden, fehlt er nachweislich oder ist das Ergebnis offen?
2. Adressbezogener Versandstatus: Darf diese konkrete E-Mail-Adresse angeschrieben werden? Ursache einer Sperre erhalten, beispielsweise ungültiges Postfach, wiederholte temporäre Fehler, Policyproblem, manuelle Sperre oder Abbestellung.
3. Kontaktfreigabe der Pressemitteilung: Darf die Mitteilung den automatischen Veröffentlichungsprozess fortsetzen, wartet sie auf Prüfung oder benötigt sie eine Korrektur/manuelle Entscheidung?

Eine Abbestellung oder manuelle Versandsperre ist für sich genommen kein Nachweis technischer Unerreichbarkeit. Ebenso darf ein positives DNS-Ergebnis keine Abbestellung umgehen. Bestehende Regeln für Benachrichtigungen weiter beachten.

Die konkrete Speicherung ist bei Umsetzung an das vorhandene Schema anzupassen. Kein zusätzliches pauschales Boolean-Feld erreichbar, das alle drei Bewertungen vermischt.

5. Empfohlener Ablauf beim Einreichen

1. Eingang speichern und Syntax validieren. Bestehende API-Verträge und Validierung beachten. Eine externe DNS-Störung darf keine bereits eingereichten Daten verlieren lassen.
2. Firmenadresse und alle mit der Mitteilung verknüpften Pressekontakte erfassen. Doppelte Adressen und Domains für die Prüfung zusammenfassen. Keine fremden Kontakte allein aufgrund derselben Domain zuordnen.
3. Bekannte Adressprobleme einbeziehen. Dauerhafte Empfängerfehler von temporären Fehlern, Policyproblemen und anderen Sperrgründen unterscheiden.
4. DNS-Prüfung unmittelbar nach erfolgreicher Speicherung im Hintergrund starten. Gültige Cache-Ergebnisse dürfen direkt verwendet werden. Die API muss nicht auf externe DNS-Antworten warten.
5. Gesamtergebnis für die Mitteilung ermitteln. Mindestens eine technisch geeignete Adresse ohne bekannten dauerhaften Empfängerfehler reicht für die technische Kontaktanforderung. Das ist keine Bestätigung des Postfachs.
6. Vor automatischer Veröffentlichung zentral erneut entscheiden. Inhaltsfreigabe und Kontaktfreigabe müssen zusammenpassen. Ein noch laufender DNS-Job darf nicht von einem schnelleren Klassifizierungsjob überholt werden.
7. Bei Korrektur neu prüfen und den Ablauf fortsetzen. Prüfergebnisse alter Adressstände dürfen neue Daten nicht überschreiben. Wiederholte Jobausführung darf weder doppelte Veröffentlichung noch doppelte Benachrichtigung verursachen.

Eine technisch geeignete, aber beispielsweise abgemeldete Adresse darf zur technischen Bewertung beitragen; eine Benachrichtigung an sie bleibt entsprechend der geltenden Versandregeln unterdrückt.

6. Entscheidung über die Veröffentlichung

Kontaktsituation	Empfohlenes Verhalten
Pressekontakt technisch ungeeignet, Firmenadresse geeignet	Normaler Inhalts-/Veröffentlichungsprozess; Kontaktkorrektur anzeigen
Firmenadresse technisch ungeeignet, mindestens ein Pressekontakt geeignet	Normaler Prozess; Firmendatenkorrektur anzeigen
Erster Pressekontakt gesperrt, weiterer Kontakt geeignet	Weitere Kontakte berücksichtigen; Versand nur an zulässige Empfänger
Alle relevanten Adressen nachweislich unzustellbar	Automatische Veröffentlichung zurückhalten; Kontaktkorrektur oder manuelle Prüfung erforderlich
Keine Kontaktadresse vorhanden	Kontaktanforderung nicht erfüllt; Korrektur oder dokumentierte Ausnahme erforderlich
Keine geeignete Adresse bekannt und mindestens eine DNS-Prüfung ausstehend	Auf Prüfung warten; keine endgültige Ablehnung
Ausschließlich Policy-/Absenderprobleme oder ein einzelner temporärer Bounce	Keine inhaltliche Ablehnung daraus ableiten; Versandproblem gesondert bearbeiten
Inhaltsfilter lehnt unabhängig davon ab	Inhaltliche Ablehnung darf abgeschlossen werden; Kontaktproblem und Versandstatus separat ausweisen

Alternative Kontaktwege: Bei manuell bestätigtem Kontakt, etwa telefonisch oder über einen verantwortlichen Ansprechpartner beim API-Einlieferer, ist eine begründete Ausnahme möglich. Eine bloß hinterlegte Telefonnummer genügt dafür nicht. Zeitpunkt, prüfende Person und Grund protokollieren; die Ausnahme hebt keine Versandsperre auf.

Bereits veröffentlichte Mitteilungen: Ein späterer Bounce erzeugt einen Prüfhinweis und gegebenenfalls eine Korrekturanforderung. Keine automatische Depublikation und keine pauschale Sperrung sämtlicher Veröffentlichungen einer Firma. Zusätzliche Auffälligkeiten können eine redaktionelle Prüfung begründen. Neue Einreichungen werden anhand des aktuellen Kontaktstands bewertet.

7. Technische Anforderungen für die Entwicklung

Prüfung und Speicherung

• Domain normalisieren, internationale Domains korrekt in eine DNS-taugliche Darstellung überführen und die bestehende Adressnormalisierung konsistent verwenden.
• Resolver muss NXDOMAIN, erfolgreiche Antworten ohne passende Records und vorübergehende Fehler unterscheiden können. Eine alleinige Ja/Nein-Abfrage auf MX reicht nicht.
• Pro Domain Ergebnis, maschinenlesbaren Grund, Prüfzeitpunkt, Ablaufzeitpunkt und nächste Wiederholung verfügbar halten.
• Ergebnis nach DNS-Gültigkeitsdauer zwischenspeichern; negative Antworten mit ihrer negativen Cache-Gültigkeit berücksichtigen. Resolverfehler nur kurz behandeln und erneut prüfen.
• Bei unklarer Gültigkeitsdauer konservative, konfigurierbare Cache-Grenzen vorsehen. Ein DNS-Befund darf nicht unbegrenzt als dauerhafte Domainsperre bestehen bleiben.
• Jobs erst nach erfolgreichem Datenbank-Commit starten. DNS-Abfragen außerhalb von Datenbanktransaktionen und Veröffentlichungssperren ausführen.
• Wiederholungen mit begrenztem Zeitbudget und zunehmenden Abständen ausführen. Nach ausgeschöpften Versuchen zur manuellen Prüfung übergeben; keine automatische Umdeutung in „Adresse ungültig“.
• Änderungen an Adressen oder Kontaktzuordnungen machen die bisherige Gesamtbewertung ungültig. Ergebnisse an den geprüften Datenstand binden.
• Bei zeitversetzter Veröffentlichung abgelaufene Domainbefunde und aktuelle Adresssperren berücksichtigen. Das Veröffentlichungsdatum bleibt erhalten, solange die Kontaktprüfung wartet.

Anbindung an das bestehende System

• API v1 und Legacy müssen dieselbe fachliche Prüfung verwenden.
• Den vorhandenen zentralen Veröffentlichungsservice erweitern, damit Klassifizierungsjobs und zeitgesteuerte Veröffentlichung die Prüfung nicht umgehen.
• Die Anwendung auf Kundeneinreichungen ausdrücklich festlegen; Ausgangsumfang dieses Konzepts sind API-Einreichungen. Die Herkunft muss serverseitig nachvollziehbar bleiben.
• Einen eigenen Prüfgrund neben der Inhaltsklassifikation führen. Kontaktkorrektur nicht als inhaltlichen Blacklist-Verstoß speichern.
• Kontaktprüfung vor endgültiger Veröffentlichung und Verbrauch eines Veröffentlichungsslots entscheiden.
• Vorhandene adressbezogene Versandsperren zentral weiterverwenden. Domainbefunde gesondert verwalten; kein synthetischer Hard Bounce allein aus einer DNS-Abfrage.
• Empfängerauswahl über alle zulässigen Pressekontakte und danach die Firmenadresse vornehmen; unmittelbar vor Versand erneut auf Sperren prüfen.
• Keine pauschale Übertragung eines Postfachfehlers auf alle Adressen derselben Domain oder das gesamte Firmenkonto.
• Historische Sperren mit unklarer Ursache zur Prüfung markieren, statt sie beim Start automatisch in Veröffentlichungssperren umzuwandeln oder freizugeben.

API und Admin

• Einlieferern verständliche, maschinenlesbare Gründe bereitstellen, beispielsweise Domain nicht vorhanden, Domain nimmt keine Mail an, Postfach dauerhaft abgewiesen oder Prüfung ausstehend. Feldnamen und Antwortformat an die bestehenden API-Verträge anpassen.
• Annahme der Einreichung, Kontaktprüfung, Inhaltsentscheidung und Benachrichtigungszustellung unterscheidbar anzeigen. Eine erfolgreich gespeicherte Einreichung ist noch keine Veröffentlichungszusage.
• Im Admin „Kontaktprüfung erforderlich“ und „Prüfung ausstehend“ filterbar machen; betroffene Adressen, Gründe, Prüfzeit und Mitteilungen anzeigen.
• Korrektur, erneute Prüfung und begründete manuelle Freigabe nachvollziehbar anbieten. Kein unbelegtes Label „Kontakt verifiziert“ nach bloßer DNS-Prüfung.
• Kontaktprobleme dem API-Einlieferer über abrufbaren Status oder einen gebündelten Bericht zugänglich machen. Keine Korrekturanforderung an eine bereits gesperrte Adresse schicken.
• Ein späterer Bounce bleibt auch dann sichtbar, wenn die Veröffentlichung bereits erfolgreich abgeschlossen wurde.

8. Abnahmekriterien für die Implementierung

Die spätere Umsetzung mit deterministischen Tests und simulierten DNS-Antworten prüfen; keine Abhängigkeit von öffentlichen DNS-Servern im Testlauf.

1. Gültiger MX erlaubt die Fortsetzung, bestätigt aber kein Postfach und löscht keine Bounce-Sperre.
2. Fehlender MX mit A/AAAA wird als zulässiger Fallback behandelt.
3. Null MX, NXDOMAIN sowie erfolgreich festgestelltes Fehlen sämtlicher Zustellwege führen zu nachvollziehbaren Kontaktproblemen.
4. Ein nutzbares MX-Ziel reicht aus, wenn weitere Ziele defekt sind; vorübergehende Auflösungsfehler werden nicht als endgültiges Fehlen behandelt.
5. Timeout und SERVFAIL erzeugen Wiederholungen und bei ausgeschöpftem Budget eine manuelle Prüfung, keine inhaltliche Ablehnung.
6. Firmenadresse und alle zugeordneten Pressekontakte werden berücksichtigt; ein defekter erster Kontakt verdeckt keinen geeigneten weiteren Kontakt.
7. Alle Adressen ungeeignet oder fehlend verhindert automatische Veröffentlichung und Slot-Verbrauch; eine dokumentierte Ausnahme ist nachvollziehbar.
8. Policyfehler, temporäre Bounces und Abbestellungen werden nicht als dauerhafte Empfängerfehler gewertet; Versandbeschränkungen bleiben wirksam.
9. API v1, Legacy, Klassifizierungsjob und Scheduler befolgen die gemeinsame Kontaktentscheidung ohne Umgehung oder Race Condition.
10. Wiederholte Jobs und konkurrierende Freigaben erzeugen keine doppelte Veröffentlichung, Slot-Belastung oder Benachrichtigung.
11. Kontaktkorrekturen verwerfen veraltete Bewertungen und ermöglichen die erneute Prüfung; Cache-Ablauf löst eine neue Domainprüfung aus.
12. Spätere Bounces depublizieren bestehende Mitteilungen nicht automatisch und sperren keine anderen Postfächer derselben Domain.
13. API-Status und Admin zeigen Kontaktursache, Inhaltsstatus und Versandstatus getrennt; manuelle Ausnahmen sind protokolliert.

9. Empfohlene Umsetzungsreihenfolge und offene Details

1. Bounce-Ursachen präzisieren: Dauerhafte Empfängerfehler zuverlässig von Policy-/Absenderproblemen unterscheiden; bestehende Sperren entsprechend einordnen.
2. DNS-Prüfung und Beobachtung ergänzen: Ergebnisse speichern, Admin-Anzeige und API-Rückmeldung bereitstellen. Zunächst ohne automatische Veröffentlichungssperren beobachten.
3. Kontaktregel aktivieren: Nach Prüfung der Ergebnisse neue API-Einreichungen entsprechend Abschnitt 6 zurückhalten; Korrektur- und Ausnahmeprozess gleichzeitig bereitstellen.

Vor Aktivierung konkret festlegen:

• Zeitbudget, Anzahl und Abstände der DNS-Wiederholungen sowie Zuständigkeit für liegengebliebene Prüfungen.
• API-Felder und Bereitstellung eines gebündelten Berichts, falls dieser zusätzlich zum abrufbaren Status benötigt wird.
• Berechtigung und Geltungsdauer manueller Ausnahmen.
• Geltung für erneutes Einreichen alter Entwürfe und eine mögliche spätere Erweiterung auf Kundeneinreichungen.

Diese Betriebsdetails sind noch keine implementierten oder abschließend festgelegten Werte. Es ist keine nachträgliche Massen-Depublikation vorgesehen.

10. Quellen und Bezug zum bisherigen Konzept

• SMTP: DNS-Auflösung und impliziter MX, RFC 5321 § 5.1
• Null MX: Domain nimmt keine E-Mails an, RFC 7505
• Postmark: Einordnung von Bounces und Spam-Beschwerden
• Bisheriges Bounce-Konzept vom 15.09.2026

Dieses Dokument ergänzt das bisherige Bounce-Konzept um die Prüfung beim Einreichen und deren Auswirkungen auf die Veröffentlichung. Aussagen zum vorhandenen Verhalten beruhen auf dem oben verlinkten Code, nicht auf einer bestätigten produktiven Ausführung.