Catch-all voor je domein: inrichting, risico’s en controles

Je schakelt een catch-all voor je domein in om geen aanvragen te missen als iemand saels@ schrijft in plaats van sales@. Begrijpelijk. Maar de server kan nu ook onbekende ontvangers accepteren, inclusief automatische spamproeven. Ongewenste foutmeldingen naar vervalste afzenders, lussen door automatische antwoorden en problemen bij doorsturen zijn risico's om te beheersen, geen onvermijdelijke uitkomst. Een catch-all vraagt om passende inrichting en controles.

Veel gidsen stoppen bij “catch-all inschakelen en naar de inbox sturen”. Hier behandelen we juist een quarantainemailbox, Postfix-patronen, luspreventie en mogelijke authenticatieproblemen bij extern doorsturen. Lees voor de basis de gids voor e-mail doorsturen instellen; dit artikel gaat specifiek over catch-all-routing.

Wat is een catch-all voor een domein?

Een catch-all is een mailserverregel voor adressen die niet overeenkomen met een mailbox, alias, groep of andere ingestelde bestemming. In plaats van 550 User Unknown kan de server bij het ontvangercommando 250 OK geven en de mail naar een terugvalbestemming leiden. Acceptatie van de ontvanger is nog geen definitieve acceptatie van de berichtgegevens. De regel verandert de ontvanger in de SMTP-envelop en verstoort op zichzelf geen afzenderauthenticatie.

Envelop en berichtheader: waarom het onderscheid telt

Het onderscheid tussen beide lagen helpt bij routing en authenticatie. Niet elk catch-all-probleem komt hierdoor. Dagen onderzoek tegenover een ingreep van twee minuten is een illustratief contrast, geen voorspelling: de benodigde oplostijd hangt van de werkelijke oorzaak af.

RFC 5321 beschrijft de SMTP-envelop met de opdrachten RCPT TO en MAIL FROM tijdens de sessie. RFC 5322 beschrijft de berichtheaders, waaronder de zichtbare velden To: en From:.

Een catch-all kan een onbekende envelopontvanger naar een andere bestemming omzetten zonder de berichtheaders te wijzigen. SPF beoordeelt het IP-adres voor MAIL FROM, of waar toepasselijk HELO. DKIM verifieert de cryptografische handtekening van ondertekende berichtdelen. DMARC slaagt bij ten minste één geslaagde SPF- of DKIM-controle met domeinafstemming op de zichtbare From. Alleen de ontvanger omzetten laat die controles niet automatisch mislukken. Een externe doorstuurstap kan daarentegen het IP-adres van de verbinding veranderen en SPF verstoren.

Het mogelijke probleem bij doorsturen

Een catch-all doorsturen naar Gmail of Outlook.com voegt een SMTP-stap toe. Dit voorbeeld toont een mogelijke fout, geen vaste uitkomst:

1. Oorspronkelijke afzender: client@bank.com (IP: 1.2.3.4)
2. Je server accepteert typo@yourdomain.com en stuurt door naar you@gmail.com
3. Gmail ziet het IP-adres van jouw server terwijl de envelopafzender bank.com blijft gebruiken
4. SPF mislukt als bank.com jouw IP niet toestaat
5. Met DMARC p=reject en zonder geldige, afgestemde DKIM kan de ontvanger weigeren; de verzender kan een bezorgfoutmelding ontvangen

De catch-all vangt het verkeerde adres op, maar doorsturen kan een ander probleem toevoegen. Overweeg SRS (Sender Rewriting Scheme) of een dienst die de herschrijving beheert. SRS herstelt geen afstemming met de oorspronkelijke From en garandeert geen aflevering. De beschreven aliasdoorsturing van TrekMail omvat serverbeheer op ondersteunde routes en abonnementen; controleer het actuele aanbod.

Drie risico's van een catch-all

Backscatter, automatische antwoordlussen en SPF/DMARC-problemen bij doorsturen zijn drie belangrijke aandachtspunten. Beoordeel ze samen voordat je instellingen verandert: een afzonderlijke oplossing kan anders een nieuw probleem veroorzaken. Een taak van vijf minuten die een week herstelwerk oplevert is een waarschuwend voorbeeld, geen vaste doorlooptijd.

1. Backscatter: een reputatierisico

Backscatter kan ontstaan als je een bericht na de berichtgegevens definitief accepteert met 250 OK, het later niet aflevert en een foutmelding naar MAIL FROM stuurt. Is dat adres vervalst, dan ontvangt een onbetrokken persoon de melding. Dat ongewenste verkeer kan de reputatie schaden en bijdragen aan blokkeerlijsten, maar plaatsing binnen enkele dagen is niet onvermijdelijk.

Weiger niet-toegestane ontvangers tijdens de SMTP-sessie vóór de relevante 250 OK, of verwerk geaccepteerde mail in een gecontroleerde quarantaine. Vermijd ongevraagde foutmeldingen naar vervalste of niet-verifieerbare afzenders. Dat is geen algemeen verbod op legitieme bezorgfouten en geen reden om geldige mail standaard stil te verwijderen.

