E-mailaliassen voor je domein: 5 configuratieproblemen controleren

Je hebt e-mailaliassen op je domein ingesteld - sales@yourcompany.com komt in je inbox terecht, support@ gaat naar de helpdesk. In het beheerpaneel lijkt alles goed, maar je kunt toch aanvragen missen, een klant kan een foutmelding krijgen en je kunt ontdekken dat je al drie weken vanaf je persoonlijke adres antwoordt. Dat is een voorbeeldsituatie, geen onvermijdelijk gevolg van aliassen.

Als een domeinalias niet werkt, controleer dan zowel adresfouten als routering en authenticatie - SPF, DKIM en DMARC. Een conflict tussen routeringslogica en authenticatie is een mogelijke oorzaak, maar niet de enige.

Zie je 550 5.7.520 of 554 5.4.14, of verdwijnt mail terwijl je server netjes 250 OK meldt? Stop dan met gokken. Deze gids behandelt vijf veelvoorkomende configuratiefouten bij domeinaliassen, met bijbehorende foutcodes en gerichte oplossingen. Acceptatie door een server bewijst overigens niet dat het bericht uiteindelijk wordt afgeleverd.

Wil je eerst de basis begrijpen - het verschil tussen een alias en een mailbox - lees dan domeinalias versus mailbox.

Werkt je domeinalias echt niet? Begin hier

Problemen met domeinaliassen vallen vaak in een van vijf categorieën. Elke categorie heeft herkenbare symptomen en soms een foutcode. Zoek eerst de passende rij voordat je DNS, routeringsregels of beheerbeleid verandert - een code biedt een aanknopingspunt, geen sluitende diagnose.

Waarom domeinaliassen problemen geven: twee afzenderadressen

E-mail kent verschillende afzenderidentiteiten. Voor dit probleem zijn er twee belangrijk. De envelopafzender (RFC 5321 MAIL FROM) wordt door servers gebruikt voor foutmeldingen - SPF controleert dit domein. De afzender in de header (RFC 5322 From:) is zichtbaar in Gmail of Outlook - DMARC vergelijkt dit domein met een geslaagde SPF- of DKIM-identiteit.

Interne routering - van sales@ naar bob@ op dezelfde server - veroorzaakt niet vanzelf een nieuwe externe SPF-controle, maar garandeert ook geen geldige authenticatie. Bij extern doorsturen ziet de ontvangende server het IP-adres van je doorstuurserver. Blijft de oorspronkelijke envelopafzender behouden en is dat IP niet toegestaan voor diens domein, dan kan SPF mislukken. Bij p=reject kan de ontvanger het bericht weigeren als DMARC ook mislukt. Een behouden, uitgelijnde DKIM-handtekening kan DMARC alsnog laten slagen; weigering, quarantaine en foutmeldingen hangen af van beleid en verwerkingsfase.

Configuratiefout 1: extern doorsturen zonder SRS

Doorsturen naar Gmail, Yahoo of een persoonlijk Outlook.com-adres kan SPF laten mislukken wanneer de oorspronkelijke envelopafzender behouden blijft. Dat verdient extra aandacht bij streng DMARC-beleid. In de hier besproken periode 2025-2026 is dit een relevant risico bij domeinaliassen, maar niet elke doorgestuurde mail mislukt: onder meer behouden DKIM en ontvangersbeleid bepalen de uitkomst bij p=reject.

Het scenario: klant alice@bank.com mailt naar contact@yourdomain.com. Je server stuurt het bericht door naar you@gmail.com. Gmail controleert SPF voor bank.com. Staat het IP van je doorstuurserver niet in de SPF-autorisatie van bank.com, dan mislukt SPF. De bank heeft p=reject. Zonder geslaagde, uitgelijnde DKIM kan DMARC mislukken en kan de ontvanger weigeren of een andere beleidsactie toepassen. De eerdere 250 OK van je server bevestigt alleen acceptatie op dat moment; een latere foutmelding is niet gegarandeerd.

De SPF-oplossing: Sender Rewriting Scheme (SRS). SRS herschrijft de envelopafzender naar je eigen domein voordat het bericht wordt doorgestuurd:

Oorspronkelijke envelop: alice@bank.com
Na SRS-herschrijving: SRS0=hash=TT=bank.com=alice@yourdomain.com

