Doorsturen met SRS: praktische configuratie en grenzen

E-mail doorsturen lijkt eenvoudig: stel een bestemming in en klaar. Toch kan SPF mislukken zonder doorsturen met SRS (Sender Rewriting Scheme). Stel dat bank.com mail stuurt naar een doorgestuurd adres op je server. Je server verstuurt die verder met de oorspronkelijke envelopafzender, maar vanaf zijn eigen IP. Als bank.com dat IP-adres niet toestaat, mislukt SPF. Met DMARC p=reject en zonder geldige, afgestemde DKIM kan de ontvanger weigeren. Een SMTP-afwijzing kan een bezorgfout opleveren; het bericht verdwijnt niet noodzakelijk zonder melding.

Deze gids behandelt de praktische inrichting van SRS. De complete gids voor e-mail doorsturen en bezorgproblemen geeft het bredere overzicht. Hier richten we ons op architectuur, adresopbouw, integratie met Postfix en de aanvullende rol van ARC. ARC kan eerdere authenticatieresultaten doorgeven, maar garandeert geen succesvolle DMARC-controle.

Wat doorsturen met SRS doet

SRS herschrijft de envelopafzender wanneer je server een bericht doorstuurt. Het oorspronkelijke domein wordt vervangen door een domein dat je beheert. Als het SPF-record van dat domein het IP-adres van de verzendende server toestaat, kan SPF bij de bestemming slagen. De zichtbare From-header wordt door deze herschrijving niet aangepast.

Zonder SRS kan behoud van de oorspronkelijke envelopafzender een SPF-fout veroorzaken. SRS pakt dat specifieke probleem aan, maar behoudt niet automatisch alle authenticatie of de afstemming met de oorspronkelijke From. Of SRS nodig is, hangt van de route en de daadwerkelijke SPF-autorisatie af.

De twee lagen van de afzenderidentiteit

Voor een juiste SRS-configuratie moet je twee adresvelden onderscheiden. SPF controleert het domein van de envelopafzender. Dat adres kan bij doorsturen gelijk blijven terwijl het IP-adres van de verbinding verandert.

• Envelopafzender (RFC 5321 MAIL FROM): Het retouradres dat mailservers gebruiken voor bezorgfouten. SPF controleert of het IP-adres van de verbinding namens dit domein mag verzenden.
• From-header (RFC 5322 From): Het adres dat het e-mailprogramma toont. DMARC controleert de afstemming met een via SPF of DKIM geauthenticeerd domein. SRS laat dit veld bewust ongewijzigd.

Dit voorbeeld veronderstelt dat de nieuwe server niet voor het oorspronkelijke domein is geautoriseerd, maar wel voor het SRS-domein:

SRS zet een domein dat je beheert in de envelopafzender. Het SPF-record moet de server toestaan, waarna die controle kan slagen. Dat garandeert nog geen aflevering. Het herschreven adres staat meestal niet in de gewone berichtweergave, maar is via Return-Path in de ruwe headers te bekijken.

SRS-adresopbouw: wat de onderdelen betekenen

Een SRS-adres oogt ingewikkeld, maar elk onderdeel heeft een functie. De opbouw helpt bij onderzoek naar bezorgfouten en routes met meerdere doorstuurstappen.

Een eerste SRS-herschrijving (SRS0) ziet er zo uit:

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

De onderdelen:

• Hash: Een ingekorte HMAC, in veel van de beschreven implementaties met SHA1, berekend met een lokale geheime sleutel. Helpt vervalste SRS-retouradressen te weren. Zonder validatie kunnen ogenschijnlijk geldige SRS0-adressen misbruik van foutmeldingen mogelijk maken; HMAC neemt niet alle risico's weg.
• Timestamp: Tijdinformatie in base32, in dit voorbeeld geldig gedurende 7-21 dagen. Formaat en geldigheid hangen van implementatie en configuratie af. Verlopen adressen weigeren beperkt sommige vormen van hergebruik, maar voorkomt niet iedere replay-aanval.
• Origin: Gegevens waarmee de oorspronkelijke afzender bij een bezorgfout kan worden hersteld. Je server ontvangt de foutmelding, voert de omgekeerde omzetting uit en stuurt de melding terug.
• AnchorDomain: Het domein dat je beheert. SPF moet de server toestaan en er moet een bereikbare retourroute zijn. MX-records zijn gebruikelijk; zonder MX kan waar toepasselijk de impliciete A- of AAAA-terugval gelden.

Bij nog een doorstuurstap wordt SRS0 in daarvoor geschikte implementaties SRS1:

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

SRS1 beperkt de adresgroei, maar controleer nog steeds de limiet van 64 tekens voor het lokale adresdeel uit RFC 5321. Bij fouten in routes met meerdere stappen is de adreslengte een nuttige controle, niet de enige mogelijke oorzaak.

Postfix-integratie: PostSRSd instellen

