Catch-all-Mailhosting: 8 Prüfungen vor der Aktivierung

Catch-all-E-Mail-Hosting leitet Nachrichten an unbekannte Empfänger Ihrer Domain auf ein Auffangziel. Es ist eine serverseitige Routingregel, kein DNS-Wildcard-Eintrag. Auch damit bleibt die endgültige Annahme von weiteren Prüfungen abhängig.

Statt 550 5.1.1 User Unknown kann die Empfängerprüfung 250 OK für RCPT TO liefern. Automatisierte Directory Harvest Attacks testen Namen wie admin@, invoice@, payroll@ und careers@. Catch-all erschwert dabei die Unterscheidung gültiger Adressen, kann aber zusätzlichen Verkehr aufnehmen. Der historische Cisco-Wert von 25 ungültigen Empfängern pro Stunde betrifft die Bewertung eines entfernten Sendehosts beziehungsweise seiner IP in einer konfigurierten Listener-Richtlinie, keine allgemeine Angriffsschwelle für Domains. Ein Angriff kann Tausende Versuche pro Minute erzeugen.

Je nach Missbrauchsrichtlinie kann ein Anbieter Maßnahmen bis zur Sperrung ergreifen. Echte Nachrichten können im unerwünschten Volumen untergehen oder an anderen Prüfungen scheitern. Prüfen Sie die folgenden acht Bereiche, bevor Sie Catch-all einschalten.

Zur Architektur mit Prüfpostfächern, PCRE-Filtermaps und Vermeidung von Exchange-Schleifen lesen Sie zunächst Domain-Catch-all kontrolliert betreiben. Die Checkliste hilft anschließend bei der konkreten Umsetzung.

Was Catch-all am SMTP-Ablauf verändert

Catch-all verändert die Empfängerprüfung im SMTP-Umschlag. Anstelle einer Ablehnung mit 550 vor DATA werden unbekannte Empfänger an ein Auffangpostfach geroutet. Das kann mehr Inhaltsscans und Speicherbedarf bedeuten. Filter können jedoch auch während DATA vor der endgültigen Annahme arbeiten; Empfängerannahme ist nicht Nachrichtenannahme.

Angenommene Proben können Queue, Filter und Speicher belasten. Werden anschließend Fehlerberichte an gefälschte MAIL FROM-Adressen verschickt, entsteht Backscatter. Ein Zeitraum von 2-4 Wochen zur Bereinigung eines Listeneintrags ist nur ein Planungsbeispiel. Dauer und Auswirkungen auf andere Domains hängen von Listenverfahren, gemeinsamen IPs und Empfängerbewertungen ab; nicht automatisch vom gesamten IP-Bereich.

Der Kern der Abwägung: flexibel auf unbekannte Empfänger reagieren, ohne frühzeitige Ablehnung, sichere Filterung und kontrollierte Fehlerbehandlung unnötig aufzugeben.

Die 8-Punkte-Checkliste für Catch-all-Hosting

Prüfen Sie acht Bereiche: SMTP-Filterung vor endgültiger Annahme, zeitnahe Logs, Schutz vor hohem Volumen, Weiterleitungsauthentifizierung, autorisierte Antwortidentitäten, NDR-Kontrollen, Export und Speicherregeln. Die konkrete Anforderung hängt von Ihrer Architektur ab.

1. SMTP-Filterung vor endgültiger Annahme

Fragen Sie, wann unerwünschte Nachrichten abgelehnt werden. 250 OK beim Empfänger sagt nicht, dass bereits der ganze Inhalt gespeichert wurde. Auch ein Inhaltsfilter vor der endgültigen SMTP-Bestätigung kann Backscatter vermeiden. Erst ein späterer NDR an einen gefälschten Absender erzeugt dieses Problem.

Eine Ablehnung bei der Empfängerprüfung kann so aussehen:

postfix/smtpd[1234]: NOQUEUE: reject: RCPT from unknown[192.0.2.1]:
  550 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org;
  from=<probe@attacker.com>, to=<random123@yourdomain.com>

Ein Inhaltsfilter kann beispielsweise protokollieren:

amavis: Blocked SPAM {DiscardedInbound}, [192.0.2.1]
  <probe@attacker.com> -> <random123@yourdomain.com>, Score: 17.2

Die zweite Zeile belegt eine Inhaltsprüfung, aber allein weder endgültige Annahme noch dauerhafte Speicherung. Fragen Sie nach dem vollständigen Ablauf, Queue-Verhalten und SMTP-Ergebnis. "Unser Spamfilter erledigt das" reicht ohne diese Informationen nicht zur Bewertung aus.

2. Zeitnaher Zugang zu SMTP-Protokollen