Gmail controleert SPF nu voor yourdomain.com. Als je server daarvoor is toegestaan, kan SPF slagen. SRS wordt op serverniveau ingesteld - door je hostingprovider of mailbeheerder. Voor Postfix en Exim zijn SRS-integraties beschikbaar; controleer welke je omgeving ondersteunt.

Belangrijke beperking: SRS kan SPF voor de nieuwe envelopafzender laten slagen, maar herstelt niet de uitlijning met het oorspronkelijke From-domein. Voor DMARC-uitlijning kan een behouden, geldige DKIM-handtekening van een uitgelijnd domein volstaan. ARC (Authenticated Received Chain) kan eerdere controles meegeven; de ontvanger moet de keten valideren en de ondertekenende dienst vertrouwen voordat hij die naar eigen beleid meeweegt. ARC creëert geen uitlijning en garandeert geen bezorging. Opnieuw ondertekenen met je eigen, andere domein herstelt die uitlijning evenmin.

Een eenvoudiger alternatief: vermijd externe doorsturing waar dat praktisch is. Gebruik een echte IMAP-mailbox op je domein en open die met een mobiele client. Doorsturen wordt soms als een patroon uit 2012 beschreven, maar kan nog steeds nuttig zijn; het vraagt bewuste authenticatie- en beleidskeuzes.

Configuratiefout 2: Microsoft 365 blokkeert extern doorsturen

Stuurt je domeinalias extern door en zien afzenders 550 5.7.520 Access denied, controleer dan het Microsoft-beleid. De optie "Automatic - System-controlled" in het uitgaande antispambeleid van Exchange Online blokkeert volgens het beschreven standaardgedrag automatisch extern doorsturen. Dit beperkt het risico op ongewenste gegevensuitvoer. Controleer het actuele tenantbeleid voordat je het wijzigt.

Aanpassing in het beheerportaal:

1. Open het Microsoft 365 Defender-portaal
2. Ga naar: Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. Bewerk Anti-spam outbound policy (Default)
4. Zet "Automatic forwarding rules" op On - Forwarding is enabled, als je beveiligingsbeleid dit toestaat

Wil je doorsturen slechts voor bepaalde gebruikers toestaan - doorgaans een beter af te bakenen aanpak - maak dan een aangepast uitgaand beleid voor die accounts in plaats van de organisatiebrede standaard te wijzigen.

Alternatief met PowerShell: dit voorbeeld schakelt doorsturen in via het organisatiebrede standaardbeleid. Voer het alleen uit als je daarvoor bevoegd bent en die brede wijziging is goedgekeurd; gebruik voor beperkte toegang een beleid voor de bedoelde accounts.

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

Configuratiefout 3: de routeringslus

Een routeringslus kan 554 5.4.14 Hop Count Exceeded veroorzaken. Het bericht gaat tussen adressen heen en weer tot een ingestelde grens wordt bereikt - bijvoorbeeld 15-20 hops in een specifieke omgeving, niet een universele limiet. Daarna kan de server een foutmelding naar de oorspronkelijke afzender sturen; jij ontvangt het bericht niet.

Zo'n lus ontstaat vaak door een vergeten inboxregel op de doelmailbox:

Serveralias: info@ → admin@
Mailboxregel op admin@: alles doorsturen naar info@ voor archivering
Resultaat: lus tot de hoplimiet wordt overschreden

De oorzaak kan bijvoorbeeld een afwezigheidsregel van twee jaar geleden zijn of een vergeten regel om alles naar info@ te archiveren. Die ouderdom is een voorbeeld, geen vaste oorzaak. Bekijk zowel serveraliassen als inboxregels. Controleer in Exchange de transportregels in het beheercentrum. Bekijk in Google Workspace bij elk betrokken account "Filters and Blocked Addresses".

Structurele aanpak: controleer wanneer je server aliassen uitbreidt en wanneer gebruikersregels worden toegepast. Een "redirect" die de oorspronkelijke ontvanger behoudt, kan in sommige configuraties opnieuw dezelfde alias activeren. Kies een expliciete afleverroute naar het einddoel en verwijder terugverwijzingen; de juiste regelvolgorde hangt af van je mailsysteem.

