SRS bij e-mail doorsturen: werking en beperkingen

Je stelt een doorstuurregel in: contact@your-agency.com → you@gmail.com. Je test hem en alles werkt. Twee weken later komt een contract van een grote zakelijke klant niet aan, ook niet in de spammap. In de logs staat 550 5.7.1 Unauthenticated email. Ook 550 5.7.520 Access denied kan verschijnen bij uitgaand doorsturen vanuit Microsoft 365. De eerste melding kan verschillende authenticatieproblemen aangeven; de tweede kan wijzen op het beleid voor extern doorsturen. Een afwijzing kan een foutmelding aan de doorsturende server opleveren, maar de gebruiker ziet die niet altijd.

Een mogelijke oplossing voor SPF-problemen bij doorsturen is Sender Rewriting Scheme, SRS, mits goed ingesteld. Een extra doorstuurstap kan de SPF-controle verstoren. In 2026 stellen Google en Yahoo eisen aan de authenticatie van afzenders, maar dat betekent niet dat iedereen een DMARC-beleid met p=reject moet publiceren (de eisen van Google voor e-mailafzenders). Een SPF-fout leidt bovendien niet automatisch tot een DMARC-fout of stille verwijdering. Deze gids legt uit wat SRS op protocolniveau doet, wat het niet oplost en welke aanvullende maatregelen nuttig kunnen zijn.

Voor het bredere overzicht lees je onze gids over e-mail doorsturen instellen en veelvoorkomende problemen oplossen.

Wat is Sender Rewriting Scheme (SRS)?

SRS herschrijft de afzender in de SMTP-envelop om SPF-problemen door het doorsturen van e-mail te beperken. Voordat je server een bericht doorstuurt, vervangt hij het oorspronkelijke envelopadres (MAIL FROM) door een adres op je doorstuurdomein. De ontvangende server controleert SPF dan voor dat domein. Met passende DNS-records en een geautoriseerde verzendende server kan die controle slagen. Zonder herschrijven kan de oorspronkelijke afzender in de envelop blijven staan terwijl de nieuwe server niet namens dat domein mag verzenden. Dat kan SPF laten mislukken; de DMARC-uitkomst hangt daarnaast af van domeinafstemming en DKIM.

De twee lagen van de afzenderidentiteit

Bij onderzoek naar doorstuurproblemen helpt het om twee lagen uit elkaar te houden. SPF controleert de afzenderidentiteit uit de envelop. DMARC vergelijkt het zichtbare afzenderdomein met het domein dat via SPF of DKIM is geauthenticeerd. Doorsturen kan die afstemming verstoren.

De envelop wordt gebruikt voor het transport en voor SPF. De ontvanger ziet het envelopadres doorgaans niet in de berichtweergave, maar kan het in de ruwe headers terugvinden. De afzender in de berichtheader verschijnt in het e-mailprogramma en vormt het uitgangspunt voor DMARC-domeinafstemming. Een nieuwe SMTP-verbinding bij doorsturen kan de SPF-controle verstoren, zonder dat daardoor noodzakelijk alle verdere authenticatiecontroles mislukken.

Een extra SMTP-stap: waarom doorsturen SPF kan verstoren

Bij doorsturen opent je server een nieuwe SMTP-verbinding met de bestemming: een extra stap, of hop. De envelopafzender kan nog steeds alice@bank.com zijn, terwijl het IP-adres van de verbinding nu bij jouw server hoort. SPF vergelijkt dat IP-adres met het SPF-record van bank.com. Als jouw server niet geautoriseerd is, mislukt de controle. Publiceert bank.com DMARC p=reject, dan vraagt het domein om afwijzing bij een DMARC-fout. Geldige, afgestemde DKIM kan DMARC echter nog laten slagen. Ook is een afwijzing niet per definitie stil: de doorsturende server kan een foutmelding ontvangen en een bezorgfout terugsturen.