Ein Kunde meldet eine Nachricht an billing@, auf die niemand reagiert hat. Eine bloße Nachrichtenanzahl erklärt nicht, ob der Empfänger akzeptiert, der Inhalt gefiltert oder ein anderes Ziel gewählt wurde. Benötigt werden passende, zeitnahe Zustellungsdaten.

Nützliche Protokolldaten können so aussehen:

Jan 03 10:14:22 mail postfix/smtpd: connect from mail.outlook.com[40.107.100.99]
Jan 03 10:14:23 mail postfix/cleanup: message-id=<20260103.ABC@outlook.com>
Jan 03 10:14:24 mail amavis: Passed CLEAN {RelayedInbound}, [40.107.100.99]
  <client@outlook.com> -> <billing@yourdomain.com>, Hit: -1.5

Google Workspace und Microsoft 365 bieten unterschiedliche administrative Such- und Tracefunktionen. 30-60 Minuten sind ein mögliches Verzögerungsbeispiel, keine gemeinsame feste Frist. Prüfen Sie Details, Aktualität, Berechtigungen und Datenschutz. Falls Support nötig ist, vereinbaren Sie einen passenden Eskalationsweg, statt den Anbieter allein deswegen pauschal auszuschließen.

3. Volumenschutz für Ihr Konto

Angreifer können Tausende zufällige Empfängernamen ausprobieren und damit viel unerwünschten Verkehr erzeugen. Prüfen Sie, ob Verbindungsgrenzen, senderbezogene Drosselung und kontobezogene Schutzmaßnahmen greifen. Sperrungen hängen vom Anbieter und der Situation ab, nicht automatisch vom Catch-all-Schalter.

Fragen Sie konkret: "Wenn unsere Domain durch einen Adressangriff 10,000 Nachrichten in einer Stunde erhält, wie begrenzen Sie die Quelle, schützen unser Konto und halten legitime Zustellung möglichst aufrecht?"

4. SRS und ARC bei Weiterleitung prüfen

Wer von Server A an Gmail oder Outlook weiterleitet, muss die Umschlagidentität und gültige Signaturen untersuchen. Dabei sind zwei Mechanismen besonders wichtig.

SPF: Der Empfänger sieht die Relay-IP. Bei unverändertem MAIL FROM kann SPF fehlschlagen, wenn das ursprüngliche v=spf1 ... -all diese IP nicht autorisiert.

DMARC: Scheitern SPF und gültiges, ausgerichtetes DKIM, kann p=reject zur Ablehnung beitragen. Es bedeutet keine universelle stille Löschung; maßgeblich sind Ergebnisse und Empfängerpolitik.

Prüfen Sie die folgenden Funktionen für Ihren Weg:

• SRS (Sender Rewriting Scheme): Schreibt Envelope-From um. SPF der neuen Identität muss die Relay-IP erlauben; Ausrichtung zum ursprünglichen From ist nicht garantiert. Details unter SRS-Weiterleitung: Funktion und Fehler.
• ARC (Authenticated Received Chain): Nach RFC 8617 übermittelt ARC signierte Authentifizierungsergebnisse. Der Empfänger muss die Kette validieren und dem verifizierten Signierer vertrauen.

Diese Fehler betreffen unterschiedliche Ursachen:

550 5.7.520 Access denied, your organization does not allow external forwarding.
550 5.7.1 Unauthenticated email from domain.com is not accepted
  due to the domain's DMARC policy.

Der externe Weiterleitungsblock ist eine Organisationsrichtlinie, kein Beweis für fehlendes SRS oder ARC. Gültiges, ausgerichtetes DKIM kann DMARC auch ohne beide erfüllen. Fehlende Dokumentation ist Anlass zur Nachfrage, nicht zum sicheren Schluss über fehlende Unterstützung.

5. Aliasse und autorisierte Antwortidentitäten

Catch-all kann Nachrichten an billing@, support@ oder project-2026@ aufnehmen. Zum Antworten als billing@yourdomain.com statt admin@yourdomain.com braucht Gmail eine passende Send-as-Identität mit Berechtigung und gegebenenfalls Verifizierung. Diese Einrichtung erfolgt je Identität, nicht bei jeder Nachricht erneut.

Prüfen Sie unterstützte SMTP-Konten und sichere Verwaltungsabläufe für zusätzliche Absender. Ein 24-stündiges Freigabebeispiel kann die Planung beeinflussen; unkontrolliertes sofortiges Senden als beliebige Adresse ist jedoch kein sinnvolles Qualitätskriterium.

6. Backscatter und NDRs kontrollieren

Nach endgültiger Annahme kann ein voller Auffangbriefkasten oder Routingfehler einen NDR auslösen. Geht er an einen gefälschten MAIL FROM, ist das Backscatter und kann eine Aufnahme in Listen wie Backscatterer.org begünstigen. Ein Filter-Discard erzeugt dagegen nicht automatisch einen solchen Bericht.

