E-mail doorsturen werkt niet: diagnose in 6 stappen

Doorsturen van e-mail werkt niet. Berichten lijken te verdwijnen, de afzender krijgt geen foutmelding en de regel ziet er correct uit. Zonder zichtbare fout is bepalen waar het misgaat lastig.

Niet werkende e-mailforwards kunnen zowel door regels en beleid als door SPF, DKIM of DMARC ontstaan. De ontvangende server controleert de identiteit van de afzender; een forward kan die controle beïnvloeden. Het resultaat kan een afwijzing, spamplaatsing, vertraging of soms verlies zonder zichtbare melding zijn. Onderzoek de route in plaats van één oorzaak aan te nemen.

Loop deze lijst door voordat je DNS wijzigt. De volledige gids voor inrichting en herstel van e-mailforwards legt SPF, SRS en ARC uit. Hier richten we ons op praktische triage wanneer doorsturen nu niet werkt.

Waarom een forward soms geen zichtbare fout oplevert

De fout kan verderop in de route optreden. Een ontvangende server kan afwijzen, waarna een foutmelding naar de envelopafzender of forwarder gaat. Soms komt die niet bij de oorspronkelijke afzender terecht. Andere fouten leveren juist wel een bounce op; stilte bewijst geen specifieke oorzaak.

Bekijk headers, foutmeldingen en beschikbare logs. Een actieve regel zegt niet dat het bericht aankomt. De zes controles hieronder geven een praktische werkvolgorde. Direct DNS aanpassen zonder de spammap te bekijken kan bijvoorbeeld 45 minuten onnodig werk kosten.

Triage in 60 seconden: benoem eerst het symptoom

Neem als praktische richtlijn 60 seconden om het symptoom te classificeren voordat je instellingen verandert. De vier patronen hieronder geven aanknopingspunten, geen sluitende diagnose.

Checklist voor niet werkende e-mailforwards

Begin bij stap 1 en stap 2. Een spammap of bounce kan meteen bruikbare informatie geven. Zo voorkom je bijvoorbeeld 45 minuten DNS-werk zonder aanwijzing dat DNS de oorzaak is. Ga verder tot je de fout met gegevens hebt gelokaliseerd.

Stap 1: controleer de spammap van de bestemming

Eerste controle  |  Symptoom: geen mail, geen bounce

Het bericht kan in de spammap staan. Bij een forward van client@gmail.com naar you@outlook.com kan de laatste server een ander verzendend IP-adres zien dan SPF toestaat voor de oorspronkelijke envelopafzender. De gevolgen hangen ook van DKIM, DMARC en ontvangerbeleid af.

Actie: meld je aan bij de uiteindelijke mailbox en bekijk Ongewenst of Spam.

Herstel: markeer gevonden mail als niet ongewenst waar passend. Onderzoek vervolgens Sender Rewriting Scheme (SRS) voor herschrijving van de envelopafzender. SRS helpt SPF voor de nieuwe envelopidentiteit, maar garandeert geen DMARC-afstemming op de oorspronkelijke From of aflevering. Een intacte, afgestemde DKIM-handtekening kan zonder SRS al voldoende zijn voor DMARC.

Stap 2: lees de bounce en NDR-codes

Lees de beschikbare foutmelding  |  Symptoom: afzender krijgt een bericht over onbestelbaarheid

Lees de volledige SMTP-code en toelichting, niet alleen het onderwerp. Ze geven concrete aanwijzingen, maar sommige codes hebben meerdere mogelijke oorzaken.

Stap 3: controleer DMARC-afstemming

Controle voor Gmail, Yahoo en Outlook  |  Symptoom: geen zichtbare aflevering of afwijzing

Onderzoek DMARC zonder iedere forwardfout eraan toe te schrijven. Zelfs bij p=reject is het onjuist te zeggen dat een gewone forward zonder SRS of ARC 100% van de tijd faalt. DMARC kan slagen met een intacte, geldige DKIM-handtekening die op de zichtbare From is afgestemd. SPF of DKIM moet zowel slagen als afgestemd zijn.

Vraag het DMARC-record van het oorspronkelijke domein op:

dig _dmarc.originalsender.com TXT +short

p=reject is een beleidsverzoek, geen bewijs dat dit bericht is afgewezen. Controleer de werkelijke resultaten: SPF gebruikt de envelopidentiteit, DKIM het ondertekenende domein. DMARC vergelijkt die met de zichtbare From, niet met elkaar.

Vervolg: beoordeel relaying met SRS en ARC-ondersteuning waar passend. ARC legt eerdere authenticatieresultaten vast in een ondertekende keten; de ontvanger beslist of hij de geldige keten vertrouwt. Het garandeert geen DMARC-pass of aflevering. cPanel-redirects zijn server-side; Gmail- en Outlook-regels verschillen per uitvoering. Controleer wat de echte forwarder ondersteunt.

Stap 4: beoordeel Microsoft 365-beleid voor extern doorsturen

Controle voor Office 365  |  Symptoom: NDR met 550 5.7.520

Microsoft 365 kan automatische externe forwards bewust blokkeren. Een gebruikersregel omzeilt toepasselijk tenantbeleid niet. Laat een bevoegde beheerder de zakelijke noodzaak en een zo beperkt mogelijke uitzondering beoordelen; zet niet zonder onderzoek doorsturen voor iedereen aan.