Configuratiefout 4: de verkeerde identiteit bij "Send As"

Een domeinalias die alleen ontvangt, is niet voldoende als je er ook mee wilt antwoorden. Reageer je op mail aan sales@yourcompany.com en ziet de ontvanger bob.smith@yourcompany.com in het From-veld, dan werkt de bedoelde afzenderidentiteit niet. Dat kan je primaire adres onthullen zonder dat je het zelf merkt.

Controle in Google Workspace:

1. Open User Settings → Accounts → "Send mail as"
2. Voeg het aliasadres toe
3. Kies bewust of je "Treat as an alias" uitvinkt. De juiste keuze hangt af van de identiteit die je wilt gebruiken; uitvinken is geen gegarandeerde privacyoplossing. Controleer From, Reply-To en andere headers van een proefbericht.

Controle in Microsoft 365:

In M365 kan "Bob on behalf of Sales" samenhangen met gedelegeerde verzendrechten; het is niet het vaste gedrag van elke alias. Verzenden vanaf mailboxaliassen heeft een aparte organisatie-instelling:

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

Deze instelling geldt voor Exchange Online - niet voor lokale Exchange-installaties. SendFromAlias staat los van Send As- en Send on Behalf-rechten; ondersteuning verschilt per client. De instelling verhelpt daarom niet automatisch elke "on behalf of"-weergave.

Configuratiefout 5: botsing met een catch-all

Een catch-all (*@domain.com) vangt adressen op waarvoor geen specifieke bestemming bestaat. Als je routeringslogica een brede regel voorrang geeft op een specifieke alias, kan mail in de verkeerde inbox terechtkomen zonder duidelijke foutmelding.

Bij geïndexeerde Postfix-tabellen zoekt virtual_alias_maps eerst een exact adres en daarna de domeinbrede catch-all; de regelvolgorde in het bronbestand bepaalt dat niet. Dit voorbeeld zet de specifieke aliassen voor de leesbaarheid bovenaan:

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

De catch-all staat hier ter illustratie onderaan, niet als vereiste voor geïndexeerde zoekvolgorde. Bij geordende PCRE-regels kan de regelvolgorde wel bepalend zijn. Bij MySQL-tabellen bepalen de query en het maptype welke match voorrang krijgt. Maak een back-up van de configuratie en bestaande maps en behoud de benodigde regels. Controleer ontvangercontrole en doelen vóór een bevoegde wijziging en herlaad pas na validatie; alleen rijen verplaatsen is geen betrouwbare oplossing.

Verder onderzoeken: lees de ruwe headers

Verdwijnt mail zonder foutmelding, zoek dan naar een exemplaar in spam of quarantaine en bekijk de ruwe headers. De header Authentication-Results laat zien welke authenticatiecontroles de ontvangende server uitvoerde. Combineer die informatie met logboeken en berichttracering; één header verklaart niet elke afleverfout.

In Gmail: open het bericht → menu met drie stippen → "Show original". Zoek het authenticatiegedeelte:

Mislukte controles - mogelijk zonder SRS:

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

smtp.mailfrom is nog steeds alice@bank.com. Als het genoemde IP je doorstuurserver is, toont dit dat de envelopafzender niet via SRS is herschreven.

Geslaagde controles - herschreven envelop:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

Het envelopadres is herschreven en SPF slaagt voor yourdomain.com. De getoonde DMARC-pass volgt niet uit SRS: daarvoor is bijvoorbeeld een geldige, behouden DKIM-handtekening nodig die met bank.com uitlijnt. De bijbehorende DKIM-uitkomst is in dit verkorte voorbeeld niet weergegeven.

Om de SMTP-acceptatie van een alias te onderzoeken, kun je swaks gebruiken. Deze opdracht kan een testbericht verzenden; gebruik uitsluitend servers, domeinen en afzenderadressen waarvoor je toestemming hebt. Vervang de voorbeeldwaarden door gecontroleerde testgegevens, niet door onbevoegd gebruikte adressen van derden:

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK bevestigt acceptatie van de betreffende SMTP-stap, niet dat een afzonderlijke mailbox bestaat of dat definitieve aflevering slaagt. 550 User Unknown wijst op afwijzing van de ontvanger; controleer de aliasmap, doelmailbox en het ontvangersbeleid.

