Catch-all-e-mail: werking, risico’s en alternatieven

Catch-all-mail is een serverinstelling die onbekende ontvangers op je domein naar een standaardbestemming leidt. Voor ghost@yourdomain.com kan een server zonder die route een 550-fout geven. Dat weigert de ontvanger, maar verplicht geen verbindingssluiting. Met catch-all kan hij 250 OK antwoorden; definitieve berichtacceptatie volgt pas later, na de toepasselijke controles.

Ook in 2026 vraagt die adresdekking om filtering, opslagbeheer en een passende omgang met persoonsgegevens. Spam of reputatieschade is geen automatische uitkomst, maar ongerichte opvang kan de beheerlast vergroten.

Deze gids behandelt SMTP, vijf productieaandachtspunten, forwardingauthenticatie en alternatieven. Kies de inrichting op basis van je werkelijke adresbehoefte en controleer de effecten.

Wat is catch-all-mail?

Catch-all-mail, ook accept-all of wildcardrouting genoemd, biedt een route voor ontvangers zonder afzonderlijke mailbox of alias. Waar een onbekend adres anders een 550-fout krijgt, kan het een aangewezen opvangmailbox gebruiken. De overige SMTP- en inhoudscontroles hoeven daardoor niet te verdwijnen.

Accept-all en catch-all duiden in beheerpanelen vaak hetzelfde doel aan: een onbekende ontvanger bij RCPT TO krijgt een standaardroute. Controleer bij TrekMail Domains → Routing, of Connection in oudere interfaces, en Catch-all Inbox. Kies een actieve, toegestane mailbox binnen hetzelfde domein. Verifieer het gedrag na de wijziging; de instelling belooft geen onmiddellijke aflevering.

Het gebruik in de late jaren 1990 moet in zijn historische context worden gezien. In 2026 zijn geautomatiseerde adresprobes en spambronnen relevante operationele factoren. Catch-all laat meer ontvangeradressen toe, niet noodzakelijk alle berichten zonder filtering.

Waarom beheerders catch-all kiezen

Twee begrijpelijke doelen zijn typefouten opvangen en licentiekosten beperken. Catch-all kan daarvoor bruikbaar zijn, maar vergelijk gerichte aliases, gedeelde mailboxen en een beheerde opvangroute voordat je alle onbekende adressen toelaat.

Angst om een aanvraag te missen

Een klant kan suport@ in plaats van support@ schrijven. Catch-all kan dat bericht opvangen, maar ook ongewenste mail naar verzonnen adressen toelaten. Hoeveel bruikbare typefouten tegenover spam staan, moet je in je eigen verkeer beoordelen.

Voor bekende typefouten kun je expliciete aliases maken. Laat naast support@ bijvoorbeeld suport@ naar dezelfde mailbox wijzen. Dat beperkt onbekende ontvangers, maar vervangt geen spamfilter.

Licentiekosten per gebruiker

Een historische prijsrange bij Google Workspace en Microsoft 365 is $6-30 per gebruiker per maand. Als support@, billing@, jobs@ en marketing@ elk een aparte gebruikerslicentie vragen, kan het voorbeeld op $120 per maand uitkomen. Suites kunnen ook aliases en gedeelde mailboxen ondersteunen; niet iedere rolnaam vereist een aparte gebruiker.

Vergelijk totale kosten, opslag, toegangsrechten en routing. Een ander abonnementsmodel kan de adresinrichting vereenvoudigen, maar maakt filtering en gegevensbeheer niet overbodig. Bekijk de actuele voorwaarden van TrekMail-plannen voor een eigen vergelijking.

Werking op SMTP-niveau

Bij RCPT TO noemt de verzendende server de ontvanger voordat de berichtinhoud via DATA wordt aangeboden. Het ontvangerantwoord bepaalt de toegestane route, maar is niet de enige beveiligingsbeslissing en nog geen definitieve berichtacceptatie.

Onbekende ontvanger weigeren

S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 550 5.1.1 User unknown
(connection closed - zero bytes of message body transferred)

