Je hebt op je domein een nieuw adres nodig, zoals sales@ of billing@. Je hebt twee opties: een e-mailalias voor het domein of een volwaardig postvak. Een verkeerde keuze kan leiden tot blootgelegde identiteiten, verloren e-mail of nalevingslacunes die maanden onopgemerkt blijven. De keuze tussen een domeinalias en een postvak beïnvloedt beveiliging, kosten en operationele weerbaarheid.
Bij traditionele oplossingen zoals Google Workspace of Microsoft 365 is dit in wezen een financiële keuze. Een postvak kost $6-30/maand. Een alias is gratis. Dat prijsmodel stuurt bedrijven richting een slechte architectuur, met aliassen waar postvakken horen, waardoor beveiligingslacunes en gebrekkige workflows ontstaan. Bij TrekMail kosten postvakken niet extra, zodat je deze keuze op technische gronden kunt maken.
Hier volgt het besliskader. We bekijken wat elke optie op protocolniveau werkelijk doet, waar aliassen tekortschieten en wanneer je welke optie gebruikt.
E-mailalias voor een domein versus postvak: wat is het werkelijke verschil?
Bij de afweging tussen een e-mailalias voor een domein en een postvak is het belangrijkste verschil eenvoudig. Een e-mailalias voor een domein is een routeringsregel die inkomende e-mail doorstuurt naar een bestaand postvak, terwijl een volwaardig postvak een onafhankelijke opslaglocatie is met eigen inloggegevens, inbox en map met verzonden berichten. Aliassen kunnen zich niet authenticeren of e-mail opslaan. Postvakken kunnen beide.
| Functie | E-mailalias voor domein | Volwaardig postvak |
|---|---|---|
| SMTP-functie | RCPT TO-herschrijving (verwijzing) | Opslageindpunt |
| Authenticatie | Geen - inloggen niet mogelijk | Eigen inloggegevens |
| Opslag | 0 GB (gebruikt quotum van bestemming) | Eigen toewijzing |
| Audittrail | Vermengd met e-mail van ontvanger | Afzonderlijke logboeken |
| Uitgaand verzenden | Vereist configuratie voor "Verzenden als" | Eigen From-header |
| Kosten (Google/Microsoft) | Gratis | $6-30/maand per gebruiker |
| Kosten (TrekMail) | Inbegrepen | Inbegrepen - gedeelde opslag |
De alias: een routeringsinstructie
Een alias is geen bestemming, maar een regel. Wanneer een mailserver een bericht voor alias@domain.com ontvangt, herschrijft deze de ontvanger in de envelop naar primary@domain.com en plaatst het bericht daar.
Voordeel: Geen onderhoud en geen extra opslag. Geschikt voor e-mail aan adressen waarop niemand hoeft in te loggen.
Nadeel: Zonder aanmelding is er geen isolatie. Als je drie jaar later een bericht aan die alias moet terugvinden, moet je zoeken in de inbox van iemand anders, tussen allerlei niet-gerelateerde berichten. Lees voor meer informatie over de interne werking onze gids over wat een e-mailalias is en hoe die werkt.
Het postvak: een zelfstandige identiteit
Een postvak is een afzonderlijk object. Het heeft eigen opslag, inloggegevens en berichtgeschiedenis.
Voordeel: Volledige isolatie. Je kunt inloggegevens aan een nieuwe medewerker, auditor of automatiseringsscript geven zonder iemands persoonlijke e-mail bloot te leggen.
Nadeel: Bij prijsmodellen per gebruiker verhoogt elk postvak de factuur. Daardoor wordt de keuze bij veel bedrijven eerder politiek dan technisch.
Het antwoordprobleem: hoe aliassen je identiteit blootleggen
Dit is de grootste operationele fout bij de keuze tussen een e-mailalias voor een domein en een postvak, en de meeste mensen zien die niet aankomen.
Het scenario: Je laat support@ als alias verwijzen naar je persoonlijke adres, founder@. Een klant mailt support@. Jij klikt op beantwoorden.
Wat gaat er mis: Tenzij je de instellingen voor "Verzenden als" zorgvuldig hebt geconfigureerd, komt je antwoord van founder@. De klant heeft nu je rechtstreekse adres en kan voortaan het supportkanaal omzeilen. De professionele scheiding is verdwenen.
De oplossing is omslachtig:
- Google Workspace: Voeg de alias toe als secundair adres, verifieer die met een code en schakel "Behandelen als alias" uit om het juiste Return-Path af te dwingen.
- Microsoft 365: Voer
Set-OrganizationConfig -SendFromAliasEnabled $trueuit in PowerShell om te voorkomen dat Outlook headers met "Namens" toevoegt. - Desktopclients: Kies bij elk antwoord handmatig het juiste adres in de vervolgkeuzelijst From. Eén vergissing en je identiteit wordt zichtbaar.
Waarom een postvak hier beter werkt: Wanneer je als support@ bent aangemeld, komen antwoorden standaard van support@. Er hoeft niets te worden geconfigureerd dat later kan breken. Als je de afwegingen rond e-mailalias voor een domein versus postvak beoordeelt, geeft de antwoordworkflow vaak de doorslag.
De valkuil van doorsturen: SPF, DMARC en verloren e-mail
Veel mensen maken een alias om e-mail extern door te sturen, bijvoorbeeld contact@business.com naar coolguy123@gmail.com. Deze opzet is architectonisch kwetsbaar.
Moderne e-mailauthenticatie (SPF, DKIM, DMARC) is bedoeld om te voorkomen dat onbevoegde servers namens een domein verzenden. Doorsturen onderbreekt die keten:
- SPF-fout: Wanneer bank.com je alias mailt en je server het bericht doorstuurt naar Gmail, ziet Gmail het IP-adres van jouw server, niet dat van de bank. Het SPF-record van de bank vermeldt jouw IP-adres niet. Afgekeurd.
- DMARC-weigering: Als de bank
p=rejectpubliceert, kan Gmail het bericht volledig weigeren. Je krijgt het dan niet te zien.
Om doorsturen betrouwbaar te laten werken, heeft je provider SRS (Sender Rewriting Scheme) en ARC (Authenticated Received Chain) nodig. Veel goedkope registrars ondersteunen geen van beide. Als je via een goedkope host doorstuurt, bestaat het risico dat legitieme e-mail ongemerkt verloren gaat.
Lees voor een volledige uitleg over het instellen en oplossen van problemen met doorsturen onze gids over e-maildoorsturing instellen en herstellen. De documentatie van Google over routering en bezorging van e-mail bespreekt ook hoe doorsturen aan de ontvangende kant samenwerkt met authenticatie.
De afhankelijkheid van één persoon: wat gebeurt er als iemand vertrekt?
Het onderscheid tussen een e-mailalias voor een domein en een postvak is vooral belangrijk bij personeelswisselingen. Aliassen creëren afhankelijkheid van sleutelfiguren waar veel teams pas aan denken wanneer het te laat is. Juist hier is het onderscheid tussen een e-mailalias voor een domein en een postvak essentieel.
Het scenario: Je laat billing@ als alias verwijzen naar alice@. Alice verwerkt alle facturen. Alice vertrekt. Je verwijdert haar account.
De gevolgen:
- Directe bounce: billing@ werkt niet meer. Facturen worden teruggestuurd naar leveranciers.
- Gegevensverlies: Tenzij je het postvak van Alice eerst hebt geëxporteerd, gaat de volledige geschiedenis van billing@ verloren.
- Privacyprobleem: Als je het account van Alice actief houdt voor de administratie, bewaar je ook haar persoonlijke HR-gesprekken en alle andere berichten in die inbox.
De oplossing met een postvak: Als billing@ een eigen postvak is, heeft Alice alleen gedelegeerde toegang. Wanneer ze vertrekt, trek je haar toegang in en geef je die aan Bob. Het postvak, de facturen en de geschiedenis blijven behouden, zonder voorziene uitvaltijd.
Beslismatrix voor e-mailalias voor een domein versus postvak
Gebruik dit overzicht om te bepalen wat elk adres op je domein moet zijn.
| Gebruikssituatie | Advies | Waarom |
|---|---|---|
| Primaire identiteit (first.last@) | Postvak | Vereist 2FA, privéopslag en mobiele synchronisatie |
| Functieadressen met veel verkeer (support@, billing@, jobs@) | Postvak | Vereist duidelijke audittrail, overdracht tussen medewerkers en isolatie van spam |
| Routering met weinig verkeer (info@, media@) | Alias | Verkeer met lage prioriteit kan naar een officemanager worden geleid |
| Tijdelijk/tracking (conference2026@, vendor-name@) | Alias | Wegwerpbaar - verwijderen zodra het spam aantrekt |
| Catch-all (*@domain.com) | Vermijden | Lokt aanvallen uit die adressen verzamelen en schaadt de domeinreputatie |
Een snelle vuistregel: als het adres ooit e-mail moet verzenden, maak je er een postvak van. Dat is de eenvoudigste test voor de keuze tussen een e-mailalias voor een domein en een postvak. Als het alleen e-mail hoeft te ontvangen en routeren, volstaat een alias. Lees voor een diepere uitleg van de wisselwerking tussen aliassen, doorsturen en je domein ons artikel over configuratie van e-mail met een domeinalias.
Waarom TrekMail deze keuze eenvoudig maakt
Zodra je de afwegingen tussen een e-mailalias voor een domein en een postvak begrijpt, volgt de vraag naar de kosten. Het prijsmodel per gebruiker bij Google en Microsoft ligt aan de basis van veel ongeschikte e-mailarchitecturen. Je betaalt meer wanneer je correcte postvakken aanmaakt, waardoor bedrijven soms uitwijken naar aliassen.
TrekMail rekent een vast tarief per domein, niet per gebruiker.
- Gedeelde opslag: Je krijgt een opslagpool (15 GB bij Starter, 200 GB bij Agency). Verdeel die over zoveel postvakken als je nodig hebt.
- Geen kosten per postvak: support@ als echt postvak aanmaken kost $0 extra. Het gebruikt ruimte uit je pool, maar er komen geen nieuwe licentiekosten bij.
- Pakketten: Free ($0, geen kaart vereist) · Starter ($3.50/mo) · Pro ($10/mo) · Agency ($23.25/mo). Alle betaalde pakketten omvatten een proefperiode van 14 dagen.
Voor kleine bedrijven betekent dit dat je billing@, sales@ en support@ als afzonderlijke, beveiligde postvakken kunt instellen zonder een prijskaartje voor grote ondernemingen. Bureaus kunnen tientallen postvakken per klant inrichten zonder telkens licentiekosten uit te rekenen. Raadpleeg voor extra context over het verschil tussen moderne routering en traditioneel doorsturen de inleiding van Cloudflare over e-mailroutering.
Conclusie
De keuze tussen een e-mailalias voor een domein en een postvak draait om één vraag: heeft dit adres een eigen identiteit nodig? Als het e-mail verzendt, tussen medewerkers wordt overgedragen of gevoelige zaken verwerkt, maak je er een postvak van. Als het alleen inkomend verkeer met lage prioriteit opvangt, kan een alias volstaan.
Nu je de afwegingen tussen een e-mailalias voor een domein en een postvak begrijpt, hoef je je infrastructuur niet langer aan te passen om $6/maand te besparen. Probeer TrekMail gratis en bouw de architectuur die bij de behoeften van je domein past.
