Domain-Catch-all: Routing, Prüfpostfach und Risiken

Sie aktivieren ein Catch-all für Ihre Domain, damit Anfragen auch bei Tippfehlern wie saels@ statt sales@ ankommen. Das ist nachvollziehbar. Innerhalb des Catch-all-Bereichs werden auch unbekannte Empfänger zugeordnet, darunter Ziele automatisierter Adressproben. Spamfilter und weitere Annahmeprüfungen bleiben relevant; die Empfängerannahme ist noch keine endgültige Nachrichtenannahme. Backscatter, Schleifen durch automatische Antworten und Zustellprobleme bei externer Weiterleitung sind mögliche Folgen einer unzureichenden Einrichtung, nicht zwangsläufige Ergebnisse jeder Catch-all-Regel.

Viele Anleitungen enden bei „Catch-all aktivieren und ins Postfach leiten“. Hier beginnt die eigentliche Planung. Dieser Leitfaden behandelt separate Prüfpostfächer, Regex-Routing in Postfix, Schleifenschutz und Authentifizierungsprobleme bei Weiterleitungen. Lesen Sie zuerst den Leitfaden zur Einrichtung von E-Mail-Weiterleitungen, wenn Sie die Grundlagen brauchen. Hier geht es gezielt um Catch-all auf Domainebene.

Was ist ein Catch-all für eine Domain?

Ein Catch-all ist eine MTA-Regel, die Nachrichten an Adressen Ihrer Domain annimmt, die keinem bekannten Empfänger zugeordnet sind. Prüfen Sie dabei nicht nur Postfächer, sondern auch Aliasse, Gruppen und andere gültige Empfänger. Statt 550 User Unknown kann der Server auf die Empfängerprüfung mit 250 OK antworten und die Nachricht an ein Ersatzpostfach routen. Die Annahme eines Empfängers ist von der endgültigen Annahme nach DATA zu unterscheiden. Catch-all verändert die Empfängerrouten im SMTP-Envelope, nicht automatisch die Authentifizierung; zusätzliche Weiterleitungen oder spätere Rückmeldungen können eigene Risiken erzeugen.

Envelope und Header: warum die Unterscheidung wichtig ist

Für die Einrichtung eines Catch-all ist die Unterscheidung zweier standardisierter E-Mail-Ebenen hilfreich. Sie erklärt nicht jedes Problem, verhindert aber Fehlannahmen bei der Suche nach Routing- und Zustellfehlern. Ein nach dieser Prüfung in zwei Minuten behebbarer Fehler ist ein Beispiel, keine Zusage; andere Ursachen können Tage der Diagnose erfordern.

RFC 5321 definiert den SMTP-Envelope mit den Befehlen RCPT TO und MAIL FROM, die während der SMTP-Übertragung ausgetauscht werden. RFC 5322 definiert die Nachrichtenheader, darunter To: und From:, die Ihr E-Mail-Client anzeigt.

Ein Catch-all ordnet einen ansonsten unbekannten Envelope-Empfänger einem Ersatzziel zu und kann die sichtbaren Header unverändert lassen. Diese Empfängerzuordnung beschädigt für sich genommen keine Authentifizierung. SPF prüft die sendende IP anhand der MAIL-FROM- oder HELO-Domain; DKIM prüft die signierten Teile von Headern und Nachrichtentext. DMARC verlangt eine gültige, auf das sichtbare Header-From ausgerichtete SPF- oder DKIM-Authentifizierung. Eine zusätzliche externe Weiterleitung kann diese Prüfungen beeinflussen.

Der Fehlerfall bei externer Weiterleitung

Die Weiterleitung von Catch-all-Nachrichten an Gmail oder Outlook.com schafft eine neue SMTP-Station. Dabei kann zuvor authentifizierte Post an einer späteren Prüfung scheitern:

1. Ursprünglicher Absender: client@bank.com (IP: 1.2.3.4)
2. Ihr Server nimmt typo@yourdomain.com an und leitet an you@gmail.com weiter
3. Gmail sieht eine Verbindung von Ihrer Server-IP mit bank.com als Envelope-Absenderdomain
4. SPF scheitert im Beispiel, weil der SPF-Eintrag von bank.com Ihre IP nicht autorisiert
5. Verwendet bank.com DMARC p=reject und fehlt auch gültiges ausgerichtetes DKIM, kann der Empfänger ablehnen. Eine SMTP-Fehlermeldung oder Unzustellbarkeitsmeldung ist möglich

Sie wollten mit Catch-all fehlende Zustellungen vermeiden, doch die zusätzliche Weiterleitung kann ein neues Problem schaffen. Wenn Sie weiterleiten müssen, prüfen Sie SRS (Sender Rewriting Scheme) oder einen Anbieter, der die Umschreibung serverseitig unterstützt. Die beschriebene Alias-Weiterleitung von TrekMail kann diese Verarbeitung übernehmen, abhängig von aktuellen Funktionen und Tarif. SRS allein garantiert weder DMARC-Ausrichtung noch Zustellung.

Drei Risiken eines Domain-Catch-all

Zu den wichtigen Risiken gehören Backscatter mit Reputationsfolgen, automatische Antwortschleifen und fehlende Zustellungen durch SPF- oder DMARC-Probleme bei externer Weiterleitung. Prüfen Sie alle drei vor einer Konfigurationsänderung. Wer nur einen Punkt berücksichtigt, kann an anderer Stelle neue Probleme schaffen: Aus einer für fünf Minuten geplanten Aufgabe kann beispielsweise eine Woche Nacharbeit werden.

1. Backscatter: ein Reputationsrisiko

Backscatter kann entstehen, wenn Ihr Server eine Catch-all-Nachricht mit 250 OK endgültig annimmt, der Spamfilter sie aber erst nach Abschluss der SMTP-Sitzung beanstandet. Erzeugt der Server anschließend eine Unzustellbarkeitsmeldung an MAIL FROM, kann diese eine gefälschte Adresse eines Unbeteiligten treffen. Dann versenden Sie unerwünschte Rückmeldungen an Personen, die Ihnen nie geschrieben haben. Das kann die IP-Reputation belasten und zu Sperrlisteneinträgen beitragen; eine Listung innerhalb weniger Tage ist nicht unvermeidlich.

Weisen Sie nicht akzeptierte Empfänger nach Möglichkeit während der SMTP-Verbindung zurück, bevor Sie die Nachricht endgültig mit 250 OK annehmen. Bewusst angenommene Catch-all-Post können Sie stattdessen zur Prüfung isolieren. Vermeiden Sie unaufgeforderte Rückmeldungen an möglicherweise gefälschte Absender. Das bedeutet nicht, legitime Unzustellbarkeitsmeldungen pauschal abzuschalten oder legitime Post still zu verwerfen.

2. Antwortschleifen (Exchange-Fehler 5.4.14)

Ein Catch-all leitet unbekannte Empfänger an ein Ersatzpostfach. Dort ist eine Abwesenheitsantwort aktiv. Ein Spammer schreibt an random@yourdomain.com, und die Nachricht kommt im Ersatzpostfach an. Die automatische Antwort geht an einen gefälschten Absender und wird zurückgesendet. Gelangt sie erneut an random@yourdomain.com und wird wieder verarbeitet, kann je nach Routing und Schutzmaßnahmen eine Schleife entstehen. Exchange kann dann 550 5.4.14 Hop count exceeded - possible mail loop melden.

Prüfen Sie für Catch-all-Post die Unterdrückung automatischer Antworten. X-Auto-Response-Suppress: All ist eine insbesondere in Exchange relevante Steuerung, aber keine universelle Garantie. Die Wirkung auf Abwesenheitsantworten, Zustellbestätigungen und Lesebestätigungen hängt von der empfangenden Software ab. Testen Sie Schleifenschutz und tatsächliches Antwortverhalten.

3. Directory Harvest Attacks (DHA)

