Eine Catch-all-E-Mail-Adresse nimmt Nachrichten für unbekannte Empfänger Ihrer Domain an. Jemand schreibt slaes@yourcompany.com statt sales@. Die Catch-all-Regel kann die Nachricht auffangen, damit eine echte Anfrage nicht an der falschen Adresse scheitert. Das ist praktisch, beschreibt aber nur einen Teil der Folgen.
Das vermeintliche Sicherheitsnetz erweitert den Eingang für beliebige Empfängernamen. Dadurch können mehr Spam und automatisierte Adressversuche verarbeitet werden. Werden nach der Annahme Fehlerberichte an gefälschte Absender geschickt, droht Backscatter. Bei anschließender Weiterleitung können außerdem Authentifizierungsprobleme entstehen. Diese Risiken sind möglich, aber nicht bei jeder Catch-all-Konfiguration unvermeidlich.
Dieser Leitfaden erklärt die Verarbeitung auf SMTP-Ebene, drei betriebliche Risiken und Alternativen für flexible Adressen. Einzelheiten zum Routing finden Sie unter Domain-Catch-all kontrolliert einsetzen.
Was ist eine Catch-all-E-Mail-Adresse?
Eine Catch-all-Adresse, auch Wildcard-Adresse genannt, ist eine Serverregel: Nachrichten für nicht eingerichtete Empfänger einer Domain werden an ein bestimmtes Postfach geleitet. Der Server kann bei RCPT TO mit "250 OK" antworten, statt unbekannte Empfänger mit "550 User unknown" abzulehnen. Andere Prüfungen können die Nachricht dennoch zurückweisen.
Unbekannte Empfänger bereits während SMTP vor der Übertragung der Nachrichtendaten abzulehnen, wird hier als Fail-closed bezeichnet. Catch-all öffnet diese Empfängerprüfung, also Fail-open. Tippfehler und erfundene Adressen können damit dieselbe Route nehmen. Spam- und sonstige Annahmeprüfungen bleiben davon getrennt.
Während einer Migration kann das helfen, unbekannte Altadressen zu finden. Im Dauerbetrieb müssen Nutzen, Aufwand und Schutzmaßnahmen bewusst abgewogen werden.
So funktioniert Catch-all auf SMTP-Ebene
Die Empfängerprüfung erfolgt beim RCPT-TO-Befehl nach RFC 5321. Sie findet vor DATA mit Headern, Text und Anhängen statt. Eine positive Empfängerantwort ist noch keine endgültige Nachrichtenannahme. Die folgenden vereinfachten Beispiele zeigen die beiden Wege.
Ohne Catch-all: Fail-closed
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 550 5.1.1 User unknown
RESULT: Connection closed. Zero data transferred.Der Empfänger wird im SMTP-Dialog abgelehnt. Der sendende Server kann anschließend einen Fehlerbericht erstellen. Dafür muss die Verbindung nicht geschlossen werden. "Zero data" meint hier die nicht übertragene Nachrichtenlast, nicht den bereits ausgetauschten SMTP-Verkehr. Für diesen Empfänger werden normalerweise keine Nachrichtendaten gespeichert oder inhaltsbasiert gefiltert.
Mit Catch-all: Fail-open
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 250 2.1.5 OK
RESULT: Server accepts headers, body, and attachments.
Routing logic directs mail to the catch-all mailbox.Der Server hat zunächst den Empfänger akzeptiert. Erst nach endgültiger Annahme der vollständig übertragenen Nachricht übernimmt er die Zustellungsverantwortung. Spam, schädliche Inhalte oder automatisierte Versuche können dann Speicher und Filter belasten. Soweit technisch sinnvoll, sollten unerwünschte Nachrichten bereits während SMTP abgelehnt werden, statt später Rückmeldungen an möglicherweise gefälschte Absender zu erzeugen.
Drei betriebliche Risiken einer Catch-all-Adresse
Zu prüfen sind insbesondere Adressausforschung und unerwünschtes Volumen, Backscatter durch nachträgliche Fehlerberichte sowie Authentifizierung bei Weiterleitung. Catch-all kann die Angriffsfläche vergrößern, verursacht diese Folgen aber nicht automatisch.
1. Directory Harvest Attacks (DHA)
Spammer testen automatisiert Tausende üblicher Namen wie admin, invoice, hr, accounts, david, noreply, info und billing. Sie wollen herausfinden, welche Empfänger tatsächlich existieren.
Ohne Catch-all können 550-Antworten unbekannte Adressen erkennen lassen. Sie zwingen einen Angreifer nicht zum Aufgeben. Mit Catch-all liefert die Empfängerprüfung möglicherweise überall 250 OK; gültige und erfundene Adressen lassen sich darüber nicht unterscheiden. Trotzdem können solche Versuche viel zusätzliche Post erzeugen. Echte Kundennachrichten gehen leichter zwischen Tausenden Sendungen an nie eingerichtete Empfänger unter.
2. Backscatter und Reputationsrisiken
Backscatter entsteht, wenn ein Server eine Nachricht annimmt und anschließend einen Fehlerbericht an einen gefälschten Absender verschickt. Solche Rückmeldungen können die Reputation belasten und Einträge in Blocklisten wie ips.backscatterer.org begünstigen.
Ein möglicher Ablauf:
- Ein Spammer sendet Schadsoftware an random@yourdomain.com und fälscht MAIL FROM als innocent@gmail.com.
- Die Catch-all-Regel akzeptiert den Empfänger; die Nachricht passiert auch die weiteren Annahmeprüfungen.
- Eine spätere Virenprüfung erkennt Schadsoftware und verhindert die interne Zustellung.
- Der Server erzeugt einen Non-Delivery Report (NDR) an innocent@gmail.com.
- Der unbeteiligte Gmail-Nutzer erhält eine unerbetene Fehlermeldung.
Bei hohem Volumen sind Reputationsprobleme oder Blocklisteneinträge möglich, nicht zwangsläufig. Vermeiden Sie nachträgliche NDRs und automatische Antworten an gefälschte Absender; prüfen Sie Ablehnung während SMTP oder eine sichere Quarantäne.
3. Weiterleitung und SPF-Probleme
Manche Betreiber leiten Catch-all-Post von *@company.com an ein privates Gmail-Konto weiter. Dafür muss die Authentifizierung des tatsächlichen Weiterleitungswegs geprüft werden. Catch-all selbst verändert SPF nicht.
Bei gewöhnlicher Weiterleitung verbindet sich Ihre IP, während MAIL FROM weiterhin etwa bankofamerica.com nennt. Dessen SPF erlaubt Ihre IP möglicherweise nicht. SRS-Weiterleitung schreibt die Umschlagidentität um; SPF der neuen Identität muss die Relay-IP autorisieren. Das schafft nicht automatisch Ausrichtung zum ursprünglichen From. Erfolgreiches, ausgerichtetes DKIM kann DMARC auch ohne SRS oder ARC erfüllen. ARC verlangt eine validierte Kette und Vertrauen des Empfängers in den verifizierten Signierer. Gmail kann ablehnen, verzögern oder filtern; ein stilles Verschwinden ist keine allgemeine Folge und diese Techniken garantieren keine Zustellung.
Alternativen zur Catch-all-Adresse
Wenn bekannte Funktionsadressen oder Markierungen genügen, erlauben explizite Aliasse und unterstützte Plus-Adressierung gezielteres Routing. Die richtige Wahl hängt vom Zweck und der tatsächlichen Umsetzung ab.
| Merkmal | Catch-all-Adresse | Explizite Aliasse | Plus-Adressierung |
|---|---|---|---|
| Syntax | *@domain.com | sales@domain.com | user+tag@domain.com |
| Empfängerprüfung | Unbekannte Empfänger werden geroutet | Unbekannte werden normalerweise abgelehnt | Nur unterstützte Basisadressen und Tags |
| Spamrisiko | Zusätzliches unerwünschtes Volumen möglich | Gezieltere Annahme, kein vollständiger Spamschutz | Gezieltere Nutzung, abhängig von der Umsetzung |
| TrekMail-Kosten | Aktuelle Planrechte prüfen | Aktuelle Gebühren und Limits prüfen | Unterstützung und aktuelle Bedingungen prüfen |
Explizite Aliasse sind für bekannte Adressen oft ein guter Ausgangspunkt: Sie legen gültige Empfänger fest und prüfen, ob alle übrigen während SMTP abgelehnt werden. Zur Strukturierung lesen Sie Alias-Weiterleitung und Domain-Alias oder Postfach.
Lizenzkosten sind kein zwingender Grund für Catch-all
Manche kleine Unternehmen wollen zusätzliche Nutzerlizenzen vermeiden. Im historischen Beispiel kostet Google Workspace $6 je Nutzer und Monat: sales@, support@ und billing@ als eigene lizenzierte Postfächer ergeben $18 monatlich für drei Adressen. Aktuelle Preise können abweichen; Aliasse, gemeinsame Postfächer und bestehende Lizenzen können andere Möglichkeiten bieten. Ein einzelnes Postfach mit Catch-all ist daher nicht die einzige Alternative.
TrekMail teilt Speicher auf Kontoebene statt ausschließlich nach Nutzerzahl abzurechnen. Prüfen Sie Gesamt- und individuelle Postfachquoten sowie aktuelle Tarifgrenzen. Wenn erforderliche Postfächer im Kontotarif enthalten sind, kann die Kostenmotivation für Catch-all entfallen.
| Historisches Beispiel mit Nutzerlizenzen | TrekMail-Beispiel | |
|---|---|---|
| 3 Funktionspostfächer | $18/Monat im Workspace-Beispiel | $3.50/Monat insgesamt im Starter-Beispiel |
| 50 Postfächer | $300/Monat im Lizenzbeispiel | $3.50/Monat im historischen Beispiel |
| Catch-all als Kostenausweg nötig? | Nicht zwingend; andere Adressmodelle prüfen | Zusätzliche Postfachrechte des Plans prüfen |
| SMTP-Empfängerprüfung | Lizenzmodell erzwingt kein Fail-open | Tatsächliche Standardkonfiguration prüfen |
Die historische Starter-Beschreibung nennt $3.50 monatlich, bis zu 50 Domains und 100 Postfächer je Domain. Prüfen Sie die heutigen Bedingungen, bevor Sie damit planen. Richten Sie sales@, support@, billing@, info@ und andere benötigte Empfänger gezielt ein; kontrollieren Sie zugleich die Ablehnung unbekannter Adressen.
Ein isoliertes Prüfpostfach für notwendiges Catch-all
Bei einer Migration können unbekannte Altadressen eine zeitweise Auffangroute sinnvoll machen. Leiten Sie solche Nachrichten nicht unkontrolliert in einen produktiven Posteingang, sondern in ein eigenes Prüfpostfach. Das ist keine Sicherheits-Sandbox: Zugriff, Filterung, Aufbewahrung und Umgang mit Anhängen müssen separat abgesichert sein.
- Eigenes Postfach anlegen: catchall-quarantine@yourdomain.com, nicht der Hauptposteingang einer Person.
- Routing einrichten: Nur unbekannte Empfänger hierher leiten; Zugriff beschränken und keine automatische Weiterleitung oder Antwort aktivieren.
- Benachrichtigungen begrenzen: Geeignete Kennzeichnung und sichere Filter verwenden; die Wirkung auf Benachrichtigungen hängt von Client und Regeln ab. Niedrige Priorität macht Schadsoftware nicht sicher.
- Wöchentlich prüfen: Für bestätigte legitime Altadressen gezielt Aliasse erstellen.
- Abschlusskriterium festlegen: Beispielsweise nach 30 Tagen ohne legitimen Fund über das Abschalten entscheiden; saisonale oder seltene Nachrichten berücksichtigen.
So dient Catch-all der Bestandsaufnahme, statt unbemerkt dauerhaft zu bleiben. Identifizieren Sie benötigte Altadressen, richten Sie sie explizit ein und schließen Sie die Auffangroute, sobald der Zweck erfüllt ist.
Für Agenturen: Adressabdeckung gezielt einrichten
Bei 100+ Domains kostet die manuelle Einrichtung wiederkehrender Kundenadressen Zeit. Standardisieren Sie postmaster@, abuse@, accounts@ und info@ und nutzen Sie tatsächlich verfügbare, dokumentierte Verwaltungsaktionen. Prüfen Sie die Unterstützung, bevor Sie Aliasvorlagen oder Automatisierung einplanen; eine domainübergreifende Sammelerstellung ist nicht vorauszusetzen.
Rollenadressen wie postmaster@ und abuse@ sind in RFC 2142 und zugehörigen SMTP-Vorgaben beschrieben. Aktive SMTP-Zustellungs- oder Relaydienste müssen postmaster unterstützen; weitere Rollen wie abuse sind nach angebotenen Diensten und geltenden Standards zu prüfen. Nicht jede Rollenadresse ist für jede Domain pauschal vorgeschrieben. Prüfen Sie Anforderungen und aktuelle Agency-Funktionen vor einer breiten Einrichtung.
Wann Catch-all sinnvoll sein kann
Drei Beispiele für zeitlich begrenzten Einsatz:
- Laufende Migration: Das Adressverzeichnis des Altsystems ist noch unvollständig.
- Domainübernahme: Historische Empfänger müssen untersucht werden, bevor über ihre Fortführung entschieden wird.
- Testumgebungen: Erfundenen Testadressen soll ohne vorherige Einzeleinrichtung ein kontrolliertes Ziel zugewiesen werden.
In diesen drei Fällen sind begrenzte Laufzeit und ein abgesichertes Prüfpostfach oft sinnvoll. Schalten Sie die Route nach Erfüllung des Zwecks ab. Dauerhaftes Catch-all kann für bewusst geplante Anforderungen vertretbar sein, braucht aber geeignete Schutzmaßnahmen und laufende Überwachung.
Catch-all bewusst bewerten, nicht einfach aktivieren
Dem Auffangen von Tippfehlern stehen drei mögliche Betriebskosten gegenüber: unerwünschtes Adressvolumen, Backscatter bei unsicheren Fehlerberichten und Authentifizierungsprobleme bei Weiterleitung. Prüfen Sie diese Risiken anhand Ihrer tatsächlichen Nachrichtenwege.
Wenn Catch-all hauptsächlich Lizenzkosten sparen soll, vergleichen Sie zuerst Adress- und Lizenzmodelle. TrekMails gemeinsamer Speicher kann passende Postfächer innerhalb der jeweiligen Planrechte ermöglichen. Sales@, support@, billing@ und 47 weitere sind ein Planungsbeispiel, keine unbegrenzte Zusage zum aktuellen Preis.
Prüfen Sie die aktuellen Bedingungen eines 14-tägigen Testzeitraums, einschließlich einer möglichen Kartenpflicht. Nano wird als kostenloses Modell ohne Karte und Testzeitraum beschrieben; Verfügbarkeit und Bedingungen sind aktuell zu prüfen. Nur in diesem beschriebenen Nano-Modell benötigen Sie eigenes externes SMTP für alle ausgehenden Nachrichten und Antworten. Verwalteter Versand in bezahlten Tarifen hängt von tatsächlichen Rechten und der Clientkonfiguration ab.
