E-mailalias of mailbox: wat heb je nodig?

Je hebt een nieuw adres nodig: sales@, billing@, support@. Veel handleidingen zeggen: «Gebruik gewoon een alias, dat is gratis.» Dat kan werken, totdat antwoorden vanaf je persoonlijke adres worden verstuurd, facturen verdwijnen wanneer een medewerker vertrekt of doorgestuurde berichten worden geweigerd door een SPF-fout. Zo kun je legitieme mail missen zonder zelf een foutmelding te ontvangen.

Dit is het probleem achter de keuze tussen een e-mailalias op je domein en een mailbox. De bron vergelijkt Google Workspace en Microsoft 365 met prijzen van $6-$30 per gebruiker per maand; controleer de actuele voorwaarden. Die kosten per licentie stimuleren het gebruik van aliassen waar eigenlijk mailboxen nodig zijn. Technisch en organisatorisch zijn ze niet hetzelfde.

Deze handleiding helpt je kiezen: verschillen op protocolniveau, mogelijke problemen in de praktijk en een keuzematrix voor elk adrestype. Meer over het doorstuurmechanisme lees je in e-mail doorsturen: instellen, problemen oplossen en werking. Begin hier als je twijfelt tussen een alias en een mailbox.

Wat is het daadwerkelijke verschil tussen een alias en een mailbox?

Een e-mailalias op je domein is een routeringsregel. Wanneer een MTA mail voor alias@domain.com ontvangt, herschrijft hij in het hier beschreven model de ontvanger in de SMTP-envelop en bezorgt hij het bericht op het bestemmingsadres. De alias heeft geen eigen opslag, inloggegevens of zelfstandige aanmeldidentiteit. Een mailbox bewaart berichten: een toegewezen opslagquotum, IMAP-inloggegevens, een map Verzonden en een afzonderlijke geschiedenis. Je kunt inloggen op een mailbox, niet op een alias zelf.

Drie manieren waarop aliassen problemen veroorzaken

Aliassen kunnen drie terugkerende problemen opleveren: het primaire adres wordt zichtbaar bij antwoorden, SPF/DMARC-authenticatie mislukt bij extern doorsturen en gegevens gaan verloren wanneer het ontvangende account wordt verwijderd. Dit zijn geen louter theoretische uitzonderingen, maar risico's wanneer een alias werk moet doen waarvoor een mailbox nodig is.

1. Je persoonlijke adres wordt zichtbaar bij antwoorden

Je koppelt de alias support@ aan je persoonlijke founder@yourdomain.com. Een klant mailt naar support@. Je klikt op Beantwoorden.

Als «Verzenden als» niet goed is ingesteld, kan het antwoord vanaf founder@ worden verstuurd. De scheiding met het zakelijke kanaal vervalt. De klant heeft nu je rechtstreekse adres en kan dat blijven gebruiken.

«Verzenden als» vraagt aandacht; de juiste procedure hangt af van de dienst en versie:

• Google Workspace: controleer het secundaire adres en de eventuele verificatiecode. Bekijk de instelling «Behandelen als alias» en de daadwerkelijke Return-Path; die optie uitschakelen garandeert op zichzelf niet de juiste uitkomst.
• Microsoft 365: de PowerShell-opdracht Set-OrganizationConfig -SendFromAliasEnabled $true schakelt verzenden vanaf aliassen in voor ondersteunde configuraties. Controleer Outlook: sommige verzendroutes kunnen je primaire identiteit tonen met «Namens».
• Desktopclients (Outlook, Thunderbird): controleer het Van-adres bij antwoorden en stel waar mogelijk de juiste identiteit in. Een verkeerde selectie kan je primaire adres zichtbaar maken.

Bij een afzonderlijke mailbox support@ gebruiken antwoorden doorgaans standaard support@. Account en client moeten nog steeds goed zijn ingesteld, maar de identiteit is eenvoudiger gescheiden te houden.

2. De SPF-valkuil bij doorsturen

Een veelgebruikte opzet: de alias contact@yourbusiness.com stuurt door naar een persoonlijk Gmail-account. Dat introduceert een kwetsbaar punt in de architectuur.