Als ghost geen geldige bestemming heeft, kan de server met 550 weigeren. De voorbeeldtekst over sluiting vereenvoudigt het protocol: de verbinding kan openblijven voor andere ontvangers. Er is geen berichtinhoud nodig voor deze geweigerde ontvanger, maar SMTP-commando's en antwoorden zijn wel uitgewisseld.

Een catch-all-route gebruiken

S: EHLO mail.sender.com
S: MAIL FROM: <sender@sender.com>
S: RCPT TO: <ghost@yourdomain.com>
R: 250 OK
(full message body, headers, attachments transferred)
→ routed to catchall-bucket@yourdomain.com

De server staat de onbekende ontvanger toe. Daarna kunnen controles tijdens DATA nog tot weigering leiden. Pas bij definitieve acceptatie neemt hij verantwoordelijkheid voor verwerking en de gekozen opvangroute. De catch-all zelf is geen reden om ongewenste inhoud zonder beoordeling op te slaan.

Ontvangerweigering kan inhoudsverwerking vermijden. Toegelaten verkeer kan meer scans, tijdelijke opslag en indexering vragen, maar filters kunnen vóór definitieve acceptatie werken. Meet belasting en volume in plaats van te veronderstellen dat ieder verzoek volledig wordt opgeslagen.

De 5 aandachtspunten in productie

Catch-all verruimt de ontvangerselectie van je mailserver, niet een DNS-instelling die automatisch aanvallen uitlokt. Onderzoek de volgende risico's en de controles die je operationeel nodig hebt.

Risico 1: extra verkeer door adresprobes

Directory Harvest Attacks (DHA) proberen bestaande adressen te herkennen met namen als admin, david, invoice, hr, webmaster en noreply. Catch-all kan dat onderscheid via het ontvangerantwoord verbergen, terwijl de pogingen wel verkeer genereren.

Zonder catch-all kan een ongeldige ontvanger een 550-fout krijgen, maar de aanvaller hoeft niet te stoppen. Een voorbeeldsprong van 50 berichten per dag naar 50,000 laat zien waarom capaciteit en filtering aandacht vragen. Dit is een belastingsscenario, geen voorspelling voor ieder domein.

Risico 2: backscatter en verzendreputatie

Backscatter kan ontstaan door dit onveilige afhandelingspatroon:

1. Een spammer stuurt mail naar random-gibberish@yourdomain.com op een domein met catch-all.
2. Hij vervalst MAIL FROM, de envelopidentiteit die in een afleveringsheader Return-Path kan worden weergegeven, naar victim@gmail.com.
3. De server accepteert het bericht definitief via de catch-all-route.
4. Een latere scan vindt ongewenste inhoud en de gewone aflevering mislukt.
5. Een NDR wordt naar de envelopafzender gestuurd, weergegeven als Return-Path: victim@gmail.com.
6. Een onschuldige persoon ontvangt daardoor een ongevraagde melding.

Veel ongevraagde foutmeldingen kunnen de reputatie schaden of bijdragen aan een vermelding op ips.backscatterer.org. Dat is geen automatische uitkomst van catch-all. Gebruik passende SMTP-weigering of gecontroleerde quarantaine zonder reacties op vervalste afzenders. Lees ook oorzaken en herstel van domeinreputatieproblemen.

Risico 3: onduidelijke verantwoordelijkheid

Als partnerships@company.com in een algemene opvangmailbox belandt, moet duidelijk zijn wie het bericht behandelt. Zonder eigenaar en controleafspraak kan belangrijke mail blijven liggen. Dat vraagt procesinrichting, niet alleen technische routing.

Met een expliciete alias leg je de bestemming en verantwoordelijke vast. Voor partnerships@ hoeft dan niet achteraf te worden geraden wie moet handelen. Ook een opvangmailbox kan een aangewezen beheerder hebben.

Risico 4: supportlast voor dienstverleners

Bij 50+ klantdomeinen kunnen catch-all-routes aanleiding geven tot vragen zoals:

• "Mijn mailbox is vol en langzaam." Controleer quota en ongewenst volume.
• "Ik krijg te veel spam." Onderzoek filtering en ontvangerdekking.
• "Ik vind de klantmail niet." In een drukke opvangmailbox kan die op pagina 400 staan.
• "Mijn uitgaande mail belandt in Spam." Onderzoek reputatie, authenticatie en eventuele backscatter.

Een vermindering van 30-40% in mailboxvragen kan een illustratief planningsdoel zijn bij een overgang naar expliciete aliases, niet een gemeten algemene belofte. Vergelijk je eigen ticketcategorieën in de eerste maand met de situatie vóór de wijziging en bewaak legitieme routes.

Risico 5: persoonsgegevens en compliance

Artikel 5(1)(c) van de AVG verlangt gegevensminimalisatie voor de werkelijke doeleinden. Catch-all is niet automatisch in strijd met die eis, maar brede opvang kan extra persoonsgegevens verzamelen. Beoordeel noodzaak, toegang, bewaartermijnen en afhandeling van verzoeken binnen je eigen verwerking.

Een opvangmailbox met 500,000 spamberichten kan het terugvinden van persoonsgegevens bemoeilijken. Als mail naar doctor@yourclinic.com bij technische beheerders terechtkomt, beoordeel rollen, toegangsbevoegdheden, gegevensstromen, afspraken en waarborgen. HIPAA-toepasselijkheid of een overtreding volgt niet alleen uit IT-toegang; een bevoegde beoordeling is nodig.

SPF, DKIM en DMARC bij catch-all

Catch-all wijzigt de authenticatieprotocollen niet rechtstreeks. Bij forwarding zijn de gebruikte envelopidentiteit, ondertekende inhoud en From-afstemming bepalend. Backscatter en ongewenst doorgestuurd verkeer vragen daarnaast afzonderlijke reputatie- en beleidscontrole.

Forwarding voegt een relay toe die de ontvangende server beoordeelt. DMARC-rapportage is gekoppeld aan het zichtbare From-domein en schrijft niet iedere mislukking aan de forwarder toe. Google Postmaster Tools kan voor geschikte domeinen geaggregeerde signalen over persoonlijk Gmail tonen, geen volledig overzicht van alle mail. Spamklachten zijn gebruikersmeldingen, niet automatisch iedere authenticatiefout.

Het forwardingvraagstuk

Alle onbekende domeinmail naar persoonlijk Gmail sturen kan handig lijken, maar vraagt toestemming, filtering, inzicht en een gecontroleerde authenticatieroute. Mislukte aflevering is niet onvermijdelijk; onderzoek de werkelijke uitkomst voordat je op de route vertrouwt.

Waarom forwarding authenticatie kan beïnvloeden

De ontvanger ziet mail vanaf jouw relay-IP, terwijl het zichtbare From: nog de oorspronkelijke afzender kan noemen, zoals bank@chase.com. SPF beoordeelt de werkelijke MAIL FROM, niet dat zichtbare adres; DKIM en DMARC stellen andere eisen.

1. SPF: blijft de oorspronkelijke Chase-envelopidentiteit behouden, dan kan het relay-IP buiten diens SPF-toestemming vallen.
2. DKIM: wijziging van ondertekende inhoud, zoals een relevante footer of header, kan de verificatie breken; niet iedere bewerking heeft dat effect.
3. DMARC: als noch SPF noch DKIM slaagt met vereiste From-afstemming, past de ontvanger zijn beleid toe, bijvoorbeeld weigering of quarantaine.

Een bericht kan worden geweigerd, gefilterd, vertraagd of soms zonder zichtbare melding verdwijnen. Dat is geen vaste uitkomst bij p=reject. Gebruik headers, traces en SMTP-antwoorden voor diagnose. De gids voor forwardinginstellingen en foutonderzoek geeft verdere controles.

Forwarding met SRS en ARC

Als een migratie of bestaande workflow forwarding nodig heeft, beoordeel de route. SRS kan de envelopidentiteit herschrijven en ARC kan eerdere authenticatiegegevens ondertekend doorgeven. Ze lossen verschillende problemen op en zijn geen universele garantie of verplichte combinatie voor iedere DMARC-pass.