PostSRSd is een mogelijke SRS-integratie voor Linux en Postfix. Postfix vraagt via canonical maps om herschreven adressen. De onderstaande voorbeelden zijn richtinggevend: controleer documentatie, syntaxis, paden en toegangsrechten voor je geïnstalleerde versie voordat je wijzigingen aanbrengt.

Stap 1: het ankerdomein voorbereiden

Bereid eerst het domein voor dat in de herschreven envelopafzender komt te staan. Controleer:

• MX-records: Bezorgfouten moeten via een geldige route aankomen. Controleer MX of, waar toepasselijk volgens RFC 5321, de impliciete A/AAAA-terugval. Zonder bereikbare retourroute kunnen foutmeldingen verloren gaan.
• SPF-record: De bestemming vergelijkt het IP-adres van de verbinding met SPF voor dit domein. SRS autoriseert het IP-adres niet zelf: stel de toestemming in en controleer de werkelijke uitkomst.
• Reputatie: Spam doorsturen kan de reputatie van server en ankerdomein schaden. Opname in een blokkeerlijst is niet onvermijdelijk, maar controle van het doorgestuurde verkeer blijft nodig.

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

Stap 2: PostSRSd configureren

Afhankelijk van pakket en versie kan de configuratie in /etc/default/postsrsd (Debian/Ubuntu) of /etc/postsrsd/postsrsd.conf staan. Dit voorbeeld is geen universele syntaxis. Controleer ook ondersteuning en werking van de uitsluitingslijst:

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

Maak alleen een nieuwe geheime sleutel aan als dat volgens je beheerplan nodig is. Let op: de uitvoeromleiding hieronder overschrijft een bestaand bestand. Bewaar de huidige sleutel eerst veilig en plan rotatie en validatie van foutmeldingen die nog onderweg zijn. Voer dit voorbeeld niet blind uit op een actief systeem.

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

Stap 3: integreren met Postfix

Controleer de instellingen in /etc/postfix/main.cf. Het voorbeeld onderscheidt PostSRSd 2.x met socketmaps en 1.x met TCP. Zie het als een conceptueel schema: verifieer de daadwerkelijke syntaxis, socketlocatie en toegangsrechten voor jouw installatie.

# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

Plan na validatie van de configuratie een herstart volgens je operationele procedures:

systemctl restart postsrsd
systemctl restart postfix

SRS is niet voldoende: de rol van ARC

SRS kan SPF laten slagen zonder de DMARC-domeinafstemming te herstellen. DMARC vereist dat het zichtbare From-domein volgens de afstemmingsregels overeenkomt met het via SPF geauthenticeerde domein of het ondertekenende domein van een geldige DKIM-handtekening. In dit voorbeeld authenticeert SPF na SRS relay.yourdomain.com, niet client.com. Zonder SPF-afstemming is geldige, afgestemde DKIM nodig om DMARC te laten slagen.

Doorsturen kan DKIM verstoren als ondertekende onderdelen veranderen op een manier die relevant is voor de canonicalisatie. Denk aan “External Sender” in Subject, een afmeldtekst in de berichtinhoud of gewijzigde MIME-grenzen. Niet iedere wijziging maakt de handtekening ongeldig. Als DKIM mislukt en SPF niet is afgestemd, kan DMARC mislukken en de ontvanger volgens zijn beleid weigeren.

ARC, Authenticated Received Chain, beschreven in RFC 8617, geeft werkelijk waargenomen authenticatieresultaten door via een ondertekende keten. Een ontvanger die de ondertekenaar vertrouwt, kan die informatie meewegen, ook bij een DMARC-fout. ARC herstelt geen domeinafstemming en dwingt geen aflevering af.

ARC voegt drie headers toe:

• ARC-Authentication-Results: de authenticatieresultaten die de server heeft waargenomen en vastgelegd
• ARC-Message-Signature: een handtekening van headers en berichtinhoud op het moment van ondertekening tijdens de verwerking
• ARC-Seal: de ondertekende verbinding tussen de onderdelen van de keten

SRS regelt de envelop; ARC geeft authenticatiecontext door. Bij strenge ontvangers zoals Google en Microsoft kunnen ze elkaar aanvullen, maar beide zijn niet altijd noodzakelijk of samen voldoende. SRS alleen herstelt DMARC niet wanneer ook afgestemde DKIM ontbreekt.

De gezaghebbende SPF-specificatie is RFC 7208.

Providerspecifieke problemen om vooraf te kennen

Ook met correct ingestelde SRS en ARC kunnen providers een route op grond van hun beleid blokkeren. Niet ieder probleem komt door authenticatie of een lokale configuratiefout. Controleer de actuele voorwaarden voordat je de route in productie gebruikt.

De fout M365 550 5.7.520 kost tijd wanneer je hem als SRS-probleem interpreteert. Als hij een blokkade op extern doorsturen aangeeft, gaat het om het beleid van de tenant waaruit de mail vertrekt, niet noodzakelijk de bestemming. Een bevoegde beheerder van de bron-tenant moet de rechten in Defender beoordelen. Omzeil beveiligingsbeleid niet.

Controleren of SRS werkt

Test de route voor productiegebruik en bekijk de ruwe headers. Een SRS-adres in Return-Path toont dat ergens in de route is herschreven, maar controleer ook authenticatie en de retourroute voor fouten. Een oorspronkelijk adres kan door uitsluitingen, een omweg of verkeerde integratie komen; het bewijst niet dat PostSRSd is gestopt.

1. Controleer Return-Path

Stuur vanuit een extern account, bijvoorbeeld ProtonMail, een test naar het doorgestuurde adres. Open bij de bestemming de berichtbron en zoek Return-Path:

• Return-Path: <SRS0=...@yourdomain.com> → SRS-herschrijving is aanwezig; controleer ook SPF en de omgekeerde omzetting
• Return-Path: <alice@protonmail.com> → geen zichtbare herschrijving op deze route; controleer uitsluitingen, integratie en mogelijke omwegen

2. Controleer DNS van het ankerdomein

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. Controleer Postfix-logs

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

Zoek naar aanvragen aan de SRS-dienst en antwoorden met herschreven adressen. Een geweigerde verbinding kan komen door een gestopte dienst, socketinstellingen, configuratie of netwerkfilters. De servicestatus is een van de controles: systemctl status postsrsd.

4. Test verbinding en TLS

SRS-, netwerk- en TLS-problemen kunnen vergelijkbare symptomen geven. Controleer SMTP-bereikbaarheid en TLS-onderhandeling afzonderlijk:

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

Een timeout kan door het netwerk, een geblokkeerde poort of een onbereikbare server komen. Een mislukte onderhandeling kan op een afzonderlijk TLS-probleem wijzen. Een timeout alleen identificeert de oorzaak niet.

Wanneer rechtstreeks hosten beter past

SRS, ARC, het ankerdomein, sleutels, uitsluitingen en reputatie brengen beheerwerk mee. Soms kiezen organisaties voor doorsturen om kosten per mailbox bij andere providers te vermijden: je stuurt sales@ naar je persoonlijke inbox in plaats van, in dit voorbeeld, $6 per maand per gebruiker te betalen. Besparing op één adres kan bij tien adressen omslaan in extra beheerkosten.

De gids over de afwegingen bij aliasdoorsturing bespreekt waar doorsturen zinvol is en waar de complexiteit zich opstapelt. De keuzegids voor aliassen en mailboxen helpt bij de onderliggende adresstructuur.

Het beschreven Pro-abonnement ($10 per maand) biedt 100 domeinen en 50GB gedeelde opslag. Controleer de actuele prijzen en limieten. Je kunt sales@, support@ en info@ als IMAP-mailboxen hosten, zonder kosten per gebruiker volgens het beschreven model en zonder die externe doorstuurroute te onderhouden. Het opslagquotum is niet exclusief voor iedere mailbox; behoud van berichten hangt ook van beleid en beheer af.

Als doorsturen nodig is, bijvoorbeeld om meerdere domeinen op één bestemming samen te brengen, omvat het beschreven Pro- en Agency-aanbod beheerde SRS-herschrijving en OpenARC-ondertekening. Controleer de huidige beschikbaarheid voordat je een bestemming instelt; dit garandeert geen aflevering. Nano met eigen SMTP geeft niet automatisch recht op beheerd doorsturen. Een eventuele SRS-implementatie op je eigen uitgaande infrastructuur vereist compatibiliteit en een gecontroleerde configuratie, zoals de besproken PostSRSd-voorbeelden.

De gids voor domeinmail doorsturen naar Gmail behandelt de specifieke problemen en verificatiestappen voor die route.

In het kort

Doorsturen met SRS herschrijft de envelopafzender zodat SPF een domein kan controleren dat de server toestaat. Zonder herschrijven kan SPF mislukken, maar niet noodzakelijk bij ieder bericht. PostSRSd is een mogelijke Postfix-integratie: bereid een domein met geldige retourroute, SPF, een geheim, ondersteunde uitsluitingen en canonical maps in main.cf voor en verifieer de versie. Overweeg ARC voor aanvullende context als DKIM onderweg ongeldig wordt; het herstelt geen afstemming en garandeert niet dat DMARC slaagt of dat het bericht wordt afgeleverd.

Controleer de ruwe headers na iedere wijziging. Als het beheerwerk de vermeden licentiekosten overtreft, overweeg dan rechtstreeks gehoste mailboxen. Bekijk de TrekMail-abonnementen: het beschreven Nano-aanbod vraagt geen creditcard, maar activering en functies hangen van de actuele voorwaarden af. Pro kan beheerde SRS en ARC op ondersteunde routes bieden om een deel van het technische werk over te nemen.