Voorkomen: vereenvoudig routes en beperk hops

Veel problemen verdwijnen als je de onderliggende routering vereenvoudigt. Twee ontwerpregels helpen bij de meeste hierboven beschreven situaties.

Regel 1: vermijd onnodig extern doorsturen. Bewaar zakelijke mail op het zakelijke domein en open die bijvoorbeeld via IMAP op je telefoon. Extern doorsturen kan SPF-controles bemoeilijken, gegevens via derden laten lopen en extra afzenderinstellingen vereisen. Weeg eventuele voordelen af tegen die risico's.

Regel 2: maak aliasketens zo mogelijk één hop lang.

Elke extra hop biedt weer ruimte voor lussen, gewijzigde headers of authenticatieproblemen. Eén directe hop is een bruikbaar ontwerpdoel, geen algemene protocolgrens.

Voor tijdelijke adressen of campagnes kan plusadressering handig zijn - bob+newsletter@domain.com - in plaats van telkens een alias te maken. Controleer ondersteuning en instellingen bij je provider: TrekMail, Gmail en Exchange kunnen hierin verschillen per omgeving. Sommige webformulieren weigeren bovendien het teken +, dus het werkt niet overal.

Lees voor de afweging tussen aliassen en doorsturen doorsturen via e-mailaliassen.

Wanneer het prijsmodel het probleem is

Een prijs per gebruiker kan het duur maken om voor elke functie een aparte mailbox te nemen, al vereisen aliassen of gedeelde mailboxen niet altijd een extra licentie. Extra routering kan uren onderzoek naar SRS en doorstuurbeleid vragen; dat is een mogelijk gevolg, geen vaste tijdsbesteding.

TrekMail gebruikt abonnementen op accountniveau, niet een algemene vaste prijs per domein. Het historische Starter-voorbeeld ($3.50/maand) laat zien hoe sales@, support@ en billing@ als aparte IMAP-mailboxen met eigen toegang en afzenderadres aliasroutering kunnen vereenvoudigen. Controleer actuele prijzen, rechten, mailboxlimieten en gedeelde opslag. Een eigen login betekent niet automatisch een afzonderlijk opslagquotum. Alleen in het beschreven Nano-model vereist elk uitgaand bericht, inclusief antwoorden, je eigen externe SMTP; beheerde verzending in betaalde plannen hangt van de feitelijke rechten en clientconfiguratie af.

Het historische bureauvoorbeeld noemt Pro ($10/maand) met 100 domeinen. Controleer huidige prijzen, limieten en rechten voordat je klanten toevoegt. IMAP-migratie vanuit Gmail of cPanel vraagt bevoegde brontoegang, compatibiliteitscontrole, verificatie van mappen en aantallen en een laatste synchronisatie. Contacten en agenda's moet je afzonderlijk beoordelen. Plan de DNS-overgang en test de migratie; dit is geen garantie op een onaangetaste liveomgeving of een vervanging voor back-ups.

Stel je voor het eerst domeinmail in, dan helpt e-mail aanmaken op je eigen domein je op weg. Bekijk voor actuele voorwaarden de TrekMail-prijzen - inclusief de huidige tariefstructuur en eventuele proefvoorwaarden. De hier genoemde proefperiode van 14 dagen voor een betaald abonnement met verplichte creditcard is een momentopname die je vóór aanmelding moet controleren.

Conclusie

Domeinaliassen kunnen op vijf herkenbare manieren misgaan: authenticatieproblemen bij extern doorsturen, beleidsblokkades in Microsoft 365, lussen door vergeten regels, de verkeerde verzendidentiteit en conflicten met catch-alls. Foutcodes en headers helpen de oorzaak te vinden, maar niet elke storing heeft één unieke code of één universele oplossing. SRS helpt de envelop-SPF, niet de oorspronkelijke DMARC-uitlijning.

Komen deze problemen steeds terug, kijk dan niet alleen naar instellingen. Misschien bouw je complexe omwegen om een prijs per gebruiker te vermijden. In dat geval kan een andere mailboxindeling of tariefstructuur zinvoller zijn.

Begin voor meer achtergrond over doorstuurarchitectuur en foutonderzoek bij e-mail doorsturen: instellen en problemen oplossen.