Een catch-all-adres vangt mail voor onbekende ontvangers op je domein op. Iemand schrijft slaes@yourcompany.com in plaats van sales@. Een catch-all kan die typefout naar een gekozen mailbox leiden, zodat een aanvraag niet alleen door het onbekende adres wordt geweigerd. Dat is handig, maar zegt nog niets over de overige controles of uiteindelijke aflevering.
Die vangnetfunctie verruimt de ontvangerselectie. Ook verzonnen adressen kunnen mail ontvangen, wat extra spam, opslag en beheer kan opleveren. Backscatter ontstaat alleen bij een onveilig afhandelingspatroon na acceptatie; SPF-problemen kunnen bij forwarding optreden, niet door de catch-all zelf.
Deze gids behandelt SMTP-gedrag, drie operationele aandachtspunten en alternatieven voor gerichte adresdekking. Lees voor routing en inrichting ook domein-catch-all instellen met behoud van controle.
Wat is een catch-all-adres?
Een catch-all, ook wildcardadres genoemd, is een serverinstelling voor mail aan onbekende ontvangers binnen je domein. De server kan op RCPT TO "250 OK" antwoorden waar hij anders "550 User unknown" zou geven. De onbekende adressen worden naar een aangewezen bestemming gerouteerd. Dit ontvangerantwoord is nog geen definitieve acceptatie van de volledige boodschap na DATA; andere controles kunnen blijven gelden.
Onbekende ontvangers al tijdens SMTP weigeren, vóór de overdracht van de berichtinhoud, wordt hier fail-closed genoemd. De catch-all verruimt die ontvangercontrole, hier fail-open genoemd. Dat betekent niet dat alle beveiligingscontroles worden uitgeschakeld. Een legitieme typefout en mail naar een verzonnen adres kunnen wel dezelfde opvangroute gebruiken.
Dat kan nuttig zijn bij een migratie. Voor blijvend gebruik zijn duidelijke doelen, passende filtering en beheer nodig.
Hoe een catch-all op SMTP-niveau werkt
Het verschil begint bij RCPT TO, beschreven in RFC 5321. De server beoordeelt de ontvanger voordat de berichtinhoud via DATA wordt verstuurd. De voorbeelden hieronder vereenvoudigen het verdere verloop: een geweigerde ontvanger verplicht de server niet de verbinding te sluiten, en een geaccepteerde ontvanger garandeert geen uiteindelijke berichtacceptatie.
Zonder catch-all: fail-closed ontvangercontrole
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 550 5.1.1 User unknown
RESULT: Connection closed. Zero data transferred.
De verzendende server krijgt een ontvangerfout en kan de afzender volgens eigen beleid informeren; dat hoeft geen onmiddellijke retourmail te zijn. Voor deze geweigerde ontvanger hoeft geen berichtinhoud te worden aangenomen. Er zijn wel SMTP-commando's en antwoorden uitgewisseld, dus de voorbeeldtekst over geen data slaat alleen op de berichtinhoud.
Met catch-all: ruimere ontvangeracceptatie
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.
De ontvanger is toegestaan, maar de server kan de boodschap tijdens de verdere SMTP-afhandeling nog toetsen. Na uiteindelijke acceptatie moet hij opslag en verwerking verzorgen, ook als de inhoud ongewenst is. Gebruik filtering en veilige afhandeling zonder achteraf automatisch meldingen naar vervalste afzenders te sturen.
Drie operationele aandachtspunten bij catch-all
Onderzoek extra verkeer naar verzonnen adressen, mogelijke backscatter bij onveilige foutafhandeling en authenticatie bij forwarding. Deze gevolgen zijn niet onvermijdelijk: routing, SMTP-beleid en filtering bepalen het werkelijke risico.
1. Directory Harvest Attacks (DHA)
Spammers kunnen automatisch duizenden gebruikelijke adresnamen proberen, zoals admin, invoice, hr, accounts, david, noreply, info en billing. Zij proberen zo bestaande adressen te herkennen of ongewenste berichten af te leveren.
Zonder catch-all kunnen onbekende adressen een 550-fout opleveren, maar dat verplicht een aanvaller niet te stoppen. Met catch-all kan een onbekende ontvanger 250 OK krijgen. Dat bemoeilijkt onderscheid op basis van alleen ontvangerantwoorden, terwijl extra verkeer wel opslag en filters kan belasten. Legitieme berichten kunnen tussen duizenden ongewenste berichten aan verzonnen adressen terechtkomen.
2. Backscatter en reputatierisico
Backscatter kan ontstaan wanneer een server mail definitief accepteert en daarna een foutmelding naar een vervalste envelopafzender stuurt. Zulke ongevraagde meldingen kunnen reputatieschade of een vermelding bij blocklists zoals ips.backscatterer.org veroorzaken. Een catch-all alleen maakt die uitkomst niet onvermijdelijk.
Een mogelijk onveilig verloop:
- Een spammer stuurt malware naar random@yourdomain.com met innocent@gmail.com als vervalste MAIL FROM
- De catch-all-route laat de onbekende ontvanger toe en de server accepteert uiteindelijk het bericht
- Een latere scan ontdekt malware en de server kan het bericht niet volgens de gewone route afleveren
- De server stuurt een Non-Delivery Report (NDR) naar innocent@gmail.com
- Een onschuldige Gmail-gebruiker krijgt zo een ongevraagde melding voor mail die hij niet heeft verstuurd
Veel van deze meldingen kunnen je reputatie schaden. Wijs waar passend tijdens SMTP af of gebruik gecontroleerde quarantaine, zonder automatische bounces of antwoorden naar vermoedelijk vervalste afzenders.
3. Forwarding en SPF
Sommige beheerders sturen een catch-all, bijvoorbeeld *@company.com, door naar persoonlijk Gmail. Naast toestemming en gegevensbeheer vraagt die relayroute aandacht voor authenticatie. De catch-all op zichzelf verandert SPF niet.
Bij gewone forwarding komt de mail vanaf je relay-IP terwijl MAIL FROM nog het oorspronkelijke domein kan gebruiken, bijvoorbeeld bankofamerica.com. SPF kan falen als dat domein je IP niet toestaat. SRS-forwarding (Sender Rewriting Scheme) herschrijft de envelop; SPF van het herschreven domein moet de relay daadwerkelijk toestaan. Dat levert niet automatisch afstemming op het oorspronkelijke From-adres op. Intacte, geldige en afgestemde DKIM kan DMARC ook zonder SRS of ARC laten slagen. ARC vraagt echte ketenvalidatie en vertrouwen in de geverifieerde sealer; Gmail beslist zelf over acceptatie en plaatsing.
Alternatieven voor een catch-all
Voor vooraf bekende adressen zijn expliciete aliases vaak eenvoudiger te beheren. Plusadressering kan tags binnen een bestaande mailbox bieden als de provider dit ondersteunt. Kies op basis van je adresbehoefte; geen van deze modellen garandeert dat spam wegblijft.
| Onderdeel | Catch-all | Expliciete aliases | Plusadressering |
|---|---|---|---|
| Notatie | *@domain.com | sales@domain.com | user+tag@domain.com |
| Ontvangercontrole | Onbekende adressen volgen opvangroute | Onbekende adressen kunnen worden geweigerd | Onbekende basisadressen kunnen worden geweigerd |
| Spamrisico | Extra verkeer naar verzonnen adressen mogelijk | Beperkte adresdekking; filtering blijft nodig | Tags beperken niet alle ongewenste mail |
| TrekMail-kosten | Actuele ondersteuning en plan controleren | Actuele rechten en limieten controleren | Actuele ondersteuning en voorwaarden controleren |
Met expliciete aliases leg je vast welke adressen geldig zijn en kun je de overige ontvangers tijdens SMTP weigeren. Kies een alias voor routing naar bestaande bestemmingen en een mailbox wanneer eigen opslag of aanmelding nodig is. Lees aliasforwarding en domeinalias versus mailbox.
Kosten als reden voor catch-all opnieuw beoordelen
Licentiekosten kunnen een rol spelen. Bij een historische prijs van $6 per gebruiker per maand kosten afzonderlijk gelicentieerde sales@, support@ en billing@ samen $18 per maand. Suites bieden echter ook aliases of gedeelde mailboxen onder eigen voorwaarden; niet ieder functioneel adres vraagt een aparte gebruikerslicentie. Onderzoek die mogelijkheden voordat je alle onbekende adressen opvangt.
TrekMail beschrijft een model met gedeelde opslagcapaciteit op accountniveau. Dat kan ruimte bieden voor meerdere mailboxen binnen planlimieten. Controleer de accountquota, eventuele individuele limieten, mailboxrechten en kosten; extra mailboxen zijn niet los van alle voorwaarden onbeperkt beschikbaar.
| Historisch voorbeeld per gebruiker | TrekMail: historische referentie | |
|---|---|---|
| 3 functionele mailboxen | $18/maand in het Workspace-voorbeeld | $3.50/maand als Starter-referentie |
| 50 mailboxen | $300/maand in het licentievoorbeeld | $3.50/maand als referentie, voorwaarden controleren |
| Catch-all nodig als omweg? | Nee; aliases en gedeelde mailboxen kunnen opties zijn | Niet noodzakelijk als benodigde adressen binnen het plan passen |
| SMTP-ontvangercontrole | Kan onbekende ontvangers weigeren | Controleer de ingestelde ontvanger- en catch-all-regels |
De historische Starter-beschrijving noemt $3.50 per maand, maximaal 50 domeinen en 100 mailboxen per domein. Controleer huidige prijzen, rechten en limieten voordat je hiermee plant. Richt sales@, support@, billing@, info@ en andere noodzakelijke adressen bewust in, met passende ontvangercontrole en toegangsrechten.
Een afgeschermde opvangmailbox als catch-all nodig is
Tijdens een migratie kan de oude adreslijst onvolledig zijn. Een aparte opvangmailbox helpt dan onbekende maar legitieme adressen te vinden. Dat is geen beveiligingssandbox: beperk toegang, houd filtering actief en voorkom automatische forwarding en antwoorden.
- Maak een aparte mailbox: catchall-quarantine@yourdomain.com, los van persoonlijke werkmail.
- Richt de opvangroute in: stuur onbekende ontvangers alleen naar deze gecontroleerde bestemming.
- Beperk meldingen: voorkom verstoring en automatische reacties; markeren als lage prioriteit vervangt geen filtering of toegangsbeperking.
- Beoordeel wekelijks: maak na verificatie een expliciete alias voor een werkelijk benodigd adres.
- Plan een evaluatiemoment: 30 dagen zonder legitieme treffer kan een voorbeeldcriterium zijn om de catch-all uit te schakelen, na controle van bedrijfsprocessen en bewaarbeleid.
Zo gebruik je catch-all als beheerd hulpmiddel om oude routes te onderzoeken. Leg gevonden adressen vast en sluit de opvangroute wanneer het doel is bereikt, tenzij een afzonderlijk beoordeelde permanente behoefte blijft bestaan.
Voor bureaus: gerichte adresdekking op veel domeinen
Bij 100+ domeinen kost het handmatig maken van standaardaliases tijd. Standaardiseer de adresstructuur en gebruik alleen daadwerkelijk beschikbare, gedocumenteerde bulkacties; ga niet uit van een domeinoverschrijdende knop voor aliastemplates. Pas postmaster@, abuse@, accounts@ en info@ alleen toe op beheerde domeinen, met geverifieerde bestemmingen en passende toegangsrechten.
postmaster@ en abuse@ hebben verschillende, dienstgebonden rollen in RFC 2142 en de SMTP-eisen. Domeinen die actieve SMTP-relay of mailaflevering aanbieden moeten binnen die dienst postmaster ondersteunen; abuse-eisen hangen af van de toepasselijke rol en dienst. Beoordeel ondersteuning en limieten van Agency voordat je grootschalig uitrolt.
Wanneer catch-all zinvol kan zijn
Drie voorbeelden van tijdelijke inzet:
- Actieve migratie: je verlaat een oud systeem en de adreslijst is nog onvolledig
- Domeinovername: je beheert een nieuw verworven domein en onderzoekt welk oud verkeer behouden moet blijven
- Testomgevingen: verzonnen testadressen moeten een gecontroleerde bestemming krijgen zonder ieder adres vooraf aan te maken
Gebruik in deze situaties een beheerde opvangroute en beoordeel wanneer die kan worden gesloten. Dit zijn geen uitputtende gebruikssituaties: ook permanent gebruik kan passend zijn als doel, filtering, toegang, monitoring en gegevensbeheer zorgvuldig zijn ingericht.
Catch-all vraagt een bewuste operationele keuze
Typefouten opvangen kan nuttig zijn, maar weeg dat af tegen extra verkeer, onveilige bounces en authenticatieproblemen bij forwarding. Backscatter en mislukte aflevering zijn geen automatische gevolgen van catch-all; de afhandeling bepaalt het risico.
Als kosten de reden zijn, vergelijk licenties, aliases, gedeelde mailboxen en capaciteit. Binnen de actuele TrekMail-planrechten kunnen Sales@, support@, billing@ en nog 47 benodigde adressen mogelijk afzonderlijk worden ingericht. Dat voorbeeld is geen belofte van een vaste prijs of onbeperkte mailboxrechten.
Controleer de actuele voorwaarden voor een proefperiode van 14 dagen, waaronder kaartvereisten. Kijk voor het beschreven Free/Nano-model naar de huidige naam, beschikbaarheid en limieten; gratis beschikbaarheid voor altijd is geen gegeven. In dit Nano-model is eigen externe SMTP nodig voor iedere uitgaande mail en ieder antwoord.