E-mail naar een ander adres doorsturen: diagnose en controle

Je stelt een doorstuurregel in. Je verstuurt een test. Het werkt. Je gaat verder.

Dan zegt een klant dat je antwoord nooit is aangekomen. Geen bounce, geen NDR. Ergens tussen de servers is het bericht niet afgeleverd, zonder dat je een melding zag.

Dit kan er gebeuren wanneer je e-mail doorstuurt naar een ander adres: je server opent een nieuwe SMTP-verbinding met de bestemming. Die controleert SPF voor jouw IP, niet dat van de oorspronkelijke afzender. Als dat IP niet is toegestaan voor het envelopdomein, kan SPF mislukken. Als ook een uitgelijnde DKIM-handtekening ontbreekt of ongeldig wordt door wijzigingen onderweg, mislukt DMARC. Bij p=reject kan de ontvanger het bericht weigeren of anders verwerken volgens zijn beleid. Een bounce is niet gegarandeerd, maar stil verwijderen evenmin.

Dit hoeft geen typefout in de configuratie te zijn. Het is een spanning tussen doorsturen en moderne authenticatie. De complete gids voor het instellen en herstellen van e-maildoorsturing behandelt de verschillende scenario's. Dit artikel richt zich op authenticatie: foutpatronen, foutcodes en passende oplossingen.

Waarom authenticatie kan mislukken bij doorsturen naar een ander adres

Bij doorsturen controleert de ontvangende MTA SPF met het IP van de doorstuurserver. E-mail heeft afzonderlijke identiteitslagen die daardoor niet meer op elkaar kunnen aansluiten. SPF controleert de envelopidentiteit; DMARC vereist een geslaagde SPF- of DKIM-controle waarvan het domein is uitgelijnd met het zichtbare afzenderdomein. De afhandeling bij mislukking hangt af van het beleid.

De keten: server A stuurt naar je doorstuurserver B, die een nieuwe TCP-verbinding met bestemming C opent. C ziet het IP van B. SPF vraagt de DNS van het envelopdomein: "Mag dit IP voor jouw domein verzenden?" Als B niet is toegestaan en de oorspronkelijke envelopafzender behouden blijft, kan SPF mislukken. Dat gebeurt niet noodzakelijk bij iedere doorsturing.

Voor DMARC volstaat een geslaagde, uitgelijnde SPF- of DKIM-controle. Een geldige DKIM-handtekening van het oorspronkelijke, uitgelijnde domein kan een doorgestuurd bericht dus laten slagen. Wijzigingen in de ondertekende inhoud of headers kunnen DKIM breken, afhankelijk van canonicalisatie en de handtekening. Als geen uitgelijnde controle slaagt, mislukt DMARC. p=reject vraagt om weigering, zonder de feitelijke afhandeling te garanderen.

Drie foutpatronen om rekening mee te houden

Bij het doorsturen van e-mail kun je verschillende problemen tegenkomen. Deze drie patronen hebben verschillende oorzaken en oplossingen. Niet elk probleem levert dezelfde foutcode op; het herkennen van het patroon helpt bij gericht onderzoek.

1. Uitgaande blokkade in Microsoft 365 (550 5.7.520)

Microsoft 365 kan automatisch extern doorsturen standaard blokkeren als bescherming tegen gegevenslekken. Wanneer je een mailboxregel naar een adres buiten de tenant instelt, kan Exchange Online het bericht tegenhouden voordat het de infrastructuur verlaat. Controleer het effectieve beleid voor de betrokken gebruiker.

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

Dit is een beleidsblokkade, geen protocolfout. Een bevoegde beheerder kan het volgende controleren:

1. Open de Microsoft 365 Defender Portal.
2. Ga naar Email & collaboration → Policies & rules → Threat policies → Anti-spam.
3. Bewerk de Outbound spam filter policy die alleen de goedgekeurde gebruikers of groepen omvat.
4. Zet Automatic forwarding voor die beperkte beleidsomvang op On - Forwarding is enabled, als dit is toegestaan.

Wereldwijd inschakelen vergroot de risico's bij accountovername. Beperk de toestemming tot goedgekeurde accounts, gebruik MFA en bewaak uitgaand verkeer na de wijziging. Controleer ook andere regels die doorsturen kunnen blokkeren.

2. Geen geslaagde uitgelijnde controle voor DMARC

Dit kan moeilijk zichtbaar zijn. SPF kan bij doorsturen mislukken doordat het verzendende IP verandert. Een geldige, uitgelijnde DKIM-handtekening kan DMARC nog laten slagen. Wijzigingen die de canonicalisatie niet opvangt in het ondertekende berichtdeel of ondertekende headers kunnen die handtekening ongeldig maken.

Veelvoorkomende wijzigingen die DKIM kunnen breken:

• Antivirussoftware die een voettekst toevoegt: "Gescand door [Productnaam]"
• Onderwerptags van de bestemmingsgateway: [EXT] of [EXTERNAL], als Subject ondertekend is
• Waarschuwingen voor een "externe afzender" die aan de HTML-inhoud worden toegevoegd
• Mailinglijstsoftware die ondertekende headers herschrijft of afmeldvoetteksten toevoegt

Als noch SPF noch DKIM een geslaagd, uitgelijnd resultaat oplevert, geeft DMARC (RFC 7489) FAIL. Bij p=reject wordt weigering gevraagd, maar de ontvanger bepaalt de afhandeling. Een SMTP-weigering kan een NDR opleveren; andere verwerking kan zonder zichtbare melding blijven. Onderzoek daarom logs en authenticatieresultaten.

3. Routeringslussen (554 5.4.14)

Lussen ontstaan wanneer servers een bericht blijven terugsturen totdat een limiet wordt bereikt. Ze kunnen NDR's opleveren, maar niet noodzakelijk onmiddellijk. Ook kunnen ze wachtrijen belasten en andere afleveringen vertragen.

Veelvoorkomende oorzaken:

• Gebruiker A stuurt door naar B, en B heeft een regel die terugstuurt naar A.
• A stuurt door naar B, die een afwezigheidsmelding verstuurt. Afhankelijk van regels en lusbeveiliging kan die melding opnieuw worden doorgestuurd; correcte automatische antwoorden voorkomen zulke herhaling doorgaans.
• Een catch-all stuurt door naar een mailbox die weer doorstuurt naar een niet-bestaand adres binnen hetzelfde domein.

554 5.4.14 Hop count exceeded - possible mail loop

Controleer altijd de volledige route, inclusief automatische antwoorden en catch-all-bestemmingen, voordat je in productie e-mail naar een ander adres doorstuurt.

De hulpmiddelen: SRS en ARC

SRS en ARC kunnen authenticatieproblemen bij doorsturen beperken, maar garanderen geen aflevering. SRS herschrijft de envelopafzender zodat SPF voor jouw domein kan slagen met de juiste DNS en verzendende IP's. ARC legt eerdere authenticatieresultaten vast, die ontvangers naar eigen inzicht kunnen vertrouwen bij een DMARC-mislukking. Beide vereisen ondersteuning op serverniveau, niet alleen een clientregel.

SRS: Sender Rewriting Scheme

SRS herschrijft de envelopafzender (P1) naar een domein dat je beheert. In plaats van alice@bank.com als envelopafzender te behouden terwijl je server mogelijk niet voor dat domein mag verzenden, kan de doorstuurserver Return-Path herschrijven naar:

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

SPF controleert nu jouw domein. Als het verzendende IP door het SPF-record is toegestaan en de controle verder slaagt, kan SPF PASS opleveren. Dat betekent nog geen uitlijning met het oorspronkelijke zichtbare From:-domein.

De hash en tijdstempel ondersteunen veilige terugroutering van bounces. Als er een NDR naar het SRS-adres komt, kan je server het valideren, decoderen en naar Alice routeren. Deze adressen zijn beperkt in tijd en doel. Geheimbeheer en validatie zijn belangrijk, maar vervangen geen relaybeperkingen of andere misbruikbescherming.

ARC: Authenticated Received Chain

SRS kan SPF laten slagen, maar herstelt niet automatisch de uitlijning tussen envelop en zichtbare afzender. ARC (RFC 8617) herstelt die uitlijning evenmin. De doorstuurserver voegt ondertekende informatie toe over de authenticatiestatus die hij bij ontvangst vaststelde.

Google en Microsoft kunnen geldige ARC-ketens van vertrouwde tussenpartijen gebruiken bij hun afleverbeslissing. Een geldige keten en goede reputatie garanderen geen aflevering in Gmail of Outlook. De ontvanger bepaalt welke ARC-afzenders worden vertrouwd en hoe een DMARC-mislukking wordt behandeld.

Zie ARC als een bewijs van de verwerkingsketen. Een deelnemende tussenserver voegt een ondertekende verklaring toe over de waargenomen authenticatie. Ontvangers kunnen de keten controleren en besluiten die te vertrouwen wanneer de gebruikelijke DMARC-controle niet slaagt.

Gmail en Microsoft 365 kunnen ARC toepassen in ondersteunde doorstuurroutes; controleer de headers van jouw route. Zonder ARC ontbreekt dat bewijs, maar DMARC kan nog steeds slagen dankzij geldige, uitgelijnde oorspronkelijke DKIM. Ontbrekende ARC betekent niet automatisch een DMARC-mislukking.

Implementatie: twee routes

Je kunt de authenticatie van doorgestuurde e-mail op je eigen MTA beheren of een beheerde dienst gebruiken die de benodigde mechanismen voor jouw route ondersteunt. Beide vereisen controle van de werkelijke configuratie en testresultaten; geen van beide sluit afleverproblemen uit.

Optie A: Postfix + postsrsd (eigen beheer)

Op een Linux-server met Postfix kan postsrsd de envelop herschrijven. Het onderstaande voorbeeld gebruikt de verouderde TCP-tabellen. Nieuwere hoofdversies gebruiken socketmap-tabellen, die hiermee niet compatibel zijn. Controleer de documentatie van jouw geïnstalleerde versie voordat je iets toepast:

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Waar je bij deze aanpak verantwoordelijk voor bent:

• Beheer van SRS-geheimen. Gelekte sleutels kunnen vervalste SRS-adressen en misbruik van bounceroutes mogelijk maken; relaybeperkingen blijven noodzakelijk.
• Passende uitzonderingen voor lokale domeinen en niet-doorgestuurde mail, zodat herschrijven interne routes niet verstoort.
• Bewaking van IP-reputatie, die samen met authenticatie, inhoud en ontvangerbeleid de aflevering beïnvloedt.
• Aparte configuratie voor ARC-ondertekening; postsrsd levert die niet op zichzelf.

Dit kan goed werken, maar vraagt doorlopend onderhoud. Een gespecialiseerde dienst kan een deel daarvan overnemen, afhankelijk van de aangeboden route en functies.

Optie B: TrekMail (beheerd doorsturen)

Controleer bij TrekMail of jouw gekozen route automatische SRS-herschrijving, ARC-ondertekening en beheerde SMTP-relays ondersteunt. Beschikbaarheid kan per abonnement en configuratie verschillen. Beheerde infrastructuur kan onderhoud verminderen, maar biedt geen garantie op aflevering of een bepaalde reputatie.

Voor zelfstandige oprichters: als je $6 per maand per mailbox betaalt om alleen info@yourdomain.com naar je persoonlijke inbox door te sturen, vergelijk dan ook oplossingen met een vast tarief. De hier genoemde Starter-prijs van $3.50 per maand voor maximaal 50 domeinen zonder kosten per gebruiker is een referentie, geen actuele toezegging. Controleer prijs, doorstuurrechten en limieten. Lees hoe mailboxdoorsturing in TrekMail werkt.

Voor bureaus die DNS voor meerdere klanten beheren: onderzoek naar defecte SPF-routes kan veel tijd kosten. Een centraal dashboard kan het beheer vereenvoudigen als de benodigde functies beschikbaar zijn. De gids voor doorsturen via e-mailaliassen bespreekt de afweging tussen aliassen en volledige mailboxregels.

Checklist voordat je e-mail naar een ander adres doorstuurt

Controleer deze vier punten voordat je een regel in productie activeert. Ze helpen de besproken problemen te beperken, maar vervangen geen tests, logbewaking en controle van het ontvangerbeleid.

1. SRS werkt waar het nodig is. Controleer Return-Path op een afgeleverd testbericht. Bij een route met SRS hoort het herschreven adres bij jouw doorstuurdomein. Controleer ook het daadwerkelijke SPF-resultaat.
2. Behoud ondertekende inhoud. Voorkom voetteksten, onderwerptags en HTML-waarschuwingen die DKIM kunnen breken. Schakel beveiligingsscans niet uit: behoud gelijkwaardige bescherming zonder het ondertekende bericht te wijzigen. Niet iedere wijziging breekt DKIM; canonicalisatie en ondertekende velden bepalen dat.
3. Lusbeveiliging. Controleer op terugstuurregels, catch-all-routes en automatische antwoorden. Test of luspreventie werkt, in plaats van aan te nemen dat iedere afwezigheidsmelding een lus veroorzaakt.
4. Uitgaand beleid van M365. Controleer in Exchange Online het effectieve beleid. Sta "Automatic Forwarding" alleen toe voor goedgekeurde gebruikers of groepen via een passend begrensd beleid in het Defender-portaal; controleer aanvullende blokkades.

Wanneer doorsturen naar een ander adres niet nodig is

Soms past een andere oplossing beter. Wil je mail van meerdere domeinen lokaal in dezelfde inbox ontvangen, dan kan een domeinalias een extra doorstuurhop vermijden. Externe doorsturing via een alias blijft echter dezelfde authenticatievragen oproepen; controleer de feitelijke route.

De vergelijking tussen domeinalias en mailbox helpt bij die keuze. Als je van provider wisselt, kan de IMAP-migratietool van TrekMail, indien beschikbaar voor je account, bestaande mail rechtstreeks overzetten. Dat vervangt niet automatisch de routering van nieuwe berichten tijdens de overgang.

Samenvatting

Bij doorsturen ziet de SPF-controle het IP van de doorstuurserver. Als het oorspronkelijke envelopdomein dat IP niet toestaat, kan SPF mislukken. Geldige, uitgelijnde oorspronkelijke DKIM kan DMARC nog laten slagen. Anders kan DMARC mislukken; weigering, bounce of andere verwerking hangt af van de ontvanger en de route.

De hulpmiddelen werken op serverniveau: SRS herschrijft de envelopafzender en kan SPF voor jouw domein laten slagen; ARC levert ondertekend bewijs dat ontvangers naar eigen inzicht kunnen gebruiken. Geen van beide garandeert uitlijning of aflevering. Implementeer ze zelf of controleer de ondersteuning bij een beheerde dienst.

Wil je minder SRS-sleutelbeheer, ARC-configuratie en reputatiebeheer, controleer dan welke functies TrekMail voor jouw route biedt. De genoemde Starter-prijs van $3.50 per maand voor maximaal 50 domeinen, vast tarief zonder kosten per gebruiker, moet je aan de actuele voorwaarden toetsen. Bekijk alle abonnementen.