Catch-all-mailhosting: 8 controles vóór inschakeling

Bij catch-all-emailhosting routeert de mailserver onbekende ontvangers op je domein naar een standaardbestemming. Dat kan typefouten opvangen, maar is een serverinstelling, geen DNS-wildcard die iedere boodschap gegarandeerd ontvangt.

Waar een onbekende ontvanger anders 550 5.1.1 User Unknown oplevert, kan de server 250 OK antwoorden op RCPT TO. Dat is nog geen definitieve berichtacceptatie. Directory Harvest Attacks proberen namen als admin@, invoice@, payroll@ en careers@. Catch-all bemoeilijkt herkenning van bestaande adressen via het ontvangerantwoord, maar extra verkeer kan filtering en opslag belasten. Een Cisco-drempel van 25 ongeldige ontvangers per uur beoordeelt de externe verzendende host binnen een ingestelde ontvangstpolicy, niet ieder catch-all-domein volgens een universele aanvalsdrempel. Aanvallen kunnen duizenden pogingen per minuut omvatten.

Afhankelijk van limieten en misbruikbeleid kan veel verkeer tot beperkingen leiden. Legitieme mail kan tussen spam verdwijnen of door filters worden tegengehouden. Controleer de volgende acht onderdelen voordat je catch-all gebruikt.

Voor opvangmailboxen, PCRE-filtermaps en het voorkomen van Exchange-lussen kun je beginnen met domein-catch-all met behoud van controle. Deze checklist helpt daarna bij de operationele inrichting.

Wat catch-all verandert in je SMTP-verwerking

Catch-all verandert de ontvangercontrole in de SMTP-envelop. In plaats van onbekende ontvangers vóór DATA met 550 te weigeren, kan de server een opvangroute gebruiken. Verbindingcontroles kunnen blijven gelden, en inhoudsfilters kunnen tijdens DATA vóór definitieve acceptatie werken. Niet iedere toegestane ontvanger veroorzaakt meteen permanente opslag.

Na definitieve acceptatie kunnen berichten wel wachtrijen, scans en opslag belasten. Een NDR naar een vervalste MAIL FROM kan backscatter veroorzaken. Een herstelvenster van 2-4 weken is slechts een voorbeeld; beleid, bewijs en de betrokken lijst bepalen de duur. Reputatie-effecten kunnen andere gebruikers van hetzelfde IP-adres raken, maar gelden niet automatisch voor een volledige IP-range.

De afweging is extra adresdekking tegenover meer toegelaten verkeer. Houd filtering actief en bepaal waar weigering, quarantaine en aflevering plaatsvinden.

De checklist met 8 punten

Beoordeel acht onderdelen: SMTP-filtering vóór definitieve acceptatie, bruikbare logs, volumebescherming, forwardingauthenticatie, geautoriseerde antwoordidentiteiten, veilige NDR-afhandeling, export en opslagbeleid. Ze helpen concrete risico's te beheersen zonder een veilige aflevering te garanderen.

1. SMTP-filtering vóór definitieve berichtacceptatie

Vraag welke controles bij de verbinding, ontvanger en DATA worden uitgevoerd. 250 OK bij RCPT TO bevestigt alleen de ontvanger; het bewijst geen opgeslagen bericht of backscatter. Die laatste ontstaat bij een latere foutmelding naar een vervalste envelopafzender.

Een weigering vóór het aannemen van de berichtinhoud kan er zo uitzien:

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>

Een inhoudsfilter kan bijvoorbeeld dit melden:

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

De tweede regel bewijst op zichzelf niet of de SMTP-server het bericht al definitief had geaccepteerd of in een wachtrij had gezet. Controleer de filterintegratie en bijbehorende transactie. Vraag wanneer acceptatie plaatsvindt en hoe afgekeurde mail wordt verwerkt. Alleen zeggen dat een spamfilter bestaat geeft daarop geen antwoord.

2. Tijdig inzicht in SMTP en routing

Als een klant mail naar billing@ heeft gestuurd, is een totaalteller niet genoeg om de route te vinden. Gebruik tracegegevens of logs met relevante ontvanger-, filter- en afleveringsinformatie. Geef alleen bevoegde beheerders toegang en beperk de blootstelling van persoonsgegevens en inhoud.