Fragen Sie nach Ablehnung während SMTP und sicherer Quarantäne, ohne automatische Antworten an gefälschte Absender. Löschen Sie nicht pauschal potenziell legitime Nachrichten. Backscatter ist kein offenes Relay, kann aber die Versandreputation Ihrer Domain und der verwendeten IPs belasten.

7. IMAP und Datenexport

Planen Sie vorab einen Export, falls Sie den Dienst wechseln müssen. Standard-IMAP kann helfen; auch dokumentierte, vollständige Exportwege können geeignet sein. Prüfen Sie Zugänglichkeit und Datenumfang, nicht allein den Namen des Verfahrens.

Wichtige Prüfpunkte:

• IMAP über Port 993 mit TLS, sofern unterstützt
• Export in .eml oder .mbox und passende Importmöglichkeiten
• Abgestimmte Limits und ein sicherer Ablauf für umfangreiche Lesezugriffe

POP3 bildet Ordner normalerweise nicht wie IMAP ab. Löschen hängt von DELE und Client-Einstellungen ab; RETR allein löscht die Nachricht nicht automatisch. IMAP ist nicht der einzige mögliche Migrationsweg und garantiert keine vollständige Metadatenübernahme. Prüfen Sie bei einer autorisierten Migration kompatible Zugänge, Sicherungen, Ordner, Anzahl, Formate und Ausnahmen sowie einen abschließenden Abgleich neuer Nachrichten. Kontakte und Kalender benötigen gegebenenfalls einen eigenen Übertragungsweg.

8. Speicherregeln und Verhalten bei voller Quote

Ein Catch-all-Postfach kann seine Quote erreichen. Fragen Sie nach der konkreten SMTP-Reaktion, etwa 452 4.2.2 Insufficient storage, Logging und Wiederholungen. Eine temporäre Antwort kann einen begrenzten Retry auslösen, garantiert aber keine spätere Zustellung. Stilles Verwerfen legitimer Post darf nicht unbemerkt bleiben.

Klären Sie, ob Speicher pro Postfach, Domain oder Konto geteilt wird. 80% Verbrauch durch einen Angriff ist ein hypothetisches Lastszenario. Grenzen je Postfach können Auswirkungen reduzieren, ersetzen aber keine Prüfung der Gesamtquote und des tatsächlichen Modells.

Catch-all im TrekMail-Modell prüfen

TrekMail beschreibt gemeinsame Speicherkapazität auf Kontoebene und mehrere Postfächer innerhalb eines Plans. Prüfen Sie die Gesamtquote, individuelle Postfachlimits sowie konto- und planbezogene Rechte, statt unbegrenzte Postfächer oder eine reine Abrechnung je Domain anzunehmen. jobs@, billing@, support@ und archive@ können gezielt eingerichtet werden, soweit die aktuellen Bedingungen es erlauben.

Ein historisches Lizenzbeispiel von $6-$12 monatlich pro Nutzer kann für eine Adresse mit drei Nachrichten im Monat teuer wirken. Aliasse und gemeinsame Postfächer in Suiten sind ebenfalls zu berücksichtigen:

Für Altadressen, externe Systeme oder Anfragen kann Catch-all geeignet sein. Prüfen Sie aktuelle SMTP-Protokolle, IMAP und SRS sowie die tatsächliche Route. Historisch werden Starter mit $3.50 monatlich für 50 Domains, ein 14-tägiger Test mit Karte sowie ein kostenloses Modell mit 10 Domains und 5GB gemeinsamem Speicher genannt. Preise, Limits und Verfügbarkeit sind aktuell zu prüfen. Im beschriebenen Nano-BYO-SMTP-Modell ist eigenes SMTP für alle ausgehenden Nachrichten und Antworten nötig; dies gilt nicht pauschal für andere Pläne.

Fazit

Catch-all ist eine bewusste Routingentscheidung, keine notwendige Grundeinstellung. Prüfen Sie die Liste bei jedem Anbieter: sichere Annahme und Fehlerbehandlung, Schutz vor Last, nachvollziehbare Zustellung sowie zuverlässiges Verhalten an Speichergrenzen. Die Entfernung eines Blocklisteneintrags kann Wochen dauern, je nach Liste und Behebung der Ursache.

Klären Sie frühzeitig SMTP-Ablehnung, tatsächliche Weiterleitungsauthentifizierung und Backscatter-Kontrollen. Reputationsfolgen können Wochen anhalten, ohne feste Frist oder unvermeidliche Auswirkungen. Falls Kosten die Hauptmotivation sind, vergleichen Sie Pläne, Aliasse und gemeinsame Postfächer, statt anzunehmen, ein anderes Preismodell beseitige jedes Routingproblem.

Aktuelle TrekMail-Pläne, IMAP-Möglichkeiten und kostenlose Angebote prüfen.