Dit scenario hoeft niet op een fout in de configuratie te wijzen. Het volgt uit de extra SMTP-stap terwijl de oorspronkelijke envelopafzender behouden blijft. SRS is een gangbare manier om dit specifieke SPF-probleem aan te pakken, maar de uitkomst hangt van de daadwerkelijke verzendroute en autorisatie af.

Hoe Sender Rewriting Scheme (SRS) de envelop herschrijft

SRS herschrijft het envelopadres MAIL FROM naar je doorstuurdomein voordat de nieuwe SMTP-verbinding wordt geopend. Daarmee kan SPF op dat domein worden gecontroleerd. De zichtbare header From: hoeft hiervoor niet te worden gewijzigd.

# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)

# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)

In dit voorbeeld controleert de bestemming SPF voor your-domain.com, waarvoor de verzendende server geautoriseerd is. De ontvanger blijft From: alice@bank.com zien. SRS kan zo de afzonderlijke SPF-controle laten slagen, maar daarmee is de afstemming met het oorspronkelijke zichtbare afzenderdomein nog niet hersteld.

De opbouw van een SRS-adres

Het SRS-adres in Return-Path lijkt een willekeurige reeks, maar elk onderdeel heeft een functie. Als je de opbouw kent, kun je beter controleren of het herschrijven werkt en mogelijke fouten onderzoeken. Details verschillen per implementatie.

Voorbeeld: SRS0=4fac=PM=bank.com=alice@your-domain.com

De keerzijde: SRS herstelt geen SPF-domeinafstemming

Een belangrijk onderscheid: SRS kan de SPF-controle laten slagen, maar herstelt niet de SPF-domeinafstemming met de oorspronkelijke zichtbare afzender. DMARC kan slagen via afgestemde SPF of via geldige, afgestemde DKIM. Daarom kunnen berichten ook na een correcte SRS-configuratie nog authenticatieproblemen hebben.

Voor DMARC moet het via SPF of DKIM geauthenticeerde domein volgens de toepasselijke afstemmingsregels overeenkomen met het domein in de zichtbare header From:. In dit SRS-voorbeeld:

• SPF-controle: PASS - het IP-adres is geautoriseerd voor envelopdomein your-domain.com
• SPF-domeinafstemming: FAIL - envelop your-domain.com ≠ berichtheader bank.com

In dit scenario is geldige, afgestemde DKIM nodig om DMARC te laten slagen. Of de handtekening geldig blijft, hangt af van de ondertekende headers, het bericht en de canonicalisatie. Waarschuwingsbanners met “External Email”, toegevoegde antivirusmeldingen of MIME-conversies van 8-bit naar 7-bit kunnen DKIM verstoren als ze de ondertekende onderdelen wijzigen.

Als zowel SPF-domeinafstemming als de relevante DKIM-validatie mislukt, kan ook DMARC mislukken. Afhankelijk van het beleid van de afzender en de ontvangende server kan het bericht dan worden afgewezen, ook al werkte de SRS-herschrijving zelf correct.

ARC als aanvulling op Sender Rewriting Scheme

ARC (Authenticated Received Chain, RFC 8617) kan SRS aanvullen. SRS herschrijft de envelop; ARC legt de waargenomen authenticatieresultaten vast in een ondertekende keten. De volgende ontvanger kan die informatie meewegen. ARC verklaart een bericht niet automatisch veilig of betrouwbaar.

ARC voegt drie headers toe: ARC-Authentication-Results, ARC-Message-Signature en ARC-Seal. Daarmee kunnen eerdere authenticatieresultaten beschikbaar blijven na tussenliggende verwerking. De berichthandtekening blijft echter gevoelig voor relevante wijzigingen na het ondertekenen; ARC is niet bestand tegen iedere latere wijziging van het bericht.

Belangrijke beperking: de ontvanger bepaalt of hij de ARC-ondertekenaar vertrouwt en wat hij met de resultaten doet. Beheerders van Microsoft 365 kunnen, wanneer nodig en ondersteund in hun tenant, via PowerShell (Set-ArcConfig) een vertrouwde ondertekenaar instellen. Doe dit alleen als bevoegde beheerder en volgens het geldende beleid. Het vertrouwen van Gmail wordt door de ontvangende dienst bepaald en is niet handmatig af te dwingen.