SRS (Sender Rewriting Scheme)

SRS herschrijft de envelopafzender naar een domein van de relay, mogelijk jouw domein. De SPF-record van het werkelijk gebruikte herschreven domein moet het relay-IP toestaan.

Vóór SRS
Envelope From: alice@example.com

Na SRS
Envelope From: SRS0=HASH=TT=example.com=alice@your-forwarder.com

De ontvanger beoordeelt SPF voor your-forwarder.com. Alleen als de juiste instellingen de gebruikte IP toestaan, kan SPF voor die identiteit slagen.

SRS garandeert geen DMARC-afstemming. Het zichtbare From: kan alice@example.com blijven, terwijl de envelop your-forwarder.com gebruikt. Die identiteiten zijn niet vanzelf afgestemd. Een geldige oorspronkelijke DKIM-handtekening die met From is afgestemd kan DMARC laten slagen. Veranderingen aan ondertekende delen kunnen die handtekening aantasten. Lees SRS-emailforwarding voor de details.

ARC (Authenticated Received Chain)

ARC laat een tussenliggende dienst ondertekende authenticatiegegevens en seals toevoegen. Daarmee kan de ontvanger onderzoeken wat eerdere servers controleerden, ook wanneer forwarding de latere beoordeling beïnvloedt.

Ontvangers zoals Gmail en Microsoft kunnen een gevalideerde ARC-keten meewegen als zij de geverifieerde sealer vertrouwen. RFC 8617 beschrijft het protocol. ARC dwingt geen DMARC-pass, inboxplaatsing of acceptatie af.

Goede reputatie alleen bewijst geen geldige ARC-keten of vertrouwde identiteit. Onderzoek cryptografische validatie, de werkelijk ondertekenende dienst en het lokale ontvangerbeleid. Vermijd ongewenste forwarding en backscatter, maar veronderstel niet dat die verbeteringen automatisch ARC-vertrouwen opleveren.

Catch-all met passende controles instellen

Een migratie, oude koppeling of typefoutherstel kan catch-all rechtvaardigen. Kies een beperkt, beheerd doel en een duidelijke verantwoordelijke. De volgende drie benaderingen hebben verschillende gevolgen; geen ervan biedt volledige isolatie of gegarandeerde veiligheid.

Strategie A: afgeschermde opvangmailbox

Gebruik waar passend een aparte opvangmailbox met beperkt toegangsrecht. Behandel onbekend verkeer niet als automatisch veilig omdat het in een aparte map staat.

1. Maak een aparte mailbox: catchall-quarantine@yourdomain.com. Geef alleen noodzakelijke ontvangst- en toegangsrechten, geen ongewenste "Send As"-rechten.
2. Routeer onbekende ontvangers van het bevoegde domein naar die mailbox, met filtering en zonder automatische forwarding of antwoorden.
3. Bij Microsoft 365 vraagt SCL 9 om classificatie als spam met hoge zekerheid. De werkelijke classificatie en actieve policy bepalen Spam of quarantaine en meldingen; stel die score niet blind voor alle mail in.
4. Plan bijvoorbeeld wekelijkse beoordeling en een procedure voor gemelde typefouten, met tijdige afhandeling volgens bedrijfsbehoefte.

Controleer in TrekMail hoe je een aparte mailbox, zoekfunctie en eventuele filterweergaven gebruikt. Een filtered view is geen beveiligingsgrens en gedeelde quota kunnen andere mailboxen raken. Beperk toegang en behoud legitieme mail volgens passend bewaarbeleid.

Strategie B: Microsoft 365, DBEB en Internal Relay

Voor Authoritative-domeinen met een volledige ontvangerdirectory kan DBEB (Directory-Based Edge Blocking) onbekende ontvangers vóór berichtinhoud weigeren. Controleer de actieve domeinmodus en alle geldige ontvangers; deze keuze moet bij de werkelijke topologie passen.

Internal Relay Mode schakelt DBEB voor dat domein uit, maar maakt op zichzelf geen catch-all. Connectoren, downstream ontvangers, routing en luspreventie moeten correct worden ingericht. Laat een bevoegde beheerder de mailtopologie beoordelen voordat een wijziging wordt gedaan, en controleer belasting en aflevering.

