Domeinmail doorsturen: diagnose met SRS en ARC

E-mail doorsturen op je domein betekent dat je server het bericht opnieuw verzendt via een nieuwe SMTP-verbinding. Zonder herschrijving kan de identiteit van de oorspronkelijke afzender in de envelop blijven staan. Dat verschil kan authenticatie en bezorging verstoren; of je een bounce ziet, hangt af van de route en afhandeling.

Zonder passende authenticatie kan doorgestuurde mail bij Gmail in spam belanden of worden geweigerd, bij Yahoo een harde 550-weigering krijgen en bij Microsoft 365 op beleid stuiten. Niet elke storing is aan jouw kant direct zichtbaar.

Deze gids bespreekt drie benaderingen voor doorsturen in 2026, foutcodes die je bij grote providers kunt tegenkomen en een controlelijst voor een eerste diagnose in minder dan tien minuten. Begin voor de volledige configuratie met onze complete gids voor het instellen en herstellen van e-maildoorsturing.

Waarom doorsturen SPF kan laten mislukken

Bij doorsturen wordt jouw server de verzendende SMTP-server, terwijl de Return-Path naar het oorspronkelijke domein kan blijven verwijzen. Als jouw IP niet is toegestaan in het SPF-record van dat domein, mislukt SPF. Bij DMARC p=reject kan de ontvanger weigeren als ook geen geldige, uitgelijnde DKIM-handtekening overblijft; SPF-falen alleen betekent niet automatisch verwijdering.

Een mogelijke foutvolgorde:

1. alice@bank.com mailt naar info@yourdomain.com. Het SPF-record van de bank staat de eigen mailservers toe.
2. Jouw server bezorgt opnieuw bij you@gmail.com. Gmail ziet jouw IP, maar de Return-Path verwijst nog naar bank.com.
3. Jouw IP staat niet in het SPF-record van bank.com. SPF mislukt in dit voorbeeld.
4. Wijzigingen aan ondertekende inhoud, zoals een footer of een ondertekend onderwerp, kunnen ook DKIM ongeldig maken. Als geen uitgelijnde authenticatie slaagt, mislukt DMARC en kan de ontvanger het afwijsbeleid toepassen.

Een bounce kan bij de oorspronkelijke afzender terechtkomen, vertraagd worden of ontbreken, afhankelijk van de fout en configuratie. Controleer daarom logs en retourroutes.

Een catch-all kan dit probleem vergroten doordat ook spam via jouw doorstuur-IP gaat. Dat kan de reputatie en bezorging bij Gmail schaden. Legitieme mail kan vervolgens in spam belanden of worden geweigerd; het verloop is niet voor iedere route hetzelfde.

Twijfel je of doorsturen bij jouw situatie past? Bekijk vóór de inrichting de afwegingen bij het doorsturen van e-mailaliassen.

De 3 patronen voor betrouwbaarder doorsturen

Deze drie benaderingen pakken verschillende risico's aan en kunnen elkaar aanvullen. Niet iedere infrastructuur heeft ze alle drie nodig, en geen combinatie garandeert bezorging bij iedere ontvanger. Kies op basis van je authenticatieroute en het ontvangende beleid.

1. Sender Rewriting Scheme (SRS)

SRS herschrijft de envelopafzender naar het domein van de doorstuurdienst. SPF kan dan slagen als dat domein de verzendende server autoriseert. De gecodeerde retourinformatie helpt bounces terug te leiden naar de oorspronkelijke afzender, mits de SRS-afhandeling goed werkt.

Vóór SRS:

MAIL FROM: <alice@bank.com>

Na SRS:

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

De beperking: SPF voor het doorstuurdomein is doorgaans niet uitgelijnd met het oorspronkelijke From-domein. SRS alleen laat DMARC dus niet slagen. Een behouden, uitgelijnde DKIM-handtekening kan dat wel; als die faalt, kan de ontvanger eventueel een vertrouwde ARC-keten meewegen.

2. Authenticated Received Chain (ARC)

ARC (RFC 8617) beschermt vastgelegde authenticatieresultaten over tussenliggende mailservers. De doorstuurdienst voegt drie cryptografisch gekoppelde headers toe. Die beschermen de geschiedenis, maar bewijzen niet op zichzelf dat de vastgelegde resultaten betrouwbaar zijn.

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