2. Automatische antwoordlussen (Exchange-fout 5.4.14)

De catch-all levert af bij een mailbox met een afwezigheidsantwoord. Spam voor random@yourdomain.com veroorzaakt een antwoord naar een vervalste afzender. Afhankelijk van routing en bescherming kunnen foutmeldingen en antwoorden bij random@yourdomain.com terugkomen en een lus vormen. Exchange kan dan 550 5.4.14 Hop count exceeded - possible mail loop melden. Niet ieder automatisch antwoord veroorzaakt zo'n route.

Overweeg op ondersteunde Exchange-systemen X-Auto-Response-Suppress: All voor catch-all-verkeer. Controleer welke antwoorden, aflevermeldingen en leesbevestigingen werkelijk worden onderdrukt. Het gedrag is niet universeel en deze header vervangt geen afzonderlijke lusbeveiliging.

3. Directory Harvest Attacks (DHA)

Als ieder ontvangeradres 250 OK oplevert, kunnen spammers duizenden combinaties proberen, zoals admin@, hr@, ceo@ en invoice@. Een catch-all toont dat de server die adressen accepteert, niet welke echte mailboxen bestaan. Dat kan meer spam opleveren, mogelijk jarenlang, maar bevestigt geen lijst met daadwerkelijk aangemaakte mailboxen of een vaste duur van aanvallen.

Een mogelijke beperking is alleen specifieke patronen accepteren, zoals in strategie 2.

Strategie 1: een aparte quarantainemailbox

Behandel onbekend verkeer voorzichtig en overweeg een aparte bestemming in plaats van je primaire inbox. Een quarantainemailbox is geen beveiligingssandbox: beperk toegang, pas filters toe en controleer dat doorsturing en automatische antwoorden uitstaan. Zo kun je bruikbare mail apart beoordelen, maar de mailbox alleen garandeert geen bescherming van je verzendreputatie.

Verwerkingsschema:

1. Accepteren: de server verwerkt *@domain.com volgens de gekozen regels
2. Herkennen: onderscheid onbekende ontvangers van mailboxen, aliassen, groepen en andere geldige bestemmingen
3. Scheiden: stuur naar een aparte mailbox zoals catchall_sink@domain.com
4. Onderdrukken: overweeg Spam Confidence Level (SCL) 9 en X-Auto-Response-Suppress: All waar ondersteund

Je kunt wekelijkse controle plannen en de frequentie aanpassen aan volume en urgentie. Verplaats geldige berichten naar de juiste mailbox en behandel overige mail volgens beleid. Bewaak capaciteit, bewaartermijnen en toegang: een vergeten quarantainemailbox kan juist de aanvragen verliezen die je wilde behouden.

Transportregel voor Microsoft 365 / Exchange Online

Verander M365-instellingen niet blind. Internal Relay schakelt Directory Based Edge Blocking (DBEB) uit, maar implementeert op zichzelf geen catch-all. Gebruik dit domeintype alleen bij de bijbehorende, bevoegde topologie met een connector naar de bedoelde eigen mailserver voor overige ontvangers, niet wanneer alle ontvangers uitsluitend hier worden gehost. Beoordeel de volledige lijst geldige ontvangers; groepslidmaatschap alleen bepaalt niet of iemand onbekend is. De onderstaande regel is een conceptueel schema om aan te passen en te testen, geen universeel stappenplan:

Plan en test regel en route voordat je het domeintype wijzigt. Volgorde en uitvoering hangen van de bestaande inrichting af. Voorkom dat de overgang naar Internal Relay een periode zonder de afgesproken controles creëert.

Strategie 2: beperkte patronen met Postfix PCRE

Een beperkt patroon vangt bepaalde adresgroepen op zonder iedere woordenboekvariant te accepteren. Definieer verwachte patronen en controleer dat ontvangers daarbuiten via SMTP-validatie worden geweigerd. Geen wildcard in de map betekent op zichzelf niet automatisch afwijzen. Dit beperkt het geaccepteerde adresbereik, zonder te garanderen dat de meeste aanvallen worden geblokkeerd.

Een mogelijke Postfix virtual alias map gebruikt PCRE (Perl Compatible Regular Expression). Controleer of PCRE-mapondersteuning geïnstalleerd is en test de patronen, inclusief de typefouten die je wilt opvangen en de bestaande ontvangerklassen:

# /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

Controleer de integratie in /etc/postfix/main.cf. De volgende regel vervangt de bestaande waarde. Bewaar de configuratie en voeg de map zorgvuldig samen met bestaande maps in plaats van die ongecontroleerd te overschrijven.

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

Plan na tests en goedkeuring het herladen: postfix reload

Overweeg voor extra bereik voorzichtige patronen voor bekende adressen in plaats van een globale catch-all:

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

