E-mail doorsturen via een alias: SPF, DMARC en fouten

Je hebt e-mail doorsturen via een alias ingesteld: contact@yourdomain.com verwijst naar je Gmail. Maandenlang werkt het. Dan mailt een klant over een ondertekend contract, maar je ziet het bericht niet. Drie weken later hoor je ervan, wanneer de deal al is misgelopen.

Geen melding ontvangen, niets in de spammap. Alleen een ontbrekende e-mail en een gemiste kans.

Dit is een mogelijk probleem wanneer aliassen en doorsturen op een streng DMARC-beleid stuiten. De ontvanger merkt de fout soms niet op. Begrip van de protocollen helpt om de oorzaak te vinden en het risico te beperken. Deze handleiding bespreekt de zwakke punten, foutcodes in de logboeken en twee mechanismen die de authenticatie van doorgestuurde mail kunnen verbeteren, zonder bezorging te garanderen.

Begin voor de basis met de handleiding voor het instellen en herstellen van e-maildoorsturing. Dit artikel gaat over mogelijke fouten.

Wat doorsturen via een e-mailalias daadwerkelijk doet

Een alias is een routeringslabel zonder eigen inbox, login of opslagquotum. Als iemand naar sales@yourdomain.com mailt, ontvangt je server het bericht en routeert het naar een andere bestemming, vaak een persoonlijk Gmail- of Outlook-account. Dit is een veelgebruikte oplossing voor functieadressen bij kleine bedrijven, maar kan moeilijk zichtbare bezorgproblemen veroorzaken.

Extern doorsturen via een alias opent een nieuwe SMTP-verbinding naar de bestemming. Daar ontstaat het authenticatieprobleem: je server verzendt een bericht dat elders is ontstaan en waarvan de authenticatie naar de oorspronkelijke afzender verwijst.

De twee lagen van een e-mail

Elke e-mail heeft twee afzonderlijke lagen die vaak worden vergeten. Ze verklaren waarom doorsturen de authenticatie kan verstoren.

Als client@bank.com naar je alias sales@yourdomain.com mailt, verstuurt de server van bank.com het bericht. In dit voorbeeld slaagt SPF omdat bank.com zijn eigen verzendende IP-adres toestaat.

Wanneer je server dit bericht naar founder@gmail.com doorstuurt, opent hij een nieuwe SMTP-verbinding. Het verbindende IP-adres is nu van jouw server, terwijl de envelopafzender ongewijzigd kan blijven. In de berichtkop staat nog steeds client@bank.com.

Gmail controleert SPF voor bank.com en ziet het IP-adres van jouw server, dat niet door dat domein is toegestaan. SPF kan mislukken. Als bank.com p=reject publiceert en ook geen afgestemde DKIM-controle slaagt, kan Gmail het bericht volgens zijn beleid weigeren. Een eventuele foutmelding kan naar de oorspronkelijke afzender gaan, niet naar jou; weigeren betekent niet automatisch stilzwijgend verwijderen.

Drie mogelijke fouten bij doorsturen via aliassen

Doorsturen kan op verschillende lagen misgaan. Elke fout heeft eigen symptomen en vraagt om een passende aanpak.

1. SPF mislukt

SPF controleert of het IP-adres van de verbinding is toegestaan door de DNS-records van het domein van MAIL FROM of HELO. Bij de nieuwe SMTP-stap komt de verbinding van jouw IP-adres in plaats van dat van de oorspronkelijke afzender. Als de envelopafzender behouden blijft en jouw IP niet is toegestaan, kan SPF bij de bestemming mislukken.

2. DMARC-weigering

DMARC vereist dat SPF of DKIM slaagt en afgestemd is op het From:-domein. Als SPF mislukt, kan een geldige afgestemde DKIM-handtekening DMARC nog laten slagen. Wijzigingen aan ondertekende onderdelen, zoals toegevoegde voetteksten of herschreven berichtkoppen, kunnen DKIM echter ongeldig maken. Als geen afgestemde controle slaagt, vraagt p=quarantine om quarantaine en p=reject om weigering. De ontvangende server bepaalt hoe hij dat beleid toepast.

3. Verlies zonder melding aan de ontvanger

Het slechtste scenario is dat de bestemming een bericht weggooit zonder NDR, een rapport van niet-bezorging. Dat is geen verplicht gevolg van DMARC: een SMTP-weigering kan wel een melding aan de afzender opleveren. De aliasontvanger ziet mogelijk niets, waardoor het probleem lang onopgemerkt kan blijven.

Foutcodes om in je SMTP-logboeken te zoeken

Ontbreekt doorgestuurde mail, controleer dan je SMTP-logboeken of vraag je provider om NDR-gegevens. Deze drie codes kunnen doorstuurproblemen helpen opsporen, maar moeten in hun context worden onderzocht.

Microsoft 365-blokkade (5.7.520)

Exchange Online kan automatisch extern doorsturen via tenantbeleid blokkeren. Die bescherming tegen gegevensdiefstal kan ook legitieme doorsturing tegenhouden. Controleer de daadwerkelijke configuratie en actuele richtlijnen.

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