1. Open als bevoegd beheerder Microsoft 365 Defender
2. Bekijk Email & collaboration → Policies & rules → Threat policies → Anti-spam, met mogelijk gewijzigde schermnamen
3. Beoordeel Anti-spam outbound policy (Default) en de daadwerkelijk toepasselijke, gerichte policy
4. Open waar toegestaan Edit protection settings
5. Beoordeel Automatic forwarding rules; kies alleen na toestemming en voor passend bereik On - Forwarding is enabled

Een niet beschikbare optie kan aan rechten of beleid liggen. Vraag de tenantbeheerder om onderzoek; een gebruikersinstelling heft organisatiebeleid niet op.

Stap 5: zoek routinglussen

Controleer de route  |  Symptoom: fout 5.4.14 of meerdere kopieën

Een lus ontstaat als server A naar B doorstuurt en B terug naar A. Hoplimieten kunnen dat uiteindelijk afbreken. Een voorbeeld is catch-all op domein A naar B, terwijl B bepaalde adressen terug naar A stuurt. Dubbele mail kan ook andere oorzaken hebben.

Bekijk bij vertraagde of dubbele mail deze headers:

• X-Loop
• X-MS-Exchange-Inbox-Rules-Loop
• Delivered-To met herhaling van hetzelfde adres

De gids voor domein-catch-all helpt routes plannen. Een keten mag technisch aliases bevatten, maar moet begrensd zijn en zonder lus bij een echte eindbestemming uitkomen.

Stap 6: verifieer de Gmail-bestemming

Controleer activering  |  Symptoom: regel bestaat maar stuurt niet door

Bij persoonlijke Gmail kan bevestiging van de bestemming nog ontbreken. Controleer of de verificatie is afgerond en doorsturen daarna daadwerkelijk is aangezet. Een bestaande regel alleen bewijst geen actieve forward.

Actie: zoek de bevestigingsmail van Gmail Team bij de bestemming, ook in Spam. Controleer afzender en aangevraagde bestemming voordat je bevestigt. Vraag zo nodig opnieuw verificatie aan via Gmail-instellingen → Doorsturen en POP/IMAP en controleer daarna de gekozen forwardinginstelling.

Headers lezen om forwardproblemen te onderzoeken

Mail in de spammap is aangekomen, maar filtering bewijst geen authenticatiefout. Bekijk Authentication-Results van een vertrouwde ontvangende server samen met routing en logs. Niet iedere forwardfout verschijnt in deze header.

Headers bekijken:

• Gmail: open bericht → menu met drie punten → Origineel weergeven
• Outlook: Bestand → Eigenschappen → Internetheaders; de route verschilt per versie

Illustratief headerfragment met SRS en ARC, geen volledige of canonieke ARC-syntaxis. Controleer de echte ARC-headers en validatie; dit fragment bewijst niet op zichzelf een gezonde route:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)

Het voorvoegsel SRS0= in Return-Path is een aanwijzing voor SRS-herschrijving, geen volledige verificatie. Afwezigheid bewijst niet dat alle envelopherschrijving ontbreekt of dat DMARC faalt. Controleer echte headers en de forwarder. Googles sinds 2024 aangescherpte regels voor verzending naar persoonlijke Gmail maken authenticatie belangrijk, maar gelden niet identiek voor iedere provider of ieder bedrijfsdomein.

Wanneer forwardproblemen een bedrijfsrisico zijn

Gemiste klantmail, contracten of supportvragen kunnen pas bij een vervolgcontact opvallen. Zonder betrouwbare registratie weet je mogelijk niet welke interacties ontbreken. Onderzoek klachten met concrete berichtgegevens.

Handmatig onderzoek wordt lastiger bij meer domeinen en veranderend beleid. Een authenticatiefout veroorzaakt niet automatisch een spamklacht. Google Postmaster Tools biedt onder voorwaarden geaggregeerde gegevens over verzending naar persoonlijke Gmail; beschikbaarheid, vertraging en volume beperken de dekking. Het toont niet ieder doorgestuurd bericht.

Verminder terugkerend onderzoek

Bij terugkerende problemen helpt passende forwardinginfrastructuur met goed toegepaste SRS en ARC. Blijf beleid, authenticatie en daadwerkelijke aflevering controleren: die mechanismen maken deze checklist niet voorgoed overbodig.

Los beheer: regels in Gmail of cPanel instellen, SPF per domein onderzoeken, M365-beleid controleren en wijzigingen telkens volgen.

Beschreven TrekMail-model: routes centraal definiëren met SRS en ARC op MTA-niveau waar ondersteund. Controleer de toepassing per route; de ontvanger blijft over acceptatie beslissen.

TrekMail beschrijft Postfix-gebaseerd doorsturen met SRS-envelopherschrijving en ARC-ondertekening. Een originele DKIM-handtekening moet intact blijven om te valideren; ARC bewaart eerdere resultaten maar vervangt die handtekening niet. Controleer actuele ondersteuning en verwerking per route. Ook Gmail, Outlook en Yahoo kunnen daarna eigen filtering toepassen.

Voor bureaus met tientallen klantdomeinen kan centraal beheer onderzoek in 30 losse panelen beperken. Configureer en toets iedere domeinroute en haar rechten. De gids voor klantmailbeheer helpt A→B→A-lussen vermijden zoals in stap 5.

De historische beschrijving noemt Pro voor $10/maand (100 domeinen, 50GB) en Agency voor $23.25/maand (1,000+ domeinen), met een proef van 14 dagen. Verifieer actuele SRS/ARC-functies, limieten, kaartvereiste en proefdekking voordat je kiest: vergelijk plannen bij trekmail.net/pricing.

Maak terugkerende forwardproblemen beter beheersbaar. Bekijk TrekMail-ondersteuning voor SRS en ARC en toets de actuele mogelijkheden.