E-mail doorsturen met SRS: SPF, DMARC en beperkingen

Je stelt doorsturen in: contact@yourdomain.com stuurt mail naar Gmail. Een week gaat het goed, daarna komen sommige klantberichten niet aan en vind je niet meteen een foutmelding terug. De logs tonen 550 5.7.1 Unauthenticated email of 550 5.7.26 This message does not have authentication information. Die antwoorden kunnen meerdere oorzaken hebben; doorsturen met SRS pakt een mogelijke oorzaak aan. Je server opent een nieuwe SMTP-verbinding, terwijl de envelopafzender nog het oorspronkelijke domein gebruikt. Als SPF je nieuwe IP niet autoriseert, kan de controle mislukken. Bij DMARC p=reject kan de ontvanger het bericht weigeren als geldige, uitgelijnde SPF én DKIM ontbreken, afhankelijk van zijn beleid. Een SMTP-weigering kan een niet-bezorgingsmelding opleveren; mail verdwijnt niet altijd stilzwijgend.

SRS inschakelen lost niet alles op. DMARC-uitlijning kan ook bij correcte herschrijving mislukken. Voor de verschillende oorzaken en diagnose lees je de handleiding voor doorstuurinstellingen en probleemoplossing.

Wat is e-mail doorsturen met SRS?

Doorsturen met SRS, Sender Rewriting Scheme, herschrijft de envelopafzender wanneer een mailserver een bericht verder stuurt. Het domein van de doorstuurdienst vervangt het oorspronkelijke domein in het technische retouradres, zodat SPF voor dat domein kan worden gecontroleerd. Slagen hangt af van DNS en IP-autorisatie. De zichtbare From blijft hetzelfde. SRS versleutelt niets en verbergt geen headers: envelopgegevens kunnen in de volledige berichtheaders staan.

Postfix kan SRS integreren via de daemon postsrsd. Microsoft 365 en sommige beheerde maildiensten ondersteunen het op bepaalde routes, waaronder hybride configuraties. Controleer versie, connectors en instellingen. SRS helpt bij de verhouding tussen SMTP-doorsturen en SPF, maar lost niet alle DMARC-eisen op.

Waarom doorsturen kan mislukken: een nieuwe SMTP-hop

Doorsturen voegt een SMTP-hop toe. SPF kan daardoor mislukken wanneer het nieuwe IP niet is toegestaan. E-mail heeft twee verschillende identiteiten. Header From (RFC 5322) is wat gebruikers zien, zoals From: alice@client.com. Envelope Sender (RFC 5321, MAIL FROM) is het technische retouradres voor SPF-controles en niet-bezorgingsmeldingen. Het staat meestal niet in de gewone weergave, maar kan in volledige headers worden gelezen.

Dit is een mogelijke foutvolgorde, niet het onvermijdelijke resultaat van ieder doorgestuurd bericht:

1. Alice verstuurt vanaf alice@client.com. SPF autoriseert haar server en slaagt bij ontvangst op jouw server.
2. Jouw server opent een nieuwe SMTP-verbinding naar you@gmail.com. De verbinding komt nu van jouw IP.
3. De envelopafzender blijft alice@client.com, maar in dit voorbeeld staat jouw server-IP niet in de SPF-autorisatie van client.com.
4. Gmail controleert SPF voor client.com en de controle mislukt omdat jouw IP niet is toegestaan.
5. Als client.com p=reject publiceert, geldige uitgelijnde DKIM ontbreekt en de ontvanger het weigeringsbeleid toepast, kan het bericht worden geweigerd. De doorstuurserver kan dat antwoord ontvangen en een niet-bezorgingsmelding sturen.

Hoe SRS het SPF-probleem kan oplossen

Doorsturen met SRS herschrijft vóór verzending de envelopafzender naar het domein van de doorstuurdienst. De bestemming controleert SPF vervolgens voor dat domein. SPF kan slagen als het actuele record het werkelijke verzend-IP toestaat. Header From verandert niet. Niet-bezorgingsmeldingen keren terug naar de doorstuurdienst, die het SRS-adres kan valideren en volgens de configuratie naar de oorspronkelijke afzender terugleiden.

De SRS-syntaxis uitgelegd

SRS verandert een eenvoudig retouradres in een gestructureerd adres met een authenticatiecode. Dit is herschrijving, geen versleuteling:

Vóór SRS: MAIL FROM: <alice@client.com>
Na SRS: MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>

Bij een tweede doorstuurstap (A → B → C) kan de dienst SRS1 gebruiken. Dit beperkt adresgroei zonder steeds de volledige SRS0-string opnieuw in te pakken. De details omvatten meer dan alleen hash en tijdstempel en verschillen per implementatie. Controleer nog steeds de grens van 64 tekens voor het lokale deel uit RFC 5321: SRS garandeert niet dat ieder adres daarbinnen past.

Waarom SRS niet genoeg is: het DMARC-probleem

