Elke website verstuurt e-mail. Orderbevestigingen, verzoeken om een wachtwoord opnieuw in te stellen, berichten uit contactformulieren en boekingsherinneringen vallen allemaal onder transactionele website-e-mail. Niemand plant dit onderdeel zorgvuldig, maar iedereen is ervan afhankelijk. Meestal stelt de bouwer van de website het één keer in en kijkt er daarna nooit meer naar.
Totdat klanten geen orderbevestigingen meer ontvangen en blijkt dat die al acht maanden in de spam belanden. In dit artikel lees je waarom dat op elk platform kan gebeuren en met welke inrichting je het voorkomt.
Waarom transactionele website-e-mail ongemerkt uitvalt
Met de standaardconfiguratie van de meeste platforms wordt e-mail rechtstreeks vanaf de webserver verzonden via de mailfunctie van de programmeertaal. Tijdens het testen lijkt dat prima te werken, omdat je in je eigen postvak kijkt en je eigen provider jouw berichten vertrouwt.
In productie gaat het mis om een reden die niets met je code te maken heeft. De webserver heeft geen verzendreputatie, deelt zijn IP-adres met alle andere diensten van de hostingprovider en verstuurt een bericht namens jouw domein vanaf een locatie die nooit door dat domein is gemachtigd. Ontvangende providers herkennen precies dit patroon als vervalsing, omdat het dat meestal ook is. Daarom schrijven de richtlijnen van Google voor afzenders authenticatie voor.
Aan jouw kant blijft de fout onzichtbaar. De website meldt dat de e-mail is verzonden, in de logboeken staat geen fout en niets wijst erop dat het bericht bij de ontvanger als spam is opgeslagen. Transactionele website-e-mail laat bijzonder slecht merken dat er iets misgaat. Daarom wordt het probleem vaak pas maanden later ontdekt wanneer een klant klaagt.
Op elk platform hetzelfde probleem
Dit is niet specifiek een WordPress-probleem, al krijgt WordPress vaak de schuld omdat het het meest gebruikte platform is. Het onderliggende mechanisme is overal hetzelfde.
WordPress gebruikt standaard de mailfunctie van PHP. Berichten worden dus rechtstreeks vanaf de server verstuurd, met alle bovengenoemde nadelen. Een SMTP-plug-in vervangt deze verzendmethode en is de gebruikelijke oplossing.
Shopify, Wix en Squarespace versturen hun eigen transactionele e-mails via een infrastructuur die doorgaans goed wordt onderhouden. Zonder aanvullende instellingen bieden ze echter niet altijd de mogelijkheid om met correcte authenticatie vanaf je eigen domein te verzenden. Daardoor beweert een bericht wel van jouw bedrijf te komen, maar kan de herkomst niet worden geverifieerd.
Webflow, Ghost en maatwerkapplicaties verschillen onderling, maar hetzelfde patroon blijft zichtbaar: de standaard verzendmethode is zelden voor jouw domein geauthenticeerd.
De oplossing is op al deze platforms gelijk: leid de transactionele website-e-mail via een geauthenticeerde SMTP-verbinding en gebruik een domein waarvan de DNS-records deze verbinding toestemming geven om berichten te verzenden.
De oplossing bestaat uit drie onderdelen
Alle drie de onderdelen zijn nodig. Met slechts twee ervan kunnen berichten nog steeds in de spam belanden.
Een SMTP-account om via te verzenden. De website verstuurt het bericht niet rechtstreeks vanaf de webserver, maar meldt zich aan bij een mailserver en draagt het bericht daaraan over. Elk platform ondersteunt dit, ingebouwd of via een plug-in.
DNS-records die het verzenden toestaan. Je hebt een SPF-record nodig dat de verzendende server vermeldt en een DKIM-handtekening waarmee het bericht kan worden geverifieerd. Zonder deze twee onderdelen lijkt zelfs geauthenticeerde e-mail voor de ontvanger niet gemachtigd. In onze handleidingen voor SPF en DKIM lees je hoe je deze records instelt.
Een afzenderadres dat echt bestaat. E-mail versturen vanaf noreply@jouwdomein.nl terwijl dat postvak niet bestaat, is een klein maar reëel negatief signaal. Bovendien verdwijnen alle antwoorden. Het aanmaken van het postvak kost hier niets extra, omdat we geen prijs per gebruiker rekenen.
Scheid deze e-mail van je gewone correspondentie
Vanaf een bepaald volume is het verstandig om transactionele website-e-mail via een eigen verzendroute te laten lopen.
Geautomatiseerde e-mail en door mensen geschreven berichten gedragen zich anders en worden ook anders beoordeeld. Een plotselinge stroom van vijfhonderd verzoeken om het wachtwoord opnieuw in te stellen na een beveiligingsincident lijkt in niets op de correspondentie van een persoon. Als beide soorten berichten via dezelfde route vertrekken, bepaalt de reputatie van het geautomatiseerde verkeer ook de reputatie van de e-mail van je team.
Met afzonderlijke SMTP-profielen per domein is deze scheiding eenvoudig: stuur het domein van je applicatie via de ene route en het domein waarmee je medewerkers schrijven via een andere. Een probleem aan de ene kant blijft dan ook daar. De werkwijze staat in onze handleiding voor aangepaste SMTP per domein.
Sommige bedrijven gebruiken zelfs een afzonderlijk subdomein voor alle geautomatiseerde e-mail. Daarmee wordt de reputatie volledig geïsoleerd, al ziet het afzenderadres er iets minder fraai uit. Of die afweging zinvol is, hangt af van het volume.
Wanneer een transactionele e-mailprovider de juiste keuze is
We moeten duidelijk zijn over de grens: bij echt grote volumes bestaan gespecialiseerde transactionele diensten om goede redenen.
Verstuur je tienduizenden berichten per dag, dan heb je bezorggebeurtenissen per bericht, webhookmeldingen bij bounces, sjabloonbeheer en gedetailleerde analyses nodig. Dat is precies waar deze diensten voor zijn gemaakt, en geen gewone e-mailhoster biedt deze functies op hetzelfde niveau.
Onze dagelijkse limieten zijn afgestemd op correspondentie en niet op campagnes: 1.000 berichten per postvak per dag bij Starter en maximaal 2.500 bij Agency. De transactionele e-mail van een kleine webwinkel of een boekingssysteem past daar gemakkelijk binnen. Voor een platform met veel verkeer geldt dat niet. De juiste architectuur is dan een transactionele provider die via een aangepast SMTP-profiel is gekoppeld. Zo blijven je e-mailhosting en bulkverzending gescheiden zonder dat je voor je postvakken twee e-mailproviders nodig hebt.
Controleren of het echt werkt
Omdat problemen in deze categorie ongemerkt optreden, is controleren veel waardevoller dan aannemen dat alles werkt.
Laat een echt bericht versturen: plaats een testbestelling of vraag om een nieuw wachtwoord. Stuur het naar adressen bij twee verschillende grote providers. Open de berichtkoppen en controleer of SPF en DKIM zijn geslaagd en of DMARC de uitlijning bevestigt. Als alle drie de controles slagen, is de configuratie daadwerkelijk afgerond.
Herhaal deze controle elk kwartaal en direct nadat iemand de DNS-instellingen of de hosting heeft gewijzigd. Transactionele website-e-mail gaat meestal niet stuk tijdens de eerste configuratie, maar wanneer later iets in de omgeving verandert. Na het verplaatsen van nameservers denkt vrijwel niemand eraan om de orderbevestigingen opnieuw te testen.
Komen de berichten aan maar belanden ze in de spam, dan wijzen de bezorgstatistieken van het domein en eventuele DMARC-rapporten meestal veel sneller op de oorzaak dan willekeurige aanpassingen aan de inhoud.