Strategie C: beperkte adrespatronen in Postfix

Een patroonroute kan een beperkt adresbereik bieden, maar het volgende voorbeeld werkt niet als wildcard in een gewone hash-map. Zo'n map gebruikt letterlijke sleutels. Behoud het voorbeeld alleen als illustratie van de gewenste route en kies een daadwerkelijk ondersteund maptype.

# /etc/postfix/virtual
sales-*@yourdomain.com    sales-bucket@yourdomain.com

Voor sales-q1@, sales-webinar@ en sales-2026@ is een correct verankerde regexp- of PCRE-map met domeinafbakening nodig. Ongewenste admin@, hr@ en andere adressen mogen niet per ongeluk dezelfde route krijgen. Controleer ontvangerselectie, bestemmingen en maillussen na een proefwijziging.

Aliases en expliciete routing

Als de nodige adressen bekend zijn, zijn aliases vaak een gerichte basis. Ze beperken onbekende ontvangers en verduidelijken bestemming en eigenaar. Spam, forwardingauthenticatie en persoonsgegevens blijven aandachtspunten; aliases verwijderen die risico's niet volledig.

Alias, mailbox of catch-all: keuzehulp

Een goedkope opvangroute kan kosten voor filtering, opslag en support meebrengen. Reputatieherstel kan nodig zijn als er werkelijk misbruik of backscatter is opgetreden, maar is niet altijd het gevolg. Lees emailaliases: betekenis, inrichting en gebruik voor de keuze tussen alias en mailbox.

Welke adressen je kunt aanmaken

Breng je werkelijk gebruikte adressen in kaart. Deze vijf voorbeelden zijn een startpunt, geen limiet voor iedere organisatie:

• hello@ of info@: algemene vragen naar een bevoegde werkmailbox
• support@: klantenservice naar helpdesk of gedeelde mailbox
• billing@: facturen en betalingen naar finance
• jobs@ of careers@: sollicitaties naar HR of een gecontroleerde ATS-koppeling
• noreply@: transactionele afzender; bepaal bewust hoe legitieme antwoorden veilig worden behandeld

Vijf aliases kunnen een eenvoudige adresstructuur dekken, maar niet iedere catch-all-behoefte. Voor een onbekende helo@ in plaats van hello@ kan de server een 550-fout geven; de verzendende dienst bepaalt de melding. Dat kan helpen de fout te herkennen in plaats van een bericht drie weken ongelezen te laten. Je kunt voor waargenomen typefouten gerichte aliases maken zonder alle onbekende adressen toe te laten.

TrekMail beoordelen voor catch-all

Controleer catch-all-ondersteuning, rechten en limieten van je actuele TrekMail-plan. Het abonnementsmodel kan gerichte mailboxen aantrekkelijker maken, maar de behoefte aan opvang hangt ook van migratie, adresdekking en bestaande workflows af.

Het historische gebruikerslicentievoorbeeld

Bij $6-30 per maand per aparte licentie kunnen support@, billing@ en jobs@ in het voorbeeld samen maximaal $90 per maand extra kosten. Controleer of aliases of gedeelde mailboxen die licenties kunnen vermijden. Kostenbesparing is geen reden om noodzakelijke routing- of beveiligingscontroles over te slaan.

Het TrekMail-model

Gedeelde opslag en mailboxrechten binnen een abonnement kunnen de keuze veranderen. Controleer actuele reikwijdte, quota en eventuele kosten per adres. Historische referenties noemen Starter voor $3.50 per maand met 50 domeinen en Pro voor $10 per maand met 100 domeinen. Dat zijn geen beloften van huidige limieten of onbeperkte mailboxen. In het beschreven Nano-model is eigen externe SMTP vereist voor alle uitgaande berichten en antwoorden.

