“Er komen geen berichten meer binnen via het contactformulier.” Dat klinkt als een vrij duidelijke storing, maar technisch gezien zegt het nog verrassend weinig. Het formulier kan daadwerkelijk defect zijn, maar het kan ook probleemloos functioneren terwijl de e-mail ergens verderop in de keten verdwijnt. Drupal kan een inzending correct verwerken, de mailserver kan het bericht accepteren en tóch kan de ontvanger niets terugvinden.
Het zichtbare probleem bevindt zich dus aan het einde van een proces, terwijl de oorzaak een paar stappen eerder kan liggen. Daarom is bij dit soort storingen één vraag belangrijker dan alle andere: tot waar komt het bericht nog?
Eén contactformulier bestaat uit meerdere systemen
Voor de bezoeker is het proces overzichtelijk: naam invullen, e-mailadres achterlaten, bericht schrijven en verzenden. Achter die ene knop bevindt zich echter een keten van verschillende systemen: de browser, het formulier, Drupal, de mailvoorziening, de ontvangende mailserver en uiteindelijk de mailbox van de ontvanger.
Iedere overgang kan een storingspunt vormen. Een bevestiging op het scherm dat het formulier succesvol is verzonden, bewijst bijvoorbeeld alleen dat Drupal de inzending heeft geaccepteerd. Het zegt niet automatisch dat de e-mail daarna ook correct is verzonden of afgeleverd. Dat onderscheid voorkomt veel verkeerd zoekwerk. Wie ervan uitgaat dat het probleem “dus in het formulier” zit, kan allerlei instellingen aanpassen terwijl de werkelijke oorzaak bijvoorbeeld bij SMTP, DNS of de ontvangende mailserver ligt.
Een goede diagnose begint daarom niet met aanpassen, maar met het opdelen van de keten in controleerbare stappen.
Soms zit het probleem inderdaad in het formulier
De eenvoudigste situatie is nog altijd dat het formulier zelf niet goed functioneert. De verzendknop reageert niet, er verschijnt een foutmelding of een bepaalde combinatie van invoer leidt tot een fout. In Drupal kan zoiets ontstaan na een update van Drupal, een module of PHP, maar ook maatwerk of JavaScript kan de oorzaak zijn.
Bij uitgebreidere formulieren spelen meer factoren mee. Een verplicht veld kan bijvoorbeeld onbedoeld verborgen zijn, een CAPTCHA-oplossing kan geldige gebruikers tegenhouden of voorwaardelijke logica kan anders reageren dan bedoeld. Bij Webform, een veelgebruikte Drupal-module voor formulieren, kan achter één ogenschijnlijk eenvoudig formulier behoorlijk wat configuratie schuilgaan: validaties, conditionele velden, handlers en vervolgacties.
Daarom is een van de nuttigste controles niet alleen of de bezoeker een bevestiging krijgt, maar ook of de inzending daadwerkelijk in Drupal wordt opgeslagen. Staat de inzending daar gewoon tussen, dan weten we dat het formulier zijn belangrijkste werk heeft gedaan. Vanaf dat moment moet het onderzoek verderop in de keten worden voortgezet.
Drupal ontvangt de inzending, maar de e-mail gaat niet weg
Wanneer de inzending keurig in Drupal terechtkomt maar niemand een e-mail ontvangt, verschuift de aandacht naar de verwerking na het formulier. Staat het juiste ontvangstadres ingesteld? Is de e-mailhandler nog actief? Wordt een formulierwaarde als ontvanger gebruikt en bevat juist dat veld onverwachte gegevens? Is er recent iets gewijzigd aan de SMTP-configuratie of de manier waarop de website mail verstuurt?
Ook externe factoren spelen een rol. Een wachtwoord van een mailaccount kan zijn gewijzigd, een API-sleutel kan verlopen of een maildienst kan strengere authenticatie-eisen invoeren. In de Drupal-logs zijn daarbij vaak aanwijzingen te vinden, al verschijnt niet ieder probleem als een nette foutmelding met een directe oplossing.
Een belangrijk technisch onderscheid is dat een succesvolle mailactie binnen Drupal nog steeds niet bewijst dat het bericht de uiteindelijke mailbox heeft bereikt. Drupal kan de e-mail correct aan een mailserver aanbieden, waarna het vervolgtraject buiten Drupal plaatsvindt.
Opvallend vaak: het formulier is niet veranderd
Bij storingen aan contactformulieren horen we regelmatig: Maar hier is helemaal niets aan aangepast. Dat kan heel goed kloppen.
Een formulier staat niet op zichzelf. De website kan hetzelfde zijn gebleven, terwijl ondertussen PHP is bijgewerkt, de hosting is gewijzigd, een mailaccount andere inloggegevens heeft gekregen of DNS-instellingen zijn aangepast. Ook ontvangende mailservers veranderen hun controles.
Dat verklaart waarom een formulier soms van de ene op de andere dag problemen lijkt te geven. Niet omdat het formulier plotseling defect raakt, maar omdat één van de systemen eromheen anders is gaan reageren.
Juist bij een formulier dat jarenlang goed heeft gewerkt, is ‘er is niets veranderd’ dus geen reden om wijzigingen buiten Drupal uit te sluiten.
De website verstuurt de mail, maar hij komt niet aan
Vanaf dit punt ligt de oorzaak vaak buiten de website zelf. E-mailservers controleren steeds strenger of berichten betrouwbaar zijn. Instellingen zoals SPF, DKIM en DMARC helpen bepalen of een server daadwerkelijk namens een domein mag verzenden en of het bericht onderweg is gewijzigd.
Daardoor kan een formulier jarenlang probleemloos werken en vervolgens ineens problemen geven zonder dat iemand het formulier heeft aangepast. Een organisatie kan bijvoorbeeld zijn mailomgeving wijzigen, DNS-records aanpassen of overstappen naar Microsoft 365 of een andere provider. Ook ontvangende partijen kunnen hun controles aanscherpen.
Een ander bekend probleem is het afzenderadres. Het lijkt logisch om het door de bezoeker ingevulde e-mailadres als afzender te gebruiken, maar voor spamfilters kan dat juist verdacht zijn. De webserver verstuurt dan immers mail alsof hij namens een extern domein spreekt. Betrouwbaarder is meestal om een adres van het eigen domein als afzender te gebruiken en het bezoekersadres als antwoordadres in te stellen.
De snelste oplossing begint meestal met niets veranderen
Dat klinkt tegenstrijdig, maar direct instellingen aanpassen maakt een storing vaak lastiger te analyseren. Iedere wijziging verandert immers de situatie waarvan je nog probeert te begrijpen waarom die niet werkt.
Wij beginnen daarom liever met volgen: een testinzending doen, controleren of Drupal deze registreert, vaststellen of een mailactie plaatsvindt en daarna onderzoeken wat de verzendende mailserver met het bericht doet. Afhankelijk van de uitkomst bekijken we Drupal-logs, SMTP-logs, DNS-instellingen en de reactie van de ontvangende mailomgeving.
Soms ligt de oorzaak in Drupal, soms in hosting of DNS, en soms blijkt alleen mail naar één specifiek domein niet aan te komen. Dat laatste detail verandert de hele diagnose. Wie uitsluitend naar het formulier kijkt, kan dan lang zoeken op de verkeerde plek.
Een niet-functionerend contactformulier is daarom zelden één probleem. Het is een keten waarin je moet vaststellen welke schakel nog werkt en vanaf welk punt het misgaat. Pas daarna heeft aanpassen zin.