Veel beheerders zetten doorsturen met SRS aan en denken klaar te zijn, maar berichten kunnen nog in spam belanden of worden geweigerd. SRS kan SPF herstellen zonder DMARC-uitlijning te behouden. DMARC vereist geldige SPF óf DKIM met een domein dat bij Header From is uitgelijnd. Na SRS kan SPF yourdomain.com authenticeren terwijl Header From client.com blijft. Die verschillende domeinen zijn in dit voorbeeld niet uitgelijnd. Bij uitlijning in de relaxed-modus kunnen andere situaties binnen hetzelfde organisatiedomein wel voldoen.

Als SPF niet is uitgelijnd, kan geldige uitgelijnde DKIM DMARC nog laten slagen. Veranderingen tijdens het doorsturen kunnen de handtekening aantasten, afhankelijk van de ondertekende onderdelen en canonicalisatie:

• [EXTERNAL] vóór het onderwerp zetten als dat onderdeel is ondertekend
• Antivirusvoetteksten of juridische disclaimers aan de ondertekende inhoud toevoegen
• 8-bit-codering omzetten naar 7-bit
• MIME-scheidingsgrenzen aanpassen

Deze wijzigingen verbreken niet iedere handtekening: ondertekende onderdelen en normalisatie bepalen het resultaat. Als noch geldige uitgelijnde SPF noch geldige uitgelijnde DKIM overblijft, mislukt DMARC. De bestemming kan dan volgens haar beleid filteren of weigeren, ook wanneer SRS correct werkte.

De rol van ARC (Authenticated Received Chain)

ARC (RFC 8617) laat de doorstuurdienst de daadwerkelijk waargenomen authenticatieresultaten vastleggen. Het moment van controle en verzegeling hangt af van de verwerkingsroute. ARC voegt drie headers toe:

• ARC-Authentication-Results: legt de waargenomen SPF-, DKIM- en DMARC-resultaten vast, inclusief fouten
• ARC-Message-Signature: ondertekent headers en inhoud zoals die bij verzegeling aanwezig zijn
• ARC-Seal: verbindt de nieuwe ARC-set cryptografisch met de bestaande keten

Als de keten geldig is en de ontvanger de verzegelende dienst vertrouwt, kan ARC meewegen in de beslissing om ondanks een DMARC-fout te accepteren. ARC verandert de uitlijning niet en garandeert geen aflevering. Gmail beoordeelt ARC-zegels in productie sinds 2019.

In 2026 kan een robuuste inrichting doorsturen met SRS, behoud van DKIM-ondertekende onderdelen en ARC combineren waar dat nuttig en ondersteund is. Niet alle drie zijn altijd noodzakelijk of voldoende: de oorspronkelijke authenticatie en het ontvangstbeleid blijven bepalend.

SRS configureren per platform

De procedures verschillen. Postfix kan een externe daemon gebruiken, Microsoft 365 kent eigen doorstuurbeleid en connectors, en Google Workspace gebruikt beheerde mechanismen met limieten en controles. Controleer de huidige instellingen; neem niet aan dat alles standaard uit of aan staat.

Postfix op zelfbeheerde Linux

Een mogelijke SRS-integratie voor Postfix gebruikt postsrsd. Het volgende is een voorbeeld voor geschikte distributies, te controleren vóór een geautoriseerde wijziging:

apt-get install postsrsd

Dit oudere voorbeeld stelt /etc/postfix/main.cf in met TCP-maps van postsrsd. Nieuwere versies kunnen andere sockets en syntaxis vereisen. Maak een back-up en voeg de instellingen zorgvuldig samen met bestaande maps; overschrijf ze niet blind:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Controleren: SRS_EXCLUDE_DOMAINS in /etc/default/postsrsd kan, waar de versie dit ondersteunt, lokale domeinen uitsluiten van herschrijving. Controleer paden, maps, socketrechten en uitsluitingen en test de routes. Een verkeerde uitsluiting kan eigen mail herschrijven of routeringsproblemen veroorzaken, maar leidt niet automatisch tot een lus.

Microsoft 365

M365 verwerkt SRS op bepaalde uitgaande routes. Controleer het actuele gedrag, zeker in hybride omgevingen of bij connectors naar een externe gateway. 550 5.7.520 Access denied, Your organization does not allow external forwarding wijst op doorstuurbeleid, niet op een bewezen SRS-storing.

Deze beperking vraagt om een beveiligingsbeoordeling. Een bevoegde beheerder kan Security Center → Policies & Rules → Anti-spam → Outbound spam filter policy bekijken en alleen goedgekeurde doorstuurstromen toestaan. Het volgende commando is een voorbeeld uit de beschreven configuratie. De parameter kan per versie verschillen of niet worden ondersteund. Verifieer de juiste procedure voor de tenant en versie; dit is geen universele instructie:

Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $true

Google Workspace

Google gebruikt beheerde doorstuurmechanismen. Mogelijke problemen, die niet uitsluitend bij Workspace voorkomen, zijn:

• Volumelimieten: een catch-all die spam doorstuurt kan quota verbruiken en beperkingen opleveren. Eventuele accountopschorting hangt af van beleid en omstandigheden.
• Lusdetectie: sommige berichten kunnen worden verworpen om lussen te stoppen. Zichtbaarheid hangt af van logs, beheertools en route; niet iedere gebeurtenis blijft zonder spoor.

Problemen met SRS-doorsturen onderzoeken

Volledige headers helpen bij diagnose. Stuur een test vanaf ProtonMail en bekijk het ontvangen bericht op de eindbestemming. Bij weigering zijn die headers mogelijk niet beschikbaar: gebruik ook SMTP-logs, tracegegevens en het volledige foutantwoord. Niet elke oorzaak blijkt uit headers alleen.

Controle 1: Return-Path

Voorbeeld zonder SRS-herschrijving: Return-Path: <original@protonmail.com>
Voorbeeld met SRS-herschrijving: Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>

Een oorspronkelijke Return-Path kan wijzen op een gestopte daemon of verkeerde integratie, maar ook op een uitsluiting of een route buiten SRS. Controleer de route en logs voordat je conclusies trekt.

Controle 2: Authentication-Results

Zoek spf=pass voor het herschrijvende domein. Bij dmarc=fail kan DKIM ontbreken, ongeldig zijn of wel geldig maar niet uitgelijnd zijn. Ook SPF kan niet bij de oorspronkelijke From passen. Controleer het ondertekenende domein en wijzigingen aan inhoud of onderwerp.

Controle 3: DNS

dig yourdomain.com TXT +short

Controleer of SPF het daadwerkelijke doorstuur-IP autoriseert en of het retouradres bereikbaar is. MX-records zijn belangrijk, maar ontbreken bewijst niet dat ontvangst onmogelijk is: SMTP kan een impliciete MX via A of AAAA gebruiken. Test routering en werkelijke antwoorden in plaats van alleen recordaanwezigheid.

Controle 4: Postfix-logs

grep "srs_forward" /var/log/mail.log

hash mismatch of timestamp expired kan ontstaan door verschillende sleutels tussen nodes, sleutelrotatie, klokinstellingen, verlopen geldigheid of configuratie. Hergebruik van oude adressen en replaypogingen zijn ook mogelijk, maar de meldingen bewijzen geen aanval. Onderzoek de context voordat je backscatter aan een specifieke oorzaak koppelt.

Wanneer je beter kunt stoppen met SRS-doorsturen

Doorsturen met SRS pakt een structureel probleem van een tussenliggende hop aan. SRS, DKIM-behoud en ARC kunnen extra componenten en controles vragen. Een schijnbare besparing op gebruikerslicenties kan kleiner worden als je beheertijd meerekent, maar de uitkomst hangt van je infrastructuur af.

Vergelijk de twee benaderingen:

TrekMail beschrijft een vast abonnement met gedeelde opslag voor mailboxen en domeinen, in plaats van een gebruikersprijs. Dat betekent niet dat je uitsluitend voor opslag betaalt of onbeperkte capaciteit krijgt. Voor bureaus: vergelijk dit met gebruikelijk doorsturen naar Gmail of lees de afwegingen bij doorsturen via aliassen. De vergelijking tussen domeinalias en mailbox helpt kiezen tussen aliassen en echte mailboxen.

Rechtstreekse ontvangst in TrekMail-mailboxen verwijdert voor die berichten de doorstuurhop. Voor die hop zijn SRS en ARC dan niet nodig. Uitgaande authenticatie moet nog steeds worden ingesteld en getest, ook met een wizard. Een server in de MX-records is niet automatisch een toegestane verzender: SPF, DKIM, DMARC en eventuele externe SMTP hangen af van route, aanbieder en abonnement.

Probeer TrekMail: het beschreven aanbod noemt Nano zonder betaalkaart of een proef van 14 dagen voor Starter vanaf $3.50/maand met beheerde SMTP. Controleer actuele beschikbaarheid, toelatingseisen, prijs en voorwaarden.

Samenvatting

Doorsturen met SRS is een nuttig hulpmiddel voor doorstuurarchitecturen in 2025-2026, geen universele verplichting. Zonder herschrijving kan SPF op de volgende hop mislukken. Met SRS en geldige SPF kan het geauthenticeerde domein nog steeds niet bij From passen. Geldige uitgelijnde DKIM kan DMARC wel laten slagen; weigering hangt af van ontvangstbeleid.

Een mogelijke Postfix-integratie gebruikt postsrsd, maps in main.cf en versieafhankelijke uitsluitingen. Controleer bij M365 de beheerde route en het doorstuurbeleid en wijzig dat alleen met toestemming. Onderzoek bij Google Workspace quota, lusdetectie en beheertools zonder opschorting of ontbrekende logs te veronderstellen.

SRS, behoud van DKIM-ondertekende onderdelen en ARC kunnen doorsturen beter beheersbaar maken. Niet alle drie zijn altijd nodig en ze garanderen geen aflevering. Overweeg anders een mailbox op de werkelijke bestemming en blijf authenticatie, toegang en limieten controleren.