Antwortet jede Adresse Ihrer Domain mit 250 OK, können Angreifer automatisiert Tausende Kombinationen wie admin@, hr@, ceo@ und invoice@ ausprobieren. Ein globales Catch-all bestätigt die SMTP-Annahme für alle diese Adressen, nicht die Existenz realer Postfächer. Das kann breites Spamaufkommen begünstigen, möglicherweise über Jahre, ohne dass damit gültige Adressen oder eine feste Angriffsdauer nachgewiesen wären.

Gezielte Adressmuster statt eines globalen Catch-all können die Annahmefläche begrenzen. Strategie 2 beschreibt diesen Ansatz.

Strategie 1: ein separates Prüfpostfach

Wenn Sie ein Catch-all brauchen, behandeln Sie unbekannte Empfänger zunächst vorsichtig. Nutzen Sie ein separates Prüf- oder Quarantänepostfach mit eingeschränktem Zugriff, Filtern und kontrollierter Aufbewahrung. Deaktivieren Sie dort automatische Weiterleitungen und Abwesenheitsantworten, sofern sie nicht ausdrücklich geprüft und freigegeben sind. Ein eigenes Postfach ist keine Sicherheits-Sandbox; es ersetzt weder Spamfilter noch Kapazitätsplanung und garantiert keine gute Senderreputation.

Die Logik der Einrichtung:

1. Annehmen: Der Server nimmt *@domain.com im vorgesehenen Catch-all-Bereich an
2. Kennzeichnen: Der Empfänger ist weder Postfach noch Alias, Gruppe oder sonstiger gültiger Empfänger
3. Trennen: An ein eigenes gemeinsames Postfach wie catchall_sink@domain.com routen
4. Antworten unterdrücken: In einer passenden Microsoft-Umgebung mit Spam Confidence Level 9 eine Behandlung als Spam hoher Konfidenz anfordern und X-Auto-Response-Suppress: All anwenden; tatsächliche Klassifizierung und Aktionen prüfen

Prüfen Sie das Postfach beispielsweise wöchentlich. Legitime Nachrichten werden nach Sichtung ins richtige Postfach verschoben; anderes bleibt gemäß Ihrer Prüf- und Aufbewahrungsrichtlinie isoliert. Planen Sie Speichergrenzen, Zuständigkeit und Prüfintervalle. Dies ist eine mögliche risikoärmere Architektur, nicht die einzige zulässige Catch-all-Konfiguration oder ein Reputationsschutz ohne Bedingungen.

Transportregel in Microsoft 365 / Exchange Online

Die folgende Einrichtung ist ein konzeptionelles Beispiel, keine pauschale Änderung für jeden M365-Mandanten. Eine Domain vom Typ Internal Relay deaktiviert Directory Based Edge Blocking (DBEB), implementiert aber allein kein Catch-all. Sie ist nicht für eine Domain gedacht, deren sämtliche Empfänger im Cloud-Dienst liegen: Für andere Empfänger muss ein geprüfter Connector zum berechtigten eigenen Mailserver passen. Prüfen Sie autorisiert Rückwege und Schleifenschutz sowie das vollständige Verzeichnis gültiger Postfächer, Aliasse, Gruppen und anderer Empfänger. Eine Gruppenbedingung allein erfasst nicht jede zulässige Empfängerart. Die mögliche Transportregel muss in die tatsächliche Topologie passen:

Planen und prüfen Sie die Transportregel vor einer Umstellung auf Internal Relay. Reihenfolge, Gültigkeit und Annahmeverhalten hängen von der konkreten Konfiguration ab. Sorgen Sie dafür, dass Routing und Schutzmaßnahmen bei der Änderung wirksam bleiben, statt die Empfängervalidierung ungeprüft zu lockern.

Strategie 2: gezielte Adressmuster mit Postfix PCRE

Gezielte Muster erfassen bestimmte Adressen, ohne die ganze Domain für beliebige Empfänger zu öffnen. Sie definieren reguläre Ausdrücke für erwartete Varianten. Ob nicht passende Adressen tatsächlich hart abgelehnt werden, hängt zusätzlich von Empfängervalidierung, Domainklasse und weiteren Maps ab. Dieser Ansatz kann die Annahmefläche bei Adressproben verkleinern, garantiert aber nicht die Abwehr eines bestimmten Anteils aller Angriffe.

