De vervelendste fouten zijn niet de fouten die luid crashen. Het zijn de fouten die glimlachen en zeggen dat alles in orde is, terwijl er niks werkt. Ik heb er een dure les aan overgehouden, en die deel ik hier, want de kans is groot dat jij ergens dezelfde valkuil hebt zonder het te weten.

De situatie: een van mijn systemen verstuurde automatisch e-mails. Bevestigingen, inloglinks, dat soort berichten. Alles leek perfect te werken. Het systeem meldde bij elke mail netjes “verzonden”. In de logs stond bij elke poging keurig een succesmelding. En toch bereikte een deel van die mails de ontvangers nooit. Negen dagen lang. Negen dagen waarin mijn eigen systeem volhield dat het z’n werk deed, terwijl er berichten spoorloos verdwenen. Geen foutmelding, geen enkel signaal. Gewoon: weg.

SMTP zegt “verzonden”, en dat betekent bijna niks#

Hier zit de kern van de valkuil, en die is belangrijk om te begrijpen, ook als je zelf nooit een regel code schrijft. Wanneer je software een mail verstuurt, geeft de mailserver aan de andere kant een bevestiging terug: “ontvangen, ik neem het over”. Jouw systeem ziet die bevestiging en concludeert: verzonden, klaar. In mijn logs stond dat als succes.

Maar die bevestiging betekent alleen dat de mail is aangenomen om verstuurd te worden. Niet dat hij is aangekomen. Wat er daarna gebeurt, valt volledig buiten het zicht van jouw systeem. En juist daar ging het bij mij mis.

Wat er onder water gebeurde#

Om te snappen waar mijn mail bleef, moet je één ding weten over hoe mail tegenwoordig tegen fraude wordt beschermd. Omdat het heel makkelijk is om te doen alsof je een mail van iemand anders stuurt, hebben domeinen een soort echtheidscontrole. Die controle heet DMARC, en die leunt op twee mechanismen met de namen SPF en DKIM. Simpel gezegd controleert de ontvangende kant: komt deze mail wel echt van een afzender die namens dit domein mág versturen? Zo niet, dan mag de ontvanger de mail in de spam gooien of zelfs helemaal weigeren.

En daar zat mijn probleem. Mijn domein ontving zijn inkomende post via de ene provider, noem het provider A. Maar mijn systeem verstuurde de uitgaande mail via een andere provider, provider B. Op zich niks geks, dat komt vaak voor. Alleen: het domein had officieel alleen provider A aangewezen als legitieme afzender. Toen provider B namens mijn domein een mail afleverde, deed de ontvangende kant zijn echtheidscontrole, zag een afzender die niet op de lijst stond, concludeerde “dit klopt niet” en gooide de mail weg. Stil. Zonder iemand iets te melden.

Het venijnige zat in het patroon. Externe ontvangers, denk aan een persoonlijk mailadres bij een van de grote providers, hanteren die controle vaak wat milder en lieten de mail nog wel door. Dus als ik zelf een test deed naar een privéadres, kwam de mail gewoon aan en dacht ik dat alles goed zat. Maar berichten van mijn domein naar mijn eigen domein, intern verkeer dus, werden onverbiddelijk weggegooid. Precies het verkeer dat ik het minst vaak controleerde, faalde het hardst. Vandaar die negen dagen.

Hoe je dit opspoort#

Als jouw automatisering mail verstuurt en je hebt ook maar de kleinste twijfel of alles wel aankomt, is dit de manier om er zeker van te zijn. Ik heb er een vaste checklist van gemaakt.

Ten eerste: geloof de succesmelding van je systeem niet. “Verzonden” in een log betekent aangenomen, niet afgeleverd. Behandel het als een belofte, niet als bewijs.

Ten tweede: kijk in de échte inbox van de ontvanger, en dan in álle mappen, ook spam en prullenbak. Als daar niets binnenkomt terwijl je systeem succes meldt, is je mail na de verzending weggevallen. Dat is het bewijs dat je zoekt.

Ten derde: controleer wat het domein officieel over zichzelf zegt. In de openbare instellingen van elk domein staat welke afzenders legitiem zijn, waar inkomende mail heen gaat, en wat er moet gebeuren als de echtheidscontrole faalt: niets doen, in de spam zetten, of weigeren. Wie deze drie dingen naast elkaar legt, ziet meestal meteen waar de mismatch zit.

Ten vierde: check of de provider waarlangs je verstuurt ook echt op die lijst van legitieme afzenders staat. Bij mij was dat de ontbrekende schakel: provider B verstuurde, maar stond nergens vermeld als toegestaan.

Hoe je het oplost#

Er zijn grofweg drie routes, in volgorde van mijn voorkeur.

De schoonste oplossing is: verstuur via dezelfde provider die ook je inkomende mail afhandelt. Dan klopt de echtheidscontrole vanzelf, want de afzender is precies de partij die het domein al kent. Dit is wat ik uiteindelijk heb gedaan.

Kan dat niet, dan kun je je provider-B alsnog toevoegen aan de lijst van legitieme afzenders van je domein en de bijbehorende digitale handtekening publiceren. Dat werkt, maar let op: er zit een technische limiet op hoeveel afzenders je zo kunt stapelen, dus dit wordt rommelig als je het te vaak doet.

De derde route is een gespecialiseerde maildienst inzetten die dit soort levering als kernproduct heeft. Prima voor grote volumes met behoefte aan analyses, maar overkill als je een handjevol mails per dag verstuurt.

De les die verder gaat dan mail#

De diepere les is niet eens mailspecifiek. De hele storing ontstond ná een beveiligingsaanpassing. Ik had iets aangescherpt, alles leek te werken, en de gevolgen doken pas negen dagen later boven water omdat mijn “is alles gezond”-controle alleen keek of de server aanstond, en niet of de mail daadwerkelijk aankwam.

Sindsdien geldt bij mij een harde regel: na elke beveiligingswijziging die iets raakt aan mail, beveiligde verbindingen of inloggen, doe ik binnen vijf minuten na het uitrollen één keer handmatig de echte flow. Zelf een mail versturen en zelf controleren of hij in de doel-inbox belandt. En mijn gezondheidscontroles testen tegenwoordig de échte functie: niet alleen of de server reageert, maar of de kernfunctie zelf nog leeft.

Wat betekent dit voor jouw bedrijf?#

Als er in jouw bedrijf ook maar iets automatisch mail verstuurt, en dat is bijna altijd zo, denk aan orderbevestigingen, wachtwoord-resets, afspraakherinneringen, dan loop je precies dit risico. En het venijnige is: je merkt het niet, want je systeem meldt succes. De klant die zijn bevestiging niet kreeg belt niet altijd; die haakt gewoon af.

Drie dingen om vandaag te doen:

  1. Test de echte aankomst, niet de verzendmelding. Stuur regelmatig een automatische mail naar een adres dat je zelf kunt controleren en kijk of hij ook echt binnenkomt, inclusief spammap.
  2. Wees extra alert na elke beveiligingswijziging. Juist het aanscherpen van beveiliging is berucht om het stilletjes breken van dingen die eromheen zitten. Doe na elke aanpassing één keer de echte flow.
  3. Zorg dat je monitoring de functie test, niet de server. “De server draait” is geen bewijs dat je mail aankomt, je betalingen doorkomen of je bestellingen binnenlopen. Laat je controles de kernfunctie zelf uitproberen.

Stille storingen zijn de duurste, juist omdat ze zich verstoppen achter groene lampjes. Wie leert om de echte uitkomst te controleren in plaats van de melding te geloven, vangt ze voordat een klant dat voor je doet.

Wil je in kaart brengen waar in jouw automatisering dit soort stille storingen op de loer liggen, en hoe je ze voorkomt? Bekijk mijn gratis downloads of neem via de consulting-pagina contact op om jouw situatie door te lichten.