Een bruikbaar logfragment kan er zo uitzien:

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 en Microsoft 365 bieden productgebonden beheer- en tracefuncties. Een vertraging van 30-60 minuten is een mogelijke referentie, geen vaste eigenschap van alle gegevens. Controleer detailniveau, toegang, beschikbaarheid en ondersteuningstijd voor jouw abonnement en onderzoeksbehoefte.

3. Volumebeperking die jouw mailverkeer mee beschermt

Een catch-all kan veel mail naar duizenden verzonnen adressen toelaten. Dat hoeft geen accountschorsing te veroorzaken, maar gedeelde systemen en accountlimieten kunnen gevolgen hebben. Vraag hoe de provider bronverkeer, gebruikerslimieten en legitieme aflevering van elkaar onderscheidt.

Vraag bijvoorbeeld: "Wat gebeurt er als ons domein binnen een uur 10,000 berichten door een Directory Harvest Attack ontvangt? Wordt de bron beperkt, ons account begrensd of volgt een andere maatregel?"

4. SRS en ARC bij forwarding

Onderzoek authenticatie als server A catch-all-mail naar Gmail of Outlook doorstuurt. De extra hop kan SPF en DKIM-afstemming beïnvloeden; catch-all zelf breekt de authenticatie niet.

SPF kan falen: de ontvanger ziet het relay-IP. Bij een oorspronkelijke envelopidentiteit met v=spf1 ... -all faalt SPF als die IP niet is toegestaan; controleer de werkelijk gebruikte identiteit.

DMARC kan falen: als geen SPF of DKIM slaagt met afstemming op het zichtbare From-domein, kan p=reject tot weigering of ander ontvangerbeleid leiden. Geldige, afgestemde DKIM die intact blijft kan DMARC zonder SRS of ARC laten slagen. Er is niet altijd een stille verwijdering.

Controleer wat de forwardingroute ondersteunt:

• SRS (Sender Rewriting Scheme): herschrijft Envelope-From; SPF van het nieuwe domein moet de relay-IP echt toestaan. Dit garandeert geen afstemming op het oorspronkelijke From. Zie SRS-forwarding: werking en mogelijke fouten.
• ARC (Authenticated Received Chain): beschreven in RFC 8617, bewaart ondertekende authenticatie-informatie over tussenliggende hops. De ontvanger moet de keten valideren en de geverifieerde sealer vertrouwen; aflevering blijft zijn beslissing.

Deze voorbeelden hebben verschillende oorzaken: het eerste betreft organisatiebeleid voor extern doorsturen, het volgende DMARC. Ze bewijzen niet dat SRS of ARC ontbreekt:

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.

Als de documentatie onduidelijk is, vraag de provider naar actuele ondersteuning en controleer de werkelijke headers en route.

5. Aliases en geautoriseerde antwoordidentiteit

Catch-all kan mail voor billing@, support@ en project-2026@ opvangen. Antwoorden vereist apart ingestelde verzendrechten. In Gmail vraagt verzenden als billing@yourdomain.com naast een hoofdaccount admin@yourdomain.com om een ondersteunde "Send As"-identiteit met vereiste verificatie en SMTP-inrichting. Dat gebeurt bij het configureren van een identiteit, niet bij ieder bericht.

Controleer hoe je bevoegde afzenderidentiteiten aanmaakt en in een ondersteunde client gebruikt. Een wachttijd van 24 uur is een mogelijk operationeel voorbeeld, geen algemene norm. Verificatie beschermt tegen misbruik; ontvangst op een onbekend adres verleent niet vanzelf verzendrechten.

6. Veilige afhandeling van backscatter en NDR's

Na definitieve acceptatie kan een volle opvangmailbox, routingfout of latere scan een fout opleveren. Als vervolgens een NDR naar een vervalste MAIL FROM wordt gestuurd, ontstaat backscatter. Dat kan reputatieproblemen of een vermelding bij Backscatterer.org geven, maar maakt de server niet automatisch tot open relay en veroorzaakt niet altijd een blocklistvermelding.

Vraag wanneer ongewenste mail wordt geweigerd, in quarantaine geplaatst of volgens gecontroleerd beleid verwijderd. Geef de voorkeur aan passende SMTP-weigering of veilige quarantaine zonder reacties op vervalste afzenders. Verwijder geen legitieme mail om alleen bounces te vermijden en behoud vereiste, legitieme afleveringsmeldingen. De verzendreputatie van je domein verdient afzonderlijke monitoring.

7. IMAP-toegang en verifieerbare export

Een opvangmailbox kan veel data verzamelen. Controleer vooraf hoe je mail kunt exporteren of migreren, via IMAP of een gedocumenteerde exportfunctie. Een andere interface dan IMAP betekent niet automatisch dat export onmogelijk is.

Beoordeel onder meer:

• Ondersteunde IMAP-toegang via poort 993 met TLS
• Export naar .eml of .mbox waar ondersteund
• Afgesproken leeslimieten en migratievensters voor bulkoverdracht

POP3-verwijdering hangt af van clientinstellingen en DELE-commando's, niet van een verplicht standaardgedrag. IMAP is bruikbaar voor mapstructuur, maar niet de enige exportmethode of garantie op volledig behoud. Controleer bevoegdheden en compatibiliteit, maak een passende back-up en vergelijk mappen, aantallen, relevante metadata en uitzonderingen na een proefmigratie. Plan een laatste synchronisatie rond de gecontroleerde DNS-omschakeling; contacten en agenda's vragen afzonderlijke overdracht.

8. Duidelijk opslagbeleid en gedrag bij volle quota

Vraag wat gebeurt bij een volle mailbox. Een tijdelijke SMTP-reactie zoals 452 4.2.2 Insufficient storage geeft de verzendende server een signaal om volgens eigen beleid opnieuw te proberen, niet om onbeperkt te blijven proberen. Stille verwijdering van legitieme mail is ongewenst; zorg voor zichtbare foutafhandeling en tijdige meldingen.

Controleer of quota per mailbox, domein of account gelden. In een voorbeeld kan ongewenst verkeer 80% van gedeelde capaciteit opgebruiken en andere mailboxen hinderen. Mailboxlimieten kunnen dit beperken, maar werken samen met de overige opslag- en accountgrenzen.

TrekMail beoordelen voor catch-all-hosting

TrekMail beschrijft gedeelde opslag en meerdere mailboxen binnen planrechten. Controleer hoe abonnement, domeinen en capaciteit werkelijk worden berekend; het is niet vanzelf per domein of onbeperkt. Richt jobs@, billing@, support@ en archive@ bewust in als ze nodig zijn, in plaats van onbekende adressen uitsluitend om kostenredenen op te vangen.

Een historische prijsrange van $6-$12 per gebruiker per maand kan aanleiding zijn om functionele adressen anders in te richten. Suites kunnen ook aliases en gedeelde mailboxen bieden. Vergelijk de mogelijkheden voor een adres dat slechts drie berichten per maand ontvangt:

Controleer voor oude routes of externe koppelingen de huidige catch-all-, log-, IMAP- en SRS-functies. Historische referenties noemen Starter voor $3.50 per maand met 50 domeinen en gedeelde opslag, en een proefperiode van 14 dagen met kaartvereiste. De beschreven gratis variant noemt 10 domeinen, 5GB gedeelde opslag en BYO SMTP. Verifieer actuele prijzen, limieten en kaartvoorwaarden. In dit Free/Nano-model is eigen externe SMTP nodig voor ieder uitgaand bericht en antwoord.

Conclusie

Catch-all-hosting is een hulpmiddel, geen noodzakelijke standaard. Controleer filtering, inzicht, volumebescherming, forwarding, verzendrechten, NDR-afhandeling, export en quota. Daarmee kun je je inrichting afstemmen op concrete risico's en bedrijfsbehoeften. Het oplossen van sommige blocklistvermeldingen kan weken duren, afhankelijk van de lijst en de aanpak van de oorzaak.

Leg vast waar definitieve acceptatie plaatsvindt en hoe fouten worden afgehandeld. Verifieer SRS, DKIM-afstemming en ARC-vertrouwen in de echte route en houd reputatie en capaciteit in de gaten; backscatter kan nog weken na het ontstaan van het probleem gevolgen hebben, zonder vaste hersteltermijn. Als kosten de aanleiding zijn, vergelijk aliases, gedeelde mailboxen en verschillende abonnementsmodellen; een andere prijsstructuur lost niet automatisch alle routingrisico's op.

Bekijk TrekMail voor catch-all-hosting, IMAP en de actuele planvoorwaarden.