In Postfix können Sie bei installierter PCRE-Unterstützung eine virtuelle Alias-Map mit PCRE (Perl Compatible Regular Expression) verwenden. Die folgenden Muster sind Beispiele und müssen gegen gewünschte sowie unerwünschte Treffer getestet werden. Der Kommentar zur Ablehnung ersetzt keine Empfängervalidierung:

# /etc/postfix/virtual_pcre

# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/    sales-team@yourdomain.com

# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/   support@yourdomain.com

# No wildcard below = hard 550 reject for everything else

Die Einbindung erfolgt in /etc/postfix/main.cf. Achtung: Wenn Sie die folgende Zuweisung als Ersatz übernehmen, können bestehende Alias-Maps verloren gehen. Sichern Sie die Konfiguration, führen Sie die neue Map mit den bisherigen Maps zusammen und prüfen Sie Reihenfolge, Muster und Empfängervalidierung:

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

Nach autorisierter Änderung und erfolgreicher Konfigurationsprüfung können Sie neu laden: postfix reload

Für breitere Abdeckung können Sie vorsichtige Muster für häufige Adressen ergänzen, statt ein globales Catch-all einzurichten:

/^(info|contact|hello|team)@yourdomain\.com$/    info@yourdomain.com

So erfassen Sie ausgewählte Varianten und begrenzen die Annahme beliebiger Adressen, sofern die übrige Empfängervalidierung entsprechend eingerichtet ist.

Wann ein Domain-Catch-all sinnvoll ist

Catch-all passt zu bestimmten, klar begrenzten Aufgaben. Die folgenden drei Beispiele sind häufig vorübergehend; es gibt auch andere begründete Einsätze mit geeigneten Kontrollen. Ein unüberlegtes dauerhaftes Catch-all ist dagegen keine gute Standardlösung.

Sinnvolle Einsätze:

• Kurzlebige Kampagnenadressen: Sie verwenden promo-jan@, promo-feb@ und promo-mar@ und möchten nicht jede Adresse einzeln bereitstellen
• Kunden-Onboarding: Sie nehmen Nachrichten an Adressen an, bevor deren reguläre Einrichtung abgeschlossen ist
• Migration eines Altsystems: Die vollständige Liste aktiver Adressen fehlt noch, und während der Umstellung sollen möglichst keine Nachrichten verloren gehen

In diesen drei Beispielen sollte das Catch-all zeitlich begrenzt sein. Sobald Sie die gültigen Adressen kennen, richten Sie passende Postfächer oder Aliasse ein und prüfen, ob das Catch-all entfallen kann. Wenn Sie zwischen Alias und vollwertigem Postfach wählen, lesen Sie den Vergleich von Domain-E-Mail-Alias und Postfach. Die betrieblichen Unterschiede sind wichtig.

Ungeeignete Begründung: Sie betreiben Catch-all nur, weil Sie für drei Aliasse keine $6 pro Nutzer und Monat zahlen möchten. Aliasse erfordern jedoch nicht bei jedem Anbieter eigene kostenpflichtige Nutzerlizenzen. Prüfen Sie zuerst die tatsächlichen Tarifbedingungen. Ein Preisproblem durch unnötig kompliziertes Routing zu kaschieren, kann nach sechs Monaten mehr Aufwand als Nutzen erzeugen.

TrekMail: gezielte Einrichtung statt Umwege

Manche Catch-all-Konfigurationen entstehen, weil Gebühren pro Nutzer die Verwaltung realer Postfächer teuer machen. Das beschriebene TrekMail-Modell nutzt gemeinsamen Speicher auf Kontoebene und Pauschaltarife innerhalb ihrer Grenzen, statt pro Postfach abzurechnen. Auch einzelne Postfachquoten können gelten. Das ist keine pauschale Abrechnung pro Domain. Prüfen Sie aktuelle Preise und Funktionen. Ein passender Tarif kann den finanziellen Anreiz mindern, Catch-all als Ersatz für echte Aliasse einzusetzen.

