Je stelt een e-maildoorstuurregel in en de test werkt. Twee weken later ontbreekt het contract van een klant. Niet in spam en zonder zichtbare niet-bezorgingsmelding. In de logs vind je: 550 5.7.1 Unauthenticated email from domain.com.
Deze fout kan verschillende authenticatieoorzaken hebben. Ontbrekende of verkeerd ingestelde SRS is een mogelijkheid om te onderzoeken, geen vaststaande oorzaak. Bij doorsturen verzendt je server vanaf zijn eigen IP een bericht waarvan de envelopafzender bij een ander domein kan horen. Een sender rewriting scheme, of SRS, past die SMTP-envelop aan. Ook in 2026 is dat op zichzelf geen volledige oplossing: weten waar de grenzen liggen is net zo belangrijk als weten hoe het werkt.
Deze gids bespreekt wat SRS doet, waar het kan misgaan en welke onderdelen een doorstuurinrichting nodig heeft. Onderzoek je bredere bezorgproblemen, zoals verkeerde MX-records, fout ingestelde catch-all of DNS-wijzigingen die de routering verstoren, lees dan eerst de gids voor het instellen en herstellen van e-maildoorsturing.
Waarom SPF bij doorsturen kan mislukken
SPF kan mislukken wanneer de doorstuurserver vanaf zijn eigen IP verzendt, de oorspronkelijke envelopafzender behoudt en diens domein dat IP niet toestaat. Bij DMARC p=reject zonder geldige, uitgelijnde DKIM kan de ontvanger weigeren. Een SMTP-weigering kan een foutmelding aan de oorspronkelijke afzender opleveren, terwijl je eigen inbox mogelijk geen melding toont.
E-mail volgt geen enkele doorlopende verbinding. Het is een keten van SMTP-verbindingen, met een nieuwe TCP-verbinding bij elke stap. Dit is een mogelijk foutscenario:
alice@client.comschrijft naarcontact@your-agency.com- Je server accepteert het bericht: in dit voorbeeld is het verzend-IP van Alice toegestaan door SPF voor
client.com - Je server opent een nieuwe SMTP-verbinding naar Gmail om door te sturen
- Gmail ziet een verbinding vanaf jouw IP
- De envelopafzender is nog steeds
alice@client.com - Gmail controleert SPF voor
client.com: jouw IP is niet toegestaan - SPF mislukt. Gebruikt
client.comp=rejecten ontbreekt geldige, uitgelijnde DKIM, dan kan Gmail weigeren
RFC 7208, de SPF-specificatie, erkent de problemen bij doorsturen. Je kunt niet zomaar aannemen dat het oorspronkelijke domein de tussenserver toestaat. De envelop herschrijven is een manier om SPF op de nieuwe route te ondersteunen.
Twee afzenderidentiteiten: envelop en header
E-mail heeft twee afzenderidentiteiten. De envelopafzender (RFC 5321, MAIL FROM, P1) dient voor SPF en de routering van niet-bezorgingsmeldingen. Servers gebruiken hem, maar gebruikers kunnen hem ook via Return-Path in de volledige headers bekijken. De Header From (RFC 5322, P2) is wat Gmail of Outlook als afzender toont. Bij doorsturen kan de SPF-autorisatie van de envelopafzender niet passen bij de nieuwe verzendserver. SRS verandert dat onderdeel, niet het zichtbare From:-adres.
| Laag | Technische naam | RFC | Doel | Zichtbaar voor |
|---|---|---|---|---|
| Envelopafzender | MAIL FROM / Return-Path | RFC 5321 (P1) | SPF en routering van niet-bezorgingsmeldingen | Servers; ook te bekijken in volledige headers |
| Header From | From: header | RFC 5322 (P2) | Afzenderweergave in e-mailclients | Eindgebruikers |
Bij doorsturen kan de zichtbare From blijven staan op alice@client.com. Je server maakt een nieuwe SMTP-transactie en SPF beoordeelt de envelopafzender tegenover het IP van die stap. Het probleem is een mogelijk ontbrekende IP-autorisatie, niet alleen het bestaan van twee verschillende identiteiten.
Wat SRS daadwerkelijk doet
SRS herschrijft de envelopafzender (P1) voordat de doorstuurserver een nieuwe SMTP-verbinding opent. De zichtbare From blijft ongewijzigd. Met een envelopdomein dat de doorstuurserver toestaat, kan SPF bij de bestemming slagen zonder de weergegeven afzender te veranderen. Dit garandeert geen DMARC-uitlijning op het oorspronkelijke domein.
De postvergelijking: zonder SRS ontvang je de brief van Alice, stop je hem in een nieuwe postzak en laat je haar retouradres staan. De bezorger en retouridentiteit verschillen: een vergelijking met het SPF-probleem, geen bewijs van vervalsing. Met SRS gebruik je jouw retouradres. Komt de zak terug, dan ontvang jij hem en kun je de retourzending naar Alice doorzetten.
| Onderdeel | Vóór doorsturen | Na SRS-herschrijving (voorbeeld) |
|---|---|---|
| Header From (P2) | alice@client.com | alice@client.com (ongewijzigd) |
| Envelopafzender (P1) | alice@client.com | SRS0=4fac=PM=client.com=alice@your-agency.com |
| Verzend-IP | Jouw server | Jouw server |
| SPF-resultaat in het voorbeeld | FAIL | PASS |
Een SRS-adres ontleden
SRS zet de envelopafzender vóór het doorsturen om in een gecodeerde tekenreeks. Het herschreven domein moet de werkelijke route toestaan. De reeks bevat een authenticatiecode voor retourmeldingen, een tijdsaanduiding die de geldigheid beperkt en het oorspronkelijke adres voor retourroutering. Het zijn gestructureerde gegevens, geen willekeurige tekens. De bescherming hangt af van de implementatie.
Een voorbeeld van een SRS-adres:
SRS0=4fac=PM=client.com=alice@your-agency.com- SRS0: eerste stap.
SRS1wordt bij verder doorsturen gebruikt en beperkt adresgroei, maar garandeert geen onbeperkte keten - 4fac: staat in het voorbeeld voor een HMAC-SHA1-code. Algoritme en lengte verschillen per implementatie. De controle helpt retourmeldingen met ongeldige codes te weigeren en backscattermisbruik te beperken
- PM: tijdsaanduiding. Een venster van 7-21 dagen is een instelbaar voorbeeld, geen universele regel. De vervaldatum beperkt het gebruik van oude adressen, maar sluit niet iedere replayaanval uit
- client.com=alice: gecodeerde oorspronkelijke afzender, gebruikt om niet-bezorgingsmeldingen terug te routeren
Wanneer je SRS nodig kunt hebben
SRS is relevant als je tussen domeinen doorstuurt, de oorspronkelijke envelopafzender behoudt en diens SPF de tussenserver niet toestaat. Een multidomeinopzet hoort dit en de hele authenticatieroute te controleren, in plaats van te verwachten dat doorsturen altijd met het beleid van alle afzenders blijft werken.
Eigen domein naar persoonlijke Gmail. Je bezit cool-startup.com en stuurt door naar founder@gmail.com. Controleer de SRS-herschrijving en SPF-autorisatie van de server. Zonder herschrijving kan SPF mislukken, ook bij afzenders met streng DMARC-beleid. Geldige, uitgelijnde DKIM kan DMARC alsnog laten slagen.
MSP of bureau met een gedeeld mailcluster. Je host 200 klantdomeinen. Klanten sturen door naar hun diensten, zoals Comcast, AT&T of Outlook. Doorgestuurde spam kan de IP-reputatie schaden. Een Spamhaus-vermelding binnen enkele weken is een mogelijk risico, geen onvermijdelijk gevolg. SRS alleen lost spam en reputatieproblemen niet op.
Microsoft 365 met een uitgaande connector. Het SRS-gedrag in M365 hangt af van de route en het ondersteunde connectortype. Controleer of SenderRewritingEnabled beschikbaar is in jouw versie en inrichting en wijzig instellingen alleen met de juiste toestemming. Controleer ook het uitgaande spambeleid: 5.7.520 bij extern doorsturen duidt op een beleidsbeperking, niet noodzakelijk op een SRS-fout.
Waarom SRS alleen niet genoeg is
SRS kan SPF voor het herschreven domein laten slagen, maar herstelt niet automatisch de DMARC-uitlijning op de oorspronkelijke From. DMARC vereist dat minstens SPF of DKIM slaagt en op dat domein is uitgelijnd. Gebruikt SRS een ander domein, dan kan SPF slagen zonder uitlijning. DMARC kan dan afhankelijk zijn van geldige, uitgelijnde DKIM die bij het doorsturen intact blijft.
Sommige wijzigingen bij doorsturen kunnen DKIM ongeldig maken:
[EXTERNAL]aan het onderwerp toevoegen kan DKIM ongeldig maken als dat veld ondertekend is- Voettekst toevoegen, zoals een virusmelding of afmeldlink, kan de ondertekende inhoud veranderen en DKIM ongeldig maken
- MIME herschrijven, bijvoorbeeld van 8-bit naar 7-bit codering, kan DKIM ongeldig maken afhankelijk van de ondertekende delen en canonicalisatie
In dit scenario is SPF niet uitgelijnd en DKIM ongeldig, waardoor DMARC mislukt. De verdere verwerking, waaronder een mogelijke weigering, hangt af van het beleid van de ontvanger.
ARC (Authenticated Received Chain, RFC 8617) kan extra informatie leveren. De server verzegelt waargenomen resultaten voordat hij doorstuurt. Er worden drie headers toegevoegd:
ARC-Authentication-Results: registreert de waargenomen SPF-, DKIM- en DMARC-resultaten, die niet allemaal geslaagd hoeven te zijnARC-Message-Signature: ondertekent berichtdelen in hun staat op het moment van ondertekening, niet noodzakelijk hun oorspronkelijke staat bij ontvangstARC-Seal: cryptografische handtekening die de verzegelaar met de keten verbindt
Gmail kan ARC meewegen wanneer SPF en DKIM DMARC niet laten slagen. Vertrouwt het de verzegelaar en de keten, dan kan die informatie de beslissing beïnvloeden. Je kunt dat vertrouwen niet afdwingen en evenmin garanderen door langdurig reputatie op te bouwen. De ontvanger beslist.
Controleren of SRS werkt
Stuur vanuit een extern account een testbericht naar je doorgestuurde adres en bekijk de volledige headers bij de bestemming. Return-Path toont of die bezorging een SRS-adres of de oorspronkelijke afzender bevat. Controleer daarnaast de werkelijke authenticatieresultaten.
Stap 1: Return-Path bij de bestemming bekijken
# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>
# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>Stap 2: DNS van je SRS-domein controleren
# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf
# Check MX - bounces need a place to go:
dig MX your-domain.comHet herschreven domein moet de verzending via SPF toestaan en een werkende retourroute bieden. Een passend MX-record is doorgaans nuttig, maar zonder MX is een domein niet altijd onbereikbaar: SMTP kan in sommige gevallen impliciet A of AAAA gebruiken. Controleer de daadwerkelijke bereikbaarheid en serverreacties, niet alleen de aanwezigheid van het record.
Stap 3: de maillog op Linux bekijken
grep "srs_forward" /var/log/mail.loghash mismatch of timestamp expired kan ontstaan door niet-gesynchroniseerde geheimen, sleutelrotatie, gewone vertraging, beschadigde gegevens of misbruikpogingen. Het bewijst op zichzelf geen aanval. Postfix heeft een geïntegreerde SRS-oplossing nodig, bijvoorbeeld PostSRSd. De inrichting verschilt per versie en configuratie. Beoordeel waar van toepassing SRS_EXCLUDE_DOMAINS voor lokale domeinen en test de routering. Ontbrekende uitsluiting veroorzaakt niet onvermijdelijk lussen.
Het eenvoudigere alternatief: niet meer doorsturen
SRS beheert de envelopafzender wanneer de verzendserver verandert. Een echte mailbox op je domein met IMAP-toegang kan de extra doorstuurstap en bijbehorende SPF-problemen vermijden. Dat garandeert geen end-to-endauthenticatie en neemt niet elk DKIM-, DMARC- of toegangsprobleem weg. Een correcte inrichting blijft nodig.
Doorsturen is ook populair omdat een gebruikerslicentie voor een mailbox met vijf berichten per maand duur kan lijken. SRS ondersteunt soms een keuze die naast techniek vooral door kosten is ingegeven.
Het beschreven TrekMail-model biedt abonnementen vanaf $3.50 per maand, meerdere domeinen en gedeelde opslag tegen een vaste prijs, zonder gebruikerskosten binnen de geldende limieten. Je kunt sales@yourdomain.com als echte IMAP-mailbox gebruiken en verbinden met Outlook of een ondersteunde Gmail-integratie. Daarmee vermijd je die specifieke doorstuurinrichting, niet alle authenticatierisico's. Controleer actuele prijzen, functies en compatibiliteit.
Voor meerdere klanten bespreekt de gids over multidomein-e-mailhosting hoe je tientallen domeinen organiseert en het beheer beperkt. Bij een hybride inrichting met mailboxen en oude doorstuurregels behandelt de gids over e-mail doorsturen via aliassen SRS in de doorstuurroute.
Of je doorstuurt of naar mailboxen overstapt: begrijp de rol van SRS, controleer de werking en beoordeel ARC als het ondersteund wordt. Een deels ingerichte doorstuurketen kan legitieme berichten laten ontbreken. Dat is een bedrijfsrisico, niet alleen een technische bijzonderheid.
Begin met een gratis TrekMail-account: volgens de beschreven aanbieding is geen creditcard nodig en heeft de proefperiode geen einddatum. Controleer de huidige voorwaarden en verken multidomeinmail zonder de doorstuurcomplexiteit.