Bij productieomgevingen kunnen SRS en ARC verschillende problemen aanpakken: SRS ondersteunt de SPF-controle na doorsturen, terwijl ARC eerdere authenticatieresultaten kan doorgeven wanneer DKIM wordt verstoord. Ze zijn niet voor elke route samen noodzakelijk en vormen evenmin een garantie voor acceptatie door alle grote providers.

SRS-problemen onderzoeken: een checklist

Als doorgestuurde berichten niet aankomen, helpt deze checklist om onderscheid te maken tussen SRS-problemen, authenticatiefouten en blokkades die eerder in de route ontstaan.

1. Controleer de Return-Path-header

Stuur vanuit een extern account een testbericht via de doorstuurroute. Bekijk bij de uiteindelijke bestemming de ruwe headers. De voorbeelden hieronder illustreren mogelijke resultaten, geen gegarandeerde uitkomsten.

# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)

# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)

2. Controleer uitgaande blokkades in Microsoft 365

Wordt doorsturen vanuit Microsoft 365 door het tenantbeleid geblokkeerd, dan gebeurt dat voordat het bericht de tenant verlaat. SRS op de ontvangende server kan die blokkade niet verhelpen.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Laat een bevoegde beheerder de Outbound Spam Filter Policy in het Defender-portaal controleren en alleen volgens het afgesproken beveiligingsbeleid aanpassen. Probeer de blokkade niet via een andere route te omzeilen. SRS op de ontvangende server verandert dit uitgaande beleid niet.

3. Controleer op routeringslussen

Als A naar B doorstuurt en B terug naar A, kan een routeringslus ontstaan, afhankelijk van de ingestelde regels en beveiligingen. Zoek in de logs naar meldingen als:

554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected

Een alternatief voor doorsturen: echte mailboxen

postsrsd instellen, HMAC-sleutels beheren en fouten in DMARC-domeinafstemming onderzoeken kost beheerwerk wanneer zakelijke e-mail via persoonlijke inboxen loopt om kosten per mailbox te vermijden. SRS lost een specifiek probleem binnen die architectuur op. Een rechtstreeks gehoste mailbox kan de extra doorstuurstap wegnemen, al vraagt ook die oplossing om correct beheer en authenticatie.

In plaats van contact@client-domain.com naar Gmail door te sturen en SRS te beheren, kun je contact@client-domain.com als IMAP-mailbox bij TrekMail hosten. Je kunt die mailbox benaderen met een ondersteunde IMAP-client of integratie, ook binnen een geschikte Gmail-omgeving waar dat wordt ondersteund. De aflevering gaat dan rechtstreeks naar de gehoste mailbox, zonder extra doorstuurstap of daarvoor benodigde envelopherschrijving. Dat neemt niet alle authenticatie- of bezorgrisico's weg. Vergelijk de aanpakken in onze gids over domeinmail doorsturen naar Gmail, of bekijk de afwegingen in onze vergelijking van aliassen en mailboxen.

Beheer je meerdere klantdomeinen? Door ze bij TrekMail onder te brengen met afzonderlijke mailboxen kun je centraal beheer vereenvoudigen, in plaats van SRS op iedere klantserver te onderhouden. De beschikbare scheiding, mogelijkheden en inrichtingstijd hangen af van het abonnement en je configuratie. Onze gids over e-mailhosting voor meerdere domeinen bespreekt hoe je die aanpak opschaalt en het configuratiewerk beperkt.

Het beschreven aanbod van TrekMail begint bij $3.50 per maand met een gratis proefperiode van 14 dagen. Controleer de actuele prijzen, voorwaarden en beschikbare functies. Stel echte mailboxen in als rechtstreekse hosting beter bij je werkwijze past.