Das historische TrekMail-Starter-Beispiel nennt $3.50 pro Monat. Prüfen Sie aktuelle Preise, Grenzen und Funktionen, bevor Sie die tatsächlich benötigten Adressen einrichten. Nur das beschriebene Nano-Modell benötigt eigenen SMTP für alle ausgehenden Nachrichten einschließlich Antworten; verwalteter Versand in bezahlten Tarifen hängt von Rechten und Einrichtung ab. Falls Sie Catch-all brauchen, kombinieren Sie die unterstützte Domainregel mit realen Empfängern für aktiv genutzte Adressen. Beginnen Sie ganz von vorn? Der Leitfaden zur Einrichtung von E-Mail auf Ihrer Domain behandelt DNS, SPF, DKIM, DMARC und Postfächer in sinnvoller Reihenfolge.

Checkliste vor der Catch-all-Aktivierung

Prüfen Sie vor der Aktivierung jeden Punkt. Lücken können unnötige Nacharbeit verursachen; deren Ausmaß hängt von Konfiguration und eingehendem Verkehr ab:

1. SMTP-Empfängervalidierung aktiv: Unbekannte Adressen außerhalb bewusst akzeptierter Catch-all-Muster während der SMTP-Verbindung zurückweisen. Unaufgeforderte Rückmeldungen an möglicherweise gefälschte Absender vermeiden.
2. Automatische Antworten kontrolliert: X-Auto-Response-Suppress: All auf passende Catch-all-Post anwenden, wo unterstützt. Abwesenheitsantworten und Schleifenschutz testen; der Header allein ist keine Garantie.
3. Prüfpostfach bereit: Eigenes Postfach für Catch-all-Post, getrennt vom Tagesgeschäft, mit Kapazitätsgrenzen und zuständiger Person.
4. Spamklassifizierung geprüft: Unbekannte Empfänger vorsichtig klassifizieren und gemäß Ihrer Richtlinie gezielt sichten. Legitime Post nicht standardmäßig still verwerfen.
5. SPF und DMARC geprüft: Bei Weiterleitung SRS und die Autorisierung der tatsächlich sendenden IP für die umgeschriebene Domain prüfen. DMARC braucht mindestens einen gültigen, ausgerichteten SPF- oder DKIM-Pfad; auch die Regeln des Empfängers sind zu berücksichtigen.
6. Gezielte PCRE-Muster bevorzugt: Teilmuster nutzen, wenn Ihr MTA Regex unterstützt. Nicht ohne geschäftlichen Grund beliebige Adressen akzeptieren; übrige Empfängervalidierung testen.
7. Unzustellbarkeitsmeldungen kontrolliert: Backscatter an gefälschte Absender verhindern, ohne legitime Rückmeldungen pauschal abzuschalten. Angenommene Post nach festgelegter Prüf- und Aufbewahrungsrichtlinie behandeln.

Fazit

Ein Domain-Catch-all ist ein legitimes Werkzeug, wenn Empfängerzuordnung, Prüfpostfach, SMTP-Validierung, Antwortverhalten und Rückmeldungen bewusst geplant sind. Ein bloßes Einschalten ohne Kontrollen kann Backscatter, Schleifen und bei externer Weiterleitung Authentifizierungsprobleme erzeugen. Diese Risiken sind prüfbar, aber nicht jeder Einsatz führt zwangsläufig innerhalb weniger Wochen zu Fehlern. Richten Sie Catch-all gezielt ein oder verzichten Sie darauf.

Wenn Sie Catch-all nur wegen Gebühren pro Nutzer einsetzen, prüfen Sie zuerst das Kostenmodell. Das beschriebene Pauschalhosting von TrekMail kann Ihnen die benötigten Postfächer und Aliasse innerhalb der Tarifgrenzen ermöglichen. Catch-all wird damit eine bewusste Wahl statt eines Umwegs. Starten Sie eine kostenlose Testphase, prüfen Sie die aktuellen Bedingungen und planen Sie Ihre Catch-all-Einrichtung von Anfang an sorgfältig.