Zo kun je verwachte adressen verwerken zonder iedere combinatie als acceptabel te presenteren. De uitkomst hangt ook van ontvangerklassen, andere maps en validatieregels af.

Wanneer een catch-all geschikt is

Een catch-all kan passen bij afgebakende situaties, ook langdurig als daar een duidelijke reden en passende controle voor zijn. Hieronder drie voorbeelden en een reden om anders te beoordelen.

Zinvolle toepassingen:

• Kortlopende campagneadressen: promo-jan@, promo-feb@ en promo-mar@ verwerken zonder ieder adres handmatig aan te maken
• Nieuwe klanten inrichten: mail opvangen voordat alle adressen zijn geconfigureerd
• Migratie van een oud systeem: tijdens de overgang actieve adressen opvangen die nog niet volledig zijn geïnventariseerd

Plan in deze drie gevallen een beperkte gebruiksduur. Maak bekende adressen daarna als mailboxen of aliassen aan en beoordeel of de catch-all uit kan. Lees voor de adresstructuur de vergelijking van domeinaliassen en mailboxen.

Een reden om te heroverwegen: $6 per gebruiker per maand voor drie aliassen vermijden. Een alias vereist niet automatisch een betaalde licentie; controleer het model van je provider. Pak een prijsprobleem rechtstreeks aan in plaats van beheercomplexiteit toe te voegen die zes maanden later nog kan doorwerken.

TrekMail: adresbeheer bewust inrichten

Kosten per gebruiker kunnen een reden zijn om een catch-all te gebruiken in plaats van expliciete adressen. TrekMail biedt accountabonnementen met gedeelde opslag en domein- en mailboxlimieten, geen algemene afzonderlijke prijs per domein. Controleer de actuele voorwaarden om de werkelijke kosten van mailboxen en aliassen te vergelijken.

Het historische Starter-voorbeeld ($3.50 per maand) illustreert adresbeheer binnen abonnementsgrenzen; controleer actuele prijzen en functies. Een ondersteunde catch-all vervangt geen expliciete dagelijks gebruikte adressen. In het beschreven Nano-model vereist elk uitgaand bericht, inclusief antwoorden, je eigen externe SMTP; beheerde verzending in betaalde plannen hangt van de rechten af. Voor migratie zijn bevoegde brontoegang, compatibiliteit, kopiecontrole en een laatste synchronisatie nodig; contacten en agenda's vragen een afzonderlijke controle. De gids voor e-mail op je domein instellen behandelt DNS, SPF/DKIM/DMARC en mailboxen.

Checklist voor inschakelen

Controleer de volgende punten voordat je een catch-all activeert. Ontbrekende controles kunnen bezorgproblemen en extra werk veroorzaken:

1. SMTP-validatie actief: weiger ontvangers buiten geaccepteerde patronen tijdens de sessie. Verwerk geaccepteerde mail zonder ongewenste foutmeldingen naar vervalste afzenders.
2. Automatische antwoorden beheerst: overweeg X-Auto-Response-Suppress: All op ondersteunde systemen en test de werking. Gebruik ook lusbeveiliging die niet van deze header afhangt.
3. Quarantaine gereed: een aparte mailbox voor onbekend verkeer, los van operationele inboxen, met passende capaciteit en toegang.
4. Classificatie en controle afgesproken: pas voorzichtig beleid toe en beoordeel berichten bewust om geldige mail terug te vinden.
5. SPF/DMARC gecontroleerd: controleer bij SRS of het SPF-beleid van de werkelijk herschreven envelopafzender het verbindings-IP toestaat. DMARC vraagt ten minste één geslaagde, afgestemde SPF- of DKIM-controle; intacte afgestemde DKIM kan zonder SRS slagen. SRS alleen herstelt geen afstemming op de oorspronkelijke From.
6. Beperkte patronen vóór een globale wildcard: gebruik waar ondersteund specifieke matches en test de ontvangercontrole.
7. Backscatter voorkomen: stuur geen ongevraagde foutmeldingen naar vervalste afzenders. Bewaar en beoordeel mogelijk geldige mail volgens beleid in plaats van die standaard stil te verwijderen.

Conclusie

Een catch-all kan nuttig zijn met gecontroleerde bestemmingen, SMTP-validatie, luspreventie en zorgvuldige foutafhandeling. Zonder die maatregelen kunnen backscatter en doorstuurproblemen toenemen, maar niet onvermijdelijk binnen enkele weken. Leg vooraf capaciteit, controle en beheerverantwoordelijkheid vast.

Gebruik je een catch-all om kosten per gebruiker te vermijden, vergelijk dan eerst de werkelijke prijzen en voorwaarden. TrekMail-abonnementen kunnen mailboxen en aliassen binnen hun limieten bieden, zodat de catch-all een bewuste keuze blijft. Bekijk de gratis proefperiode, controleer de actuele voorwaarden en richt je domein met passende controles in.