Google en Microsoft kunnen ARC meenemen bij hun bezorgbeslissing. Als authenticatie op de laatste hop mislukt, kan een vertrouwde ARC-keten aanleiding geven om toch te accepteren. Een geldige keten is geen acceptatiegarantie en verandert een mislukte DMARC-controle niet automatisch in een geslaagde.

Vertrouwen hangt af van het beleid van de ontvanger en de reputatie van de tussenpartij. Een nieuw ondertekendomein of nieuw IP krijgt niet automatisch dat vertrouwen.

3. Een transparante doorgang (DKIM behouden)

Behoud de oorspronkelijke DKIM-handtekening door ondertekende inhoud zo min mogelijk te wijzigen: geen toegevoegde footer, herschreven onderwerp of inhoudelijke scannerwijzigingen. DKIM controleert de berichtinhoud en geselecteerde headers volgens canonicalisatieregels. Niet iedere bytewijziging breekt de handtekening, maar wijzigingen aan ondertekende inhoud kunnen dat wel.

Moeilijk te vinden storingen ontstaan vaak door berichtwijzigingen. Een spamfilter voegt bijvoorbeeld "Dit bericht is gescand door MailGuard" toe. De verzendlogs tonen dat niet altijd duidelijk. Een dkim=fail (body hash did not verify) in Authentication-Results bij de ontvanger kan de aanwijzing zijn, als je een berichtkop of diagnostisch exemplaar kunt inzien.

DKIM-behoud helpt alleen als een geldige handtekening de hele route overleeft en met het oorspronkelijke From-domein uitgelijnd is. Als SPF niet uitgelijnd is en die DKIM-handtekening faalt, mislukt DMARC; de uiteindelijke afhandeling blijft afhankelijk van het ontvangende beleid.

Hoe grote providers storingen bij doorsturen afhandelen

Microsoft, Google en Yahoo kunnen mail op basis van beleid, authenticatie of reputatie blokkeren of anders indelen. Yahoo kan bijvoorbeeld een 550-weigering geven, maar er is geen universeel foutpatroon per provider. Lees de volledige SMTP-reactie en logs om te bepalen of de blokkade bij de bron, onderweg of bij de ontvanger ontstaat.

Microsoft 365 (Exchange Online)

Automatisch extern doorsturen kan in Microsoft via het uitgaande antispambeleid van Defender worden geblokkeerd. Als dat beleid op de afzender van toepassing is, kan de mail stoppen voordat jouw doorstuurdienst wordt bereikt. Controleer de actuele tenantinstellingen.

Een bounce met 5.7.520 kan naar de oorspronkelijke envelopafzender gaan. De beheerder van het ontvangende postvak ziet die niet noodzakelijk. Gebruik message trace en verzendlogs om de precieze route te controleren.

Google Workspace / Gmail

Een mogelijke expliciete weigering is 550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy. Die kan optreden bij p=reject als geen uitgelijnde authenticatie slaagt en de ontvanger geen beleidsuitzondering toepast. Het ontbreken van SRS of ARC alleen is niet de beslissende voorwaarde.

Ook reputatie kan een rol spelen. Spam uit een catch-all doorsturen kan jouw IP-reputatie in dagen of weken schaden en spamplaatsing of weigering veroorzaken. Of er een foutcode of bounce ontstaat, hangt van de concrete afhandeling af.

Yahoo / AOL

Bij Yahoo kan onvoldoende authenticatie leiden tot een harde 550-weigering, maar niet iedere doorgestuurde mail wordt meteen geweigerd. Tags zoals [FWD] of [External] kunnen DKIM breken als het onderwerp ondertekend is. SPF-falen en DKIM-falen verhogen het risico op DMARC-falen; een claim van 100% weigering is zonder concrete beleids- en berichtgegevens niet gerechtvaardigd. Ook oudere configuraties moeten per route worden onderzocht.

Controlelijst voor de diagnose

Doorloop bij een storing deze stappen voordat je instellingen wijzigt:

1. Lees de Authentication-Results-header bij de ontvanger ("Origineel weergeven" in Gmail; berichtbron in Outlook).

   Authentication-Results: mx.google.com;
     spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
     dkim=fail (body hash did not verify)
     dmarc=fail (p=REJECT)

   spf=fail → controleer envelopdomein, verzend-IP en SPF; ontbrekende of foutieve SRS is een mogelijke oorzaak.
   dkim=fail (body hash) → onderzoek veranderingen aan ondertekende inhoud en transportproblemen.
   Als geen uitgelijnde SPF- of DKIM-controle slaagt, mislukt DMARC; de ontvanger beslist over weigering en eventuele ARC-uitzonderingen.
2. Controleer routeringslussen. 5.4.14 Hop count exceeded wijst op een overschreden hoplimiet; lees de context. Teken de volledige keten: A→B→C→A is een mogelijke lus.
3. Test Reply-To. Een antwoord gebruikt normaal Reply-To als die aanwezig is, anders From. Controleer beide headers als het antwoord onverwacht bij de doorstuurdienst terechtkomt; dat bewijst niet op zichzelf dat From herschreven is.
4. Controleer ieder onderdeel dat het bericht verwerkt. Spamfilters, virusscanners, mailinglijstsoftware en antiphishingtools kunnen ondertekende inhoud wijzigen. Niet iedere wijziging maakt DKIM ongeldig; bekijk de ondertekende velden en canonicalisatie.
5. Controleer het catch-allvolume. Veel doorgestuurde spam kan de bezorging bij Gmail schaden, zelfs als afzonderlijke berichten authenticatiecontroles doorstaan.

Twijfel je nog tussen doorsturen en aparte adresroutering? Vergelijk domeinaliassen en postvakken: ze lossen verschillende problemen op en kennen andere storingsrisico's.

De doorstuurinfrastructuur van TrekMail

Bij zelfbeheerde Postfix kunnen postsrsd voor SRS, OpenARC voor ARC, sleutelrotatie en behoud van ondertekende inhoud relevante onderdelen zijn. Dit zijn vier afzonderlijke aandachtspunten. Welke componenten nodig zijn, hangt af van je ontwerp; soortgelijke bezorgklachten kunnen verschillende oorzaken hebben.

DKIM opnieuw ondertekenen door de doorstuurdienst is een afzonderlijke ontwerpkeuze, geen algemene ARC-verplichting. Een extra handtekening kan de doorstuurdienst authenticeren, maar herstelt niet automatisch DMARC-uitlijning met de oorspronkelijke From. Behoud daarom de oorspronkelijke geldige DKIM-handtekening en controleer hoe de ontvanger ARC beoordeelt; een ontbrekende nieuwe handtekening verklaart niet iedere storing.

Controleer in de actuele TrekMail-documentatie of jouw route OpenARC, opnieuw ondertekenen met DKIM en automatische SRS gebruikt. Die functies hebben verschillende doelen en garanderen geen bezorging. Stel het doeladres in via de instellingen voor postvakdoorsturing en controleer met testberichten dat de ondertekende inhoud behouden blijft.

De vermelde abonnementen zijn Pro ($10/maand) en Agency ($23.25/maand), met postvakdoorsturing en een gratis proefperiode van 14 dagen waarvoor een creditcard nodig is. Nano ($0, 10 domeinen, eigen SMTP) en Starter ($3.50/maand, 50 domeinen) worden zonder doorsturing vermeld. Controleer vóór aankoop de actuele functies, prijzen en limieten in de volledige abonnementsvergelijking op trekmail.net/pricing.

Conclusie

Betrouwbaar e-mail doorsturen op je domein in 2026 vraagt aandacht voor de envelopafzender, behoud van uitgelijnde DKIM en het beleid van de ontvanger. SRS en ARC kunnen helpen, maar zijn geen universele verplichting of garantie. Een extra DKIM-handtekening van de doorstuurdienst vervangt de oorspronkelijke uitlijning niet.

Begin de diagnose met Authentication-Results uit een vertrouwde ontvangende server. Die header toont de daar uitgevoerde controles; gebruik ook eerdere headers en logs om de hele route te reconstrueren.

Wil je Postfix niet zelf beheren? Bekijk professionele e-mail op je domein instellen met TrekMail. Een eenvoudige inrichting kan ongeveer 15 minuten duren; controleer de actuele ondersteuning voor SRS, ARC en DKIM en test je route.