Aanpak: een bevoegde beheerder kan na beoordeling van de risico's een uitzondering in het uitgaande antispambeleid van de Microsoft 365-portal overwegen. Gebruik een omleidingsregel niet als vermeende gegarandeerde omweg: controleer welke regels het tenantbeleid toestaat.

Routeringslus (5.4.14 / 5.4.6)

Een lus kan ontstaan als twee aliassen naar elkaar doorsturen, of als een catch-all naar een adres gaat dat berichten terug naar je domein stuurt.

554 5.4.14 Hop count exceeded - possible mail loop

Aanpak: controleer je transportregels. Let bijvoorbeeld op een catch-all voor *@yourdomain.com die naar een adres met onbeperkte automatische antwoorden stuurt. Een afwezigheidsbericht veroorzaakt niet vanzelf een lus, maar recursieve routes of ontbrekende beveiligingen kunnen dat wel doen.

DMARC-authenticatiefout (550 5.7.1)

In dit voorbeeld heeft de bestemmingsserver het doorgestuurde bericht geweigerd vanwege een DMARC-authenticatieprobleem.

550-5.7.1 Unauthenticated email from bank.com is not accepted due to domain's DMARC policy.

Dit is een voorbeeld van een DMARC-fout die bij doorsturen kan voorkomen. Onderzoek de SPF- en DKIM-resultaten. SRS en ARC op serverniveau kunnen helpen, maar garanderen niets en vervangen geen correcte DNS-configuratie.

De maatregelen: SRS en ARC

Je kunt de bestemming niet dwingen een uitzondering op haar beleid te maken. SRS en ARC zijn aanvullende mechanismen voor extern doorsturen op het niveau van de MTA, de mailtransportserver. Beheer je die server niet zelf, vraag dan je provider welke mechanismen worden ondersteund en hoe ze worden toegepast.

SRS (Sender Rewriting Scheme)

SRS herschrijft de SMTP-envelopafzender, die in Return-Path wordt vastgelegd, naar het domein van de doorsturende server. SPF kan bij de bestemming slagen als de DNS-records van dat domein de server correct toestaan en aan de overige controles wordt voldaan.

Zonder SRS:
Envelopafzender: client@bank.com
Verzendend IP-adres: jouw doorstuurserver
SPF-resultaat: FAIL in dit voorbeeld; jouw IP staat niet in het record van bank.com

Met SRS:
Envelopafzender: SRS0=Hash=TT=bank.com=client@yourdomain.com
Verzendend IP-adres: jouw doorstuurserver
SPF-resultaat: PASS in dit voorbeeld; jouw IP is toegestaan voor yourdomain.com

SRS neemt ook een hash en tijdsaanduiding op in het herschreven adres om de geldigheid te controleren en misbruik te beperken. De vervaltermijn hangt af van de implementatie. Dit maakt het adres niet immuun voor adresverzameling of elk hergebruik.

ARC (Authenticated Received Chain)

SRS kan SPF bij de bestemming herstellen, maar herstelt op zichzelf niet de DMARC-domeinafstemming van SPF. DMARC vergelijkt het From:-domein (bank.com) met de geauthenticeerde domeinen. Met SRS staat in de envelop yourdomain.com, terwijl From: bank.com blijft. Die domeinen komen niet overeen. Geldige afgestemde DKIM kan DMARC nog wel laten slagen.

ARC, beschreven in RFC 8617, voegt een ondertekende keten van eerder waargenomen authenticatieresultaten toe. Je server verzegelt het doorgestuurde bericht en de vastgelegde resultaten. Hij verklaart niet automatisch dat zowel SPF als DKIM geldig waren, maar documenteert de controles die daadwerkelijk zijn uitgevoerd.

Ontvangende systemen, waaronder Gmail en Outlook in ondersteunde configuraties, kunnen ARC en de reputatie van de doorstuurserver meewegen. Een geldig zegel verplicht de ontvanger niet tot vertrouwen of bezorging. ARC verandert de DMARC-domeinafstemming niet.

Geen van beide is een eenvoudige DNS-instelling. SRS-herschrijving en ARC-verzegeling vereisen ondersteuning in de transportlaag. Correcte DNS, intacte DKIM en het beleid van de ontvanger blijven belangrijk bij extern doorsturen onder streng DMARC-beleid.

Twee operationele valkuilen

Ook met SRS en ARC kunnen twee veelgebruikte configuraties problemen veroorzaken.

Je persoonlijke adres wordt zichtbaar bij antwoorden

Doorsturen regelt ontvangst, niet automatisch de verzendidentiteit. Als je in Gmail antwoordt zonder een andere afzender in te stellen, kan From founder@gmail.com tonen in plaats van sales@yourdomain.com. De klant ziet dan je persoonlijke adres.

Mogelijke oplossing: stel in Gmail «Mail verzenden als» in bij de accountinstellingen volgens de actuele interface. Geef je aliasadres en toegestane SMTP-inloggegevens voor je domein op. Bij ondersteunde verzendroutes gebruikt Gmail die server; controleer het zichtbare antwoordadres. Raadpleeg voor de verbinding de instellingen voor beheerde SMTP van TrekMail.

Dit kan werken, maar de bronprocedure voegt drie configuratiestappen per account toe. Bij een nieuw SMTP-wachtwoord moet je mogelijk ook Gmail bijwerken.

De valkuil van extern doorsturen met catch-all

Vermijd extern doorsturen van een catch-all (*@yourdomain.com). Spammers proberen vaak willekeurige lokale adresdelen op bekende domeinen, zoals billing@, admin@ en noreply12345@. Een catch-all kan die berichten ontvangen en spam die door de filters komt doorsturen.

Grote hoeveelheden doorgestuurde spam kunnen de reputatie van je server-IP schaden. Ook legitieme mail, inclusief mail van echte mailboxen, kan in spam belanden. Reputatieherstel kan tijd kosten, maar dit gevolg is niet automatisch en kent geen vaste termijn.

Gebruik zo nodig liever een afzonderlijke lokale catch-all-inbox en controleer die handmatig. De documentatie over mailboxdoorsturing in TrekMail helpt je de configuratie te beoordelen zonder onnodig spamverkeer door te sturen.

Doorsturen via een alias of een echte mailbox?

De handleiding voor domeinaliassen en mailboxen biedt het volledige afwegingskader. Dit is de samenvatting voor doorsturen:

Vermijd doorsturen via een alias als permanente vervanging van een echte mailbox uitsluitend om kosten te besparen. Bij prijzen per gebruiker kan dat aantrekkelijk lijken, maar extra configuratie, uitzonderingen en authenticatierisico's horen ook in de afweging.

Hoe TrekMail doorsturen afhandelt

SRS en ARC zelf beheren vraagt om transportconfiguratie, integratie met Postfix, beheer van ARC-sleutels en sleutelrotatie. De details hangen af van je systeem. Dit is serverbeheer, geen eenvoudige wijziging van een alias.

De bron beschrijft mailboxdoorsturing op TrekMail Pro en Agency via een transportlaag met OpenARC. ARC-zegels worden volgens die beschrijving automatisch op doorgestuurde mail toegepast; de bestemming stel je in via het dashboard. Controleer actuele ondersteuning, limieten en gedrag in de documentatie. Deze beschrijving bewijst op zichzelf geen SRS-ondersteuning en garandeert geen bezorging. De DNS-authenticatie van je domein moet nog steeds correct zijn ingesteld.

Vaak is een afzonderlijke mailbox zonder doorsturen eenvoudiger. Het vasteprijsmodel uit de TrekMail-bron rekent geen extra bedrag per gebruiker of mailbox. Een mailbox support@yourdomain.com verandert niet alleen van prijs omdat er één persoon inlogt in plaats van tien, binnen de limieten en met ondersteunde toegangsvormen. Controleer de actuele voorwaarden en beveiligingseisen voordat je kiest.

• Mkb: geef support@ een eigen IMAP-login en configureer SMTP voor verzenden. Directe toegang vereenvoudigt afzenderscheiding en beperkt de noodzaak om externe instellingen voor «Verzenden als» bij te werken.
• Bureaus: maak afzonderlijke mailboxen voor functieadressen van klanten in plaats van door te sturen naar persoonlijke teamaccounts. Met toegestane toegang en correct ingestelde clients kan het team vanaf het juiste zakelijke adres antwoorden.

Stel je ook SPF, DKIM en DMARC voor je domeinen in, dan behandelt de basis voor veilige zakelijke e-mail de belangrijkste onderdelen van de authenticatie.

Conclusie

E-mail doorsturen via een alias kan geschikt zijn voor weinig kritische toepassingen. Let vooral op deze risico's:

1. De oorspronkelijke afzender gebruikt streng DMARC (p=quarantine of p=reject) en geen afgestemde controle blijft geldig
2. De doorstuurserver gebruikt geen SRS, waardoor oorspronkelijke SPF bij de bestemming kan mislukken
3. De doorstuurserver gebruikt geen ARC, zodat eerdere resultaten ontbreken voor beoordeling; SRS alleen stemt SPF niet af op DMARC, terwijl afgestemde DKIM kan volstaan
4. Je stuurt een catch-all extern door en kunt spam versterken
5. Je moet vanaf de alias antwoorden: doorsturen stelt die verzendidentiteit niet automatisch in

Kies passende protocolondersteuning bij je provider, waaronder SRS en ARC waar nodig, of vervang de doorstuurfunctie door een echte mailbox met directe login. Doorsturen kan aantrekkelijk lijken bij kosten per gebruiker. Het beschreven vasteprijsmodel van TrekMail voegt binnen de limieten geen mailboxlicentie toe.

De bron noemt TrekMail Pro vanaf $10/maand, met maximaal 100 domeinen, mailboxdoorsturing met ARC-zegels en geen kosten per mailbox binnen de limieten. De bron noemt ook een gratis proefperiode van 14 dagen waarvoor een creditcard nodig is, anders dan bij Nano. Controleer actuele prijzen en voorwaarden.