E-mail doorsturen is waarschijnlijk een van de eerste functies die je instelt wanneer je een domein bezit. En vaak is het ook de eerste functie die ongemerkt ophoudt te werken.
Op het eerste gezicht is het eenvoudig: mail aan info@yourdomain.com omleiden naar je account bij @gmail.com. In de praktijk is doorsturen een tussenstap die rechtstreeks botst met de belangrijkste vertrouwensmodellen van het moderne internet: SPF, DKIM en DMARC. Bij een verkeerde configuratie volgt niet altijd een duidelijke bounce. Het bericht verdwijnt gewoon.
Voor een oprichter kan een niet-werkende doorstuurregel gemiste berichten van investeerders betekenen. Voor een MSP die 50 klantdomeinen beheert, betekent het op maandagochtend een golf aan supporttickets.
Deze gids legt uit hoe doorsturen op protocolniveau werkelijk werkt, waarom het op voorspelbare manieren mislukt en hoe je in 2026 een configuratie bouwt die bestand is tegen streng DMARC-beleid.
Het denkmodel: waarom e-mail doorsturen ingewikkelder is dan het lijkt
Voordat je een niet-werkende doorstuurregel kunt herstellen, moet je begrijpen wat er op SMTP-niveau gebeurt. Het is geen briefje doorgeven, maar een brief opnieuw posten. Dat verschil is bijzonder belangrijk.
Wanneer server A een e-mail naar jouw server stuurt, server B die als doorstuurserver fungeert, en server B het bericht aflevert bij de eindbestemming, server C, verandert een cruciale identiteit. De ontvangende server ziet het IP-adres van server B, niet dat van server A. Dat is de oorzaak van bijna elke doorstuurstoring.
Envelope en header: de twee identiteiten van een e-mail
Elke e-mail heeft twee afzonderlijke identiteitslagen. Doorsturen kan die uit de pas laten lopen:
- De envelope (P1): wat mailservers gebruiken om het bericht technisch te routeren. Bevat het
Return-Path, dat door SPF wordt gevalideerd. - De header (P2): wat je mailprogramma als afzender toont. De controles op DKIM- en DMARC-uitlijning gebruiken deze laag.
Dit gaat er mis. Wanneer je server een bericht doorstuurt, opent deze een nieuwe SMTP-verbinding met de bestemming. SPF vergelijkt het verzendende IP met het SPF-record van de oorspronkelijke afzender, maar het IP van jouw doorstuurserver is daarin niet gemachtigd. SPF faalt. Als de oorspronkelijke afzender streng DMARC-beleid voert (p=reject) en je geen SRS hebt geïmplementeerd, wijst de ontvangende server het bericht direct af.
Een concrete vergelijking: Alice stuurt een brief aan Bob. Bob stopt de brief van Alice in een nieuwe envelop met zijn eigen retouradres en stuurt die aan Carol. Carol vraagt Alice of zij de brief vanaf Bobs adres heeft verstuurd. Alice zegt van niet. Dat is een DMARC-fout, waarop de mailserver van Carol zijn beleid toepast.
Dit onderscheid tussen envelope en header vormt de basis. Elke oplossing in deze gids vloeit eruit voort.
Doorsturen, aliassen en catch-all: ken het verschil
Beheerders verwarren deze drie routeringsmethoden voortdurend. De verkeerde kiezen is de snelste route naar een ticket over verdwenen mail dat drie uur onderzoek kost.
E-mail doorsturen
Een e-mail aan één adres wordt bij een compleet andere server afgeleverd, bijvoorbeeld contact@startup.com → founder@gmail.com. Er vindt een netwerksprong plaats. Authenticatieketens breken als je ze niet expliciet afhandelt. Geschikt om meerdere domeinen in één inbox samen te brengen. Risico: hoog zonder correcte SRS/ARC-verwerking. Lees onze verdieping over de afwegingen bij de combinatie van alias en doorsturen.
E-mailaliassen
Een andere naam voor een bestaande mailbox op dezelfde server. support@company.com bezorgt in dezelfde mailbox als admin@company.com, zonder netwerksprong en zonder wijziging van de authenticatie. Geschikt voor één persoon met meerdere rollen. Risico: laag. Lees voor meer uitleg over wanneer aliassen tekortschieten en je een volwaardige mailbox nodig hebt onze keuzegids voor alias of mailbox.
Catch-all (routering met jokerteken)
Accepteert alle mail voor een niet-bestaand adres op je domein, oftewel *@domain.com. Handig om typefouten of eenmalige campagneadressen op te vangen. Risico: kritiek wanneer deze rechtstreeks naar Gmail wijst. Elk spambericht aan je domein komt in je inbox en uiteindelijk kan Gmail je doorstuurserver als spambron beschouwen. Isoleer een catch-all daarom. De volledige afweging staat in onze gids voor zakelijke e-mailconfiguratie.
| Methode | Netwerksprong? | Authenticatierisico | Meest geschikt voor |
|---|---|---|---|
| Doorsturen | Ja | Hoog (SPF/DMARC breekt) | Routering tussen domeinen/providers |
| Alias | Nee | Geen | Meerdere rollen, dezelfde mailbox |
| Catch-all | Afhankelijk van configuratie | Kritiek (spammagneet) | Typefouten, tijdelijke adressen |
Configuratiepatronen: goed, slecht en onwerkbaar
Je kunt e-mail op drie manieren doorsturen. Twee daarvan leveren problemen op. Eén werkt betrouwbaar in productie.
1. Routering aan providerzijde (de juiste aanpak)
Dit gebeurt op MTA-niveau voordat het bericht een mailbox bereikt. De server ontvangt de e-mail, herschrijft de envelope met SRS en stuurt deze meteen door. Er is geen betaalde mailboxlicentie nodig en er wordt geen opslag gebruikt. SPF en ARC worden op infrastructuurniveau afgehandeld.
Dit is de aanpak om op voort te bouwen. De doorstuurroutes van TrekMail werken op deze manier: jij bepaalt de bestemming en de infrastructuur verwerkt de authenticatieheaders. Raadpleeg de installatiegids voor mailboxdoorsturing voor de exacte stappen.
2. Mailboxregels (de oude aanpak)
Je maakt een volledig gebruikersaccount aan, betaalt $6-$30/month voor een licentie die je niet werkelijk nodig hebt, meldt je aan en maakt een inboxregel: "Als een bericht binnenkomt, stuur het door naar X."
Er zijn uitzonderingen waarin dit zinvol is: voorwaardelijk doorsturen ("stuur alleen facturen door"), auditvereisten of situaties waarin het bericht lokaal moet worden opgeslagen voordat het wordt doorgestuurd. In de meeste configuraties betaal je echter voor een gebruiker alleen om mail te routeren. Ook dit breekt DMARC zoals elke andere doorstuurmethode, en Microsoft 365 blokkeert automatisch doorsturen standaard. Daarover meer bij de storingen.
3. Doorsturen aan clientzijde (volledig vermijden)
Dit is een regel in Outlook Desktop of Apple Mail op je eigen computer. Je laptop moet aanstaan, actief zijn en internetverbinding hebben om het bericht door te sturen. Het werkt niet wanneer je reist, tijdens een herstart of om 2am wanneer die belangrijke e-mail binnenkomt.
Er is geen productiescenario waarin dit de juiste keuze is. Vertrouw je hier nu op, pas dat dan meteen aan.
Checklist voor een veilige configuratie
Voer deze vier controles uit voordat je een doorstuurroute activeert. Sla je er één over, dan komt dat later terug als probleem.
1. De lussencontrole
Controleer dat het bestemmingsadres niet terugstuurt naar de bron. A→B→A is een oneindige lus. Moderne servers detecteren dit met limieten voor het aantal sprongen en geven een 5.4.14 hop count exceeded-NDR terug, maar dan heb je je verzendreputatie al belast. Breng de routes voor activering in kaart.
2. De headerinspectietest
Stuur vanaf een extern account, zoals persoonlijk Gmail, Yahoo of iets buiten je domein, een testbericht naar het doorgestuurde adres. Open bij de bestemming de volledige headers en zoek de header Authentication-Results. Je wilt spf=pass door SRS-herschrijving of dkim=pass zien. Staat er dmarc=fail, dan is de configuratie niet productierijp.
3. De Reply-To-test
Beantwoord een doorgestuurd bericht. Gaat het antwoord naar de oorspronkelijke afzender of naar het adres van de doorstuurserver? Het moet naar de oorspronkelijke afzender gaan. Komt het bij de doorstuurserver terecht, dan is je envelope-configuratie verkeerd en ontstaat voor alle betrokkenen een verwarrend gespreksspoor.
4. Controle van uitgaand beleid
Gebruik je Microsoft 365 of Google Workspace als relaybestemming, controleer dan in de instellingen van het uitgaande spamfilter of automatisch doorsturen is toegestaan. M365 blokkeert dit standaard. Bij een verkeerde configuratie kunnen doorgestuurde berichten stil worden weggefilterd zonder melding aan de oorspronkelijke afzender.
Veelvoorkomende storingen
Wanneer doorsturen niet werkt, valt de oorzaak vrijwel altijd in een van deze specifieke patronen. Het patroon herkennen bespaart een uur doelloos headers lezen.
1. Stil wegfilteren door DMARC
Dit is in 2026 de meest voorkomende oorzaak van verdwijnende mail en is onzichtbaar: geen NDR, geen foutmelding, niets. Het bericht komt gewoon niet aan.
Het scenario: een bank, betalingsverwerker of SaaS-leverancier stuurt met streng p=reject-DMARC-beleid een bericht aan je domein. Jij stuurt het door naar Gmail. Het IP van je doorstuurserver breekt SPF. Als je server ook de inhoud aanpast, bijvoorbeeld met een disclaimer, of het onderwerp wijzigt met [External], breekt DKIM eveneens. SPF-fout + DKIM-fout = DMARC-fout. Gmail wijst het bericht af.
De oplossing is SRS op de doorstuurserver implementeren zodat SPF slaagt en de inhoud ongemoeid laten zodat DKIM geldig blijft. Beheer je de infrastructuur niet zelf, dan heb je een doorstuurprovider nodig die dit afhandelt. Lees voor een diepere blik op DMARC-fouten in doorstuurketens onze uitleg van DMARC en veilige e-mail.
2. De Microsoft-blokkade 550 5.7.520
Symptoom: de oorspronkelijke afzender ontvangt een NDR met code 550 5.7.520 Access denied, your organization does not allow external forwarding.
Het uitgaande spamfilter van M365 doet precies waarvoor het is bedoeld: automatisch doorsturen naar externe adressen blokkeren. Open voor de oplossing het Microsoft Defender-portaal → Email & Collaboration → Policies & Rules → Threat policies → Anti-spam policies → Edit the outbound policy → zet "Automatic forwarding rules" op "On - forwarding is enabled".
Het is niet intuïtief en Microsoft heeft de instelling diep weggestopt. De foutcode geeft echter een nauwkeurige diagnose: wanneer je deze ziet, weet je precies waar je moet zijn.
3. De afwezigheidslus
Gebruiker A stuurt door naar gebruiker B. Gebruiker B stelt een automatisch antwoord in. Gebruiker A mailt gebruiker B. De automatische reactie van B gaat naar A. De server van A stuurt dat antwoord door naar B. De server van B reageert opnieuw.
Moderne mailservers gebruiken headers zoals X-Loop en X-Auto-Response-Suppress om dit te herkennen en te stoppen. Oudere of verkeerd geconfigureerde systemen kunnen nog steeds binnen enkele minuten duizenden berichten genereren. Controleer automatische antwoorden wanneer je doorsturen tussen accounts instelt.
4. DKIM breekt door aanpassing
DKIM ondertekent een cryptografische hash van de berichtinhoud. Zodra iets in het ondertekende gedeelte verandert, zelfs door een voettekst van één regel, is de handtekening ongeldig. Veel zakelijke mailsystemen voegen aan elk uitgaand bericht een juridische disclaimer toe. Wordt die na het maken van de DKIM-handtekening toegevoegd, dan is de handtekening bij de bestemming ongeldig.
Zie je dkim=fail (body hash did not verify) in de headers van een doorgestuurd bericht, dan is dit vrijwel altijd de oorzaak.
Foutzoekprocedure: van symptoom naar oplossing
| Symptoom | Waarschijnlijke oorzaak | Diagnostische stap |
|---|---|---|
Afzender ontvangt NDR 5.7.1 |
SPF / relay geweigerd | Controleer of het IP van je doorstuurserver op een blokkeerlijst staat. Controleer SPF-authenticatie in de headers. |
Afzender ontvangt NDR 5.4.14 |
Routeringslus | Controleer alle doorstuurregels op circulaire routes (A → B → A). |
| Geen e-mail, geen NDR (stil weggefilterd) | DMARC-afwijzing / spamfilter | Controleer de spammap van de bestemming. Zoek in de headers naar dmarc=fail. |
550 5.7.520 Access denied |
Blokkade in uitgaand M365-beleid | Wijzig het uitgaande spambeleid van M365 Defender: schakel automatisch doorsturen in. |
| E-mail komt aan maar ziet er beschadigd uit | DKIM-bodyhash mislukt | Zoek in de headers naar dkim=fail (body hash did not verify). Schakel het invoegen van voetteksten/disclaimers uit. |
| Antwoord gaat naar doorstuurserver, niet naar oorspronkelijke afzender | Verkeerde Reply-To / envelope-configuratie | Controleer of de doorstuurconfiguratie de Reply-To-header van de oorspronkelijke afzender bewaart. |
Waarom doorsturen in productie misgaat: SRS en ARC
Eenvoudige doorstuurregels volstaan niet in een productieomgeving. Je hebt infrastructuur nodig die SRS en ARC begrijpt. Dit is wat beide doen en waarom ze allebei belangrijk zijn.
SRS: Sender Rewriting Scheme
SRS verhelpt de SPF-fout die door de netwerksprong ontstaat. Je doorstuurserver herschrijft het afzenderadres in de envelope, zodat de bestemming SPF tegen jouw domein kan valideren in plaats van tegen dat van de oorspronkelijke afzender.
Voor SRS:
MAIL FROM: alice@bank.comNa herschrijving met SRS:
MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.comDe ontvangende server voert SPF uit voor forwarder.com. Dat slaagt omdat jouw server gemachtigd is. Bounces gaan via het gecodeerde adres nog steeds terug naar alice@bank.com. SPF is geldig zonder het retourpad te breken.
SRS is essentieel. Zonder SRS mislukt bij de bestemming de authenticatie van elk doorgestuurd bericht van een afzender met streng SPF-beleid. Lees onze uitgebreide gids voor e-mail op je eigen domein voor een volledige uitleg van SRS in doorstuurketens. Routeer je specifiek naar een Gmail-inbox, bekijk dan onze stapsgewijze uitleg om domeinmail veilig naar Gmail door te sturen met SRS en correct ingestelde functie Verzenden als.
ARC: Authenticated Received Chain
SRS herstelt SPF, maar lost DMARC-uitlijning niet volledig op. Daar komt ARC in beeld. Met ARC kan je doorstuurserver het bericht cryptografisch voorzien van een zegel dat verklaart: "Ik heb de authenticatie van dit bericht bij ontvangst gecontroleerd en deze was geldig."
Google en Microsoft erkennen allebei ARC-zegels van vertrouwde tussenservers. Als zo'n zegel aanwezig en vertrouwd is, kunnen deze providers een bericht accepteren, ook wanneer de oorspronkelijke SPF/DMARC-controles door de doorstuursprong zouden mislukken. Het is in feite een chain-of-custody-record voor e-mailauthenticatie.
ARC is vastgelegd in RFC 8617 en is de huidige standaard om authenticatie bij legitiem doorsturen te behouden. Zonder ARC kan strikt p=reject-DMARC-beleid van de oorspronkelijke afzender ervoor zorgen dat grote providers doorgestuurde berichten weigeren, zelfs als SRS actief is.
De gevarenzone van catch-all
Doorsturen wordt vaak gecombineerd met een catch-all-configuratie en die combinatie verdient een specifieke waarschuwing. Wijs je een catch-all-jokerteken naar Gmail, dan belandt elk spambericht aan willekeurige adressen op je domein bij Gmail. Gmail ziet daarbij jouw doorstuurserver als bron. Spamklachten tegen je IP kunnen snel oplopen, waardoor ook de verzendreputatie van je domein voor legitieme mail keldert.
Heb je een catch-all nodig, isoleer deze dan in een aparte mailbox met spamfiltering op serverniveau en stuur hem niet door naar een persoonlijke inbox. Het volledige configuratiepatroon staat in onze gids voor e-mail instellen op je domein.
Waar TrekMail van pas komt
De oude aanpak voor doorsturen was zelf een MTA met SRS- en ARC-ondersteuning bouwen of licentiekosten per gebruiker betalen om alleen mail te routeren. Geen van beide opties paste bij beheerders van meer dan een handvol domeinen.
Google of Microsoft $6/user/month betalen, 10 doorstuuradressen nodig hebben en mogelijk voor 10 ongebruikte accounts betalen, of aliaslimieten bereiken en noodgrepen stapelen: het is een heffing op routering.
TrekMail kiest voor hosting tegen een vast tarief. Je betaalt voor een abonnement, niet voor gebruikers. Doorstuurroutes, aliassen en catch-all-configuratie zijn inbegrepen en worden op serverniveau beheerd, met SRS-conforme doorsturing in de infrastructuur. Jij stelt de route in; het platform verwerkt authenticatieheaders, TLS-handhaving en bezorging. Geen kosten per adres en geen worsteling met uitgaand spambeleid om basisfuncties beschikbaar te maken.
Voor een zelfstandige oprichter betekent dit dat hello@yourdomain.com in minder dan vijf minuten naar Gmail kan worden gerouteerd, zonder een complete mailserver op te zetten. Voor een team vindt elke wijziging in het dashboard plaats, zonder DNS-archeologie. Voor een bureau met 100+ klantdomeinen worden regels centraal beheerd en consequent toegepast, zonder authenticatiefouten die op vrijdag om 6pm tot escalaties leiden.
Het Pro-abonnement ($10/month, of $8/month bij jaarlijkse betaling) omvat externe catch-all en mailboxdoorsturing. Het Agency-abonnement ($29/month) schaalt naar 1,000+ domeinen en biedt API-toegang voor bulkbeheer van routes. Alle betaalde abonnementen omvatten een gratis proefperiode van 14-day (kaart vereist).
Bekijk op trekmail.net hoe TrekMail doorsturen op elke schaal afhandelt.
Conclusie
E-mail doorsturen is geen functie die je eenmaal instelt en daarna vergeet. Het is een actieve routeringsbewerking die de fundamentele authenticatiemodellen van het internet raakt. De storingen zijn voorspelbaar: SPF breekt door de IP-wijziging, DKIM door aanpassing van inhoud en DMARC wijst af bij mislukte uitlijning. Zodra je begrijpt wat er op protocolniveau gebeurt, zijn ze allemaal op te lossen.
De praktische conclusies: gebruik doorsturen aan serverzijde met SRS en ARC, nooit regels aan clientzijde. Test je headers vóór activering. Let op de blokkade in uitgaand M365-beleid. Houd catch-all geïsoleerd. En betaal bij beheer over meerdere domeinen niet per gebruiker om alleen mail te routeren.
Met de juiste infrastructuur kan e-mail doorsturen betrouwbaar werken. Bij een verkeerde configuratie verdwijnen je belangrijkste berichten spoorloos. De keuze is niet ingewikkeld.