Voor een migratie of oude route kun je waar ondersteund een aparte opvangmailbox gebruiken. Beperk toegang en voorkom ongewenste forwarding en automatische antwoorden. Dit is geen volledige beveiligingsisolatie en gedeelde capaciteit kan andere mailboxen raken. Lees de TrekMail-documentatie voor catch-all-inboxen.

Controleer ook ondersteuning voor forwarding naar meerdere bestemmingen en een lokale kopie. Een externe catch-all-bestemming op Pro of Agency kan onder actuele voorwaarden een optie zijn voor een beheerd maar onbezet domein. Dat vraagt toestemming, authenticatie en gegevensbeheer, niet alleen een adreskeuze. Zie een domein naar een externe opvangbestemming routeren.

Bekijk een eventuele proefperiode van 14 dagen en de actuele kaart- en planvoorwaarden voordat je migreert.

Veelgestelde vragen

Deze antwoorden helpen bij het beoordelen, inrichten of uitschakelen van catch-all. Verifieer productafhankelijke stappen in de actuele interface.

Wat is catch-all-mail?

Catch-all is een mailserverroute voor onbekende ontvangers op een domein. In plaats van een 550-fout kan zo'n ontvanger een opvangbestemming krijgen. Accept-all en wildcardrouting zijn veelgebruikte namen, maar controles en bestemmingen verschillen per implementatie.

Is catch-all veilig te gebruiken?

Dat hangt af van doel en inrichting. Beperk toegang, behoud filtering en leg verantwoordelijkheid en bewaarbeleid vast. Een aparte opvangmailbox is geen sandbox. Gebruik geen blinde maximale spamscore of starre beoordelingstermijn die legitieme mail negeert.

Kan catch-all uitgaande aflevering beïnvloeden?

Indirect, bijvoorbeeld door backscatter naar vervalste envelopafzenders of ongewenste relaymail. Dat is niet automatisch. DMARC-rapporten gaan over het zichtbare From-domein en niet noodzakelijk over de forwarder. Onderzoek reputatie, echte authenticatieresultaten en ontvangerbeleid afzonderlijk.

Wat is het verschil met een emailalias?

Een alias geeft een expliciet adres een gekozen bestemming. Catch-all geeft ieder onbekend ontvangeradres binnen zijn bereik een opvangroute. Aliases beperken de selectie; beide vragen filtering en duidelijk beheer. Vijf gerichte aliases kunnen een kleine organisatie helpen, maar dekken niet alle mogelijke behoeften.

Kan catch-all op Google Workspace of Microsoft 365?

Google Workspace biedt productgebonden routingregels voor onbekende ontvangers. Bij Microsoft 365 moeten geaccepteerde domeinen, connectoren, ontvangerdirectory en regels samen worden beoordeeld. Internal Relay schakelt DBEB uit, maar is op zichzelf geen catch-all-configuratie. Laat een bevoegde beheerder de topologie en luspreventie controleren. Licenties, aliases en gedeelde mailboxen hebben afzonderlijke voorwaarden.

Hoe schakel ik catch-all uit?

Controleer eerst alle geldige adressen en routes. Open in cPanel Home → Email → Default Address en kies "Discard with error to sender" voor weigering tijdens SMTP; de geavanceerde optie "Discard" verwijdert daarentegen stil. In Google Workspace beoordeel je Apps → Google Workspace → Gmail → Routing, of Default routing voor een bestaande oudere regel. Bij Microsoft 365 is Authoritative passend wanneer de ontvangerdirectory compleet is en connectoren zijn gecontroleerd. In TrekMail controleer je Domains → [domain] → Routing, of Connection in oudere interfaces, en Catch-all Inbox → "No catch-all". Plan bijvoorbeeld 24-48 uur voor verificatie van mailstromen, geen universele deadline voor stabiliteit.

Wat kan ik in plaats van catch-all gebruiken?

Begin met expliciete aliases, mailboxen en eigenaarschap voor bekende adressen. Vijf of minder adressen kunnen een klein scenario dekken, maar kies volgens je echte bedrijfsprocessen. Vergelijk actuele licenties en opslagmodellen zonder te veronderstellen dat een andere provider automatisch alle authenticatie-, reputatie- of routingproblemen oplost.