De authenticatiestandaarden SPF (RFC 7208) en DMARC (RFC 7489) controleren verschillende zaken: SPF toetst het IP-adres van de verbinding aan het domein van MAIL FROM of HELO; DMARC vereist een geslaagde SPF- of DKIM-controle met domeinafstemming op de zichtbare afzender. Doorsturen kan de SPF-controle verstoren.

Een mogelijk foutscenario wanneer een bank naar je alias mailt en die doorstuurt naar Gmail:

1. De bankserver verstuurt naar contact@yourbusiness.com.
2. Je server herschrijft de ontvanger en stuurt door naar you@gmail.com.
3. Gmail ziet bij de SMTP-verbinding het IP-adres van jouw server, niet dat van de bank.
4. Het SPF-record van de bank machtigt jouw server niet. Zonder passende maatregelen mislukt SPF.
5. Als de bank DMARC met p=reject gebruikt en ook geen afgestemde DKIM-controle slaagt, kan Gmail het bericht volgens zijn beleid weigeren.

Je krijgt mogelijk geen melding. Een eventuele foutmelding kan naar de oorspronkelijke afzender gaan, niet naar de ontvanger van de alias; dit hangt af van het ontvangende systeem.

SRS (Sender Rewriting Scheme) kan het SPF-probleem beperken door de envelopafzender te herschrijven. Met de juiste SPF-machtiging kan de ontvangende server de doorsturende server controleren. Dit garandeert op zichzelf geen geslaagde DMARC-controle of bezorging:

# Original envelope (bank → your alias)
MAIL FROM: <notifications@bank.com>
RCPT TO:   <contact@yourbusiness.com>

# After SRS rewrite (your server → Gmail)
MAIL FROM: <SRS0=hash=TT=bank.com=notifications@yourbusiness.com>
RCPT TO:   <you@gmail.com>

Zonder SRS blijft MAIL FROM notifications@bank.com tonen, een domein waarvoor jouw server niet mag verzenden. SPF kan daardoor bij Gmail mislukken. Controleer of je provider SRS of ARC ondersteunt; neem dat niet zomaar aan. Meer over de basisconfiguratie van SPF, DKIM en DMARC staat in onze handleiding voor veilige zakelijke e-mail.

3. De afhankelijkheid van één medewerker

Je koppelt de alias billing@ aan alice@. Alice beheert de facturen. Alice vertrekt. Je verwijdert haar account.

Een mogelijk gevolg: billing@ levert foutmeldingen op en nieuwe facturen komen niet aan. De factuurgegevens van de afgelopen drie jaar in haar mailbox kunnen ook verloren gaan als je vóór verwijdering geen export, bewaarbeleid of herstelmogelijkheid hebt geregeld.

Bewaar je Alice' account alleen voor de facturen, dan bewaar je ook haar persoonlijke HR-gesprekken. Dat maakt toegangsbeheer, privacy en bewaarplichten ingewikkelder.

Met een afzonderlijke mailbox billing@ en gedelegeerde toegang, indien ondersteund, kun je Alice' toegang intrekken en Bob toegang geven zonder de zakelijke mailbox te verwijderen. Behoud van de geschiedenis hangt nog steeds af van bewaarbeleid en een zorgvuldig uitgevoerde overdracht.

Keuzematrix: alias of mailbox?

Kies bij voorkeur een mailbox voor adressen die mail versturen, bij personeelswisselingen worden overgedragen, een afzonderlijk auditspoor nodig hebben of veel of bedrijfskritische mail ontvangen. Gebruik een alias voor eenvoudige routering met weinig verkeer, tijdelijke volgadressen en omleidingen zonder eigen geschiedenis of professionele antwoordidentiteit.

Het bijzondere geval noreply@

noreply@ lijkt een routeringsadres, waardoor een alias voor de hand ligt. Maar in het hier beschreven model meldt je applicatie zich aan als SMTP-gebruiker om transactionele mail te versturen. Een alias heeft geen eigen inloggegevens. Een echte mailbox is nodig als je provider de SMTP-toegang daaraan koppelt; andere diensten kunnen afzonderlijke verzendgegevens zonder inbox aanbieden. Publiceer het wachtwoord niet en deel het niet onnodig met personen.

Waarschuwing voor catch-all

Een catch-all naar een persoonlijke inbox kan spam, mail naar verkeerd getypte adressen en berichten waarmee spammers geldige domeinadressen proberen te vinden binnenhalen. Heb je er een nodig, stuur dan naar een afzonderlijke mailbox voor ongewenste mail en controleer die wekelijks. Houd hem weg van de primaire inbox van een gebruiker. De handleiding voor e-mail op je eigen domein beschrijft hoe je die scheiding vanaf het begin kunt instellen.

Waarom de sector verkeerd kiest en wat TrekMail anders doet

Een oorzaak van slechte aliasarchitectuur is niet onwetendheid, maar de prijs per gebruiker. Mailboxlicenties bij Google Workspace en Microsoft 365 kunnen het gebruik van aliassen stimuleren waar mailboxen nodig zijn; voorwaarden verschillen per product en mailboxtype. Een besparing van $6/maand in het bronscenario kan later leiden tot verkeerde antwoordadressen, ontbrekende afzonderlijke auditsporen en moeilijk zichtbare SPF-problemen.

Het oude model (per licentie): in het voorbeeld zijn 5 medewerkers + 3 functiemailboxen (support, billing, noreply) = 8 licenties × $6 = $48/maand. Dit is geen algemeen minimum: controleer licenties en mogelijkheden voor gedeelde mailboxen. Een alias support@ naar een persoonlijke inbox kan veel instelwerk voor «Verzenden als» vergen en ruimte voor fouten laten.

TrekMail: het bronmodel rekent geen extra licentie per gebruiker. Maak support@, billing@ en noreply@ als afzonderlijke mailboxen voor $0 extra per mailbox, binnen de abonnementslimieten. Ze gebruiken gedeelde opslag; controleer de actuele voorwaarden.

In de bron beginnen abonnementen bij $3.50/maand (Starter: 50 domeinen, 15GB gedeelde opslag, 100 mailboxen per domein, beheerde SMTP inbegrepen). Het beschreven Nano-abonnement omvat 10 domeinen, 5GB en maximaal 10 mailboxen per domein, zonder verplichte creditcard. Controleer actuele prijzen, namen, beschikbaarheid en vereisten.

Voor bureaus en MSP's kan dit model het klantgesprek vereenvoudigen: geschikte functiemailboxen aanmaken zonder elke extra gebruikerslicentie te berekenen. Een nieuw adres kan worden toegevoegd binnen de geldende limieten. Onze handleiding voor e-mailhosting voor meerdere domeinen op schaal beschrijft het beheer van tientallen klantdomeinen vanuit één dashboard.

Snelle referentie: wanneer gebruik je welke optie?

Gebruik een mailbox als het adres:

• Via IMAP moet worden gebruikt om mail te lezen, met SMTP voor verzenden
• Bij personeelswisselingen wordt overgedragen
• Een afzonderlijke map Verzonden nodig heeft voor controles
• Veel of bedrijfskritische mail verwerkt
• Zich bij een SMTP-server moet aanmelden voor transactioneel verzenden in het model van de provider

Gebruik een alias als het adres:

• Niet-prioritaire mail naar een bestaande mailbox routeert
• Tijdelijk is, voor een evenement of herkenning van een leverancier
• Alleen binnen hetzelfde domein doorstuurt
• Geen professionele antwoordidentiteit of zelfstandige overdracht nodig heeft

Conclusie

Aliassen routeren mail. Mailboxen bewaren mail en maken verzenden mogelijk met de juiste verzenddienst. Ze zijn niet uitwisselbaar, ook al stimuleert de prijs per gebruiker soms die gedachte. Verdwenen berichten na een vertrek en antwoorden vanaf het verkeerde adres zijn concrete risico's als een alias het werk van een mailbox moet doen.

Kies meteen de juiste architectuur: mailboxen voor belangrijke adressen, aliassen voor eenvoudige routering met weinig risico. Zoek een provider die die scheiding niet financieel ontmoedigt.

Bekijk de TrekMail-abonnementen: het bronmodel kent geen kosten per gebruiker en noemt een gratis proefperiode van 14 dagen voor betaalde abonnementen. Controleer de actuele prijzen en voorwaarden.