Als het contactformulier “Bedankt” zegt, maar er geen mail aankomt

Stel u een kleine fysiotherapiepraktijk voor. De website heeft een contactformulier, en het formulier werkt – of lijkt in elk geval te werken. Bezoekers vullen het in, klikken op “Verzenden” en zien een vriendelijk “Bedankt, wij nemen snel contact met u op”. Wat niemand ziet: de berichten bereiken de inbox van de praktijk al een tijd niet meer. Er is geen foutmelding, geen bounce in iemands inbox, nergens een rood lampje. Het formulier faalt in stilte.

Waarom niemand het merkt

De “Bedankt”-pagina van een formulier betekent meestal maar één ding: de website heeft het bericht doorgegeven. Of een mailserver het accepteert, als spam markeert of onderweg weigert, gebeurt later, buiten het zicht van het formulier. De functie mail() van PHP meldt bijvoorbeeld succes zodra het lokale systeem het bericht voor bezorging accepteert – niet wanneer het iemand bereikt. Dus krijgt de bezoeker een bevestiging en gaat verder. De eigenaar ziet intussen een lege inbox en denkt dat het gewoon een rustige maand is. Minder aanvragen zijn op zichzelf zelden alarmerend: vakanties, het weer, de economie – er is altijd een verklaring die aannemelijker klinkt dan “het formulier is kapot”.

De gebruikelijke oorzaken

• Het SMTP-wachtwoord of de mailprovider is gewijzigd. Het formulier blijft inloggen met de oude gegevens en de mailserver weigert – stilletjes, voor zover de bezoeker kan zien.
• PHP mail() zonder authenticatie. De webserver verstuurt mail rechtstreeks, zonder bij een echte mailserver in te loggen. Veel ontvangende servers vinden zulke mail verdacht: hij belandt in de spam of wordt meteen geweigerd.
• SPF, DKIM en DMARC kloppen niet met elkaar. Veel formulieren zetten het adres van de bezoeker in het From-veld. Het bericht beweert dan bijvoorbeeld van een gmail.com-adres te komen, maar wordt door uw webserver verstuurd – precies wat DMARC moet tegenhouden.
• Een plug-inupdate of themawissel breekt het formulier of de CAPTCHA. Een gewijzigde template laat een veld weg, een script laadt niet meer, of de CAPTCHA-widget verschijnt zonder script – en elke inzending zakt voor de validatie.
• De ontvangende mailbox is vol. De mailserver weigert nieuwe berichten, en de bounce gaat naar een adres dat niemand leest.
• De cookiebanner blokkeert het formulierscript. Als de toestemmingstool de CAPTCHA of het formulierscript als “marketing” indeelt, krijgen bezoekers die cookies weigeren mogelijk een formulier dat niet kan worden verzonden, of waarvan de inzendingen worden geweigerd omdat er een token ontbreekt.
• Een verlopen TLS-certificaat of domein. Bezoekers zien een browserwaarschuwing en vertrekken, of de mailserver is niet meer veilig bereikbaar. Verloopt het domein van de ontvangende mailbox, dan stopt mail daarnaartoe gewoon.
• Een cachelaag levert verouderde pagina’s. Een full-page cache kan een formulier leveren met een verlopen beveiligingstoken (een nonce of CSRF-token). De server weigert de inzending, en afhankelijk van de configuratie ziet de bezoeker geen duidelijke foutmelding.

De valkuil van het From-adres

De derde oorzaak verdient een nadere blik, omdat veel formulierconfiguraties hem standaard ingebouwd hebben. DMARC controleert of het domein in het zichtbare From-adres overeenkomt met een domein waarvoor SPF of DKIM instaan. Als het formulier een bericht “van” het adres van de bezoeker verstuurt, is uw server niet gemachtigd om voor dat domein te verzenden, dus mislukt de controle. Afhankelijk van het DMARC-beleid van het domein van de bezoeker en van uw eigen mailprovider belandt het bericht in de spam of wordt het geweigerd. De oplossing is eenvoudig: verstuur vanaf een adres op uw eigen domein en zet het adres van de bezoeker in Reply-To. Met “Beantwoorden” bereikt u de bezoeker nog steeds.

Wat u kunt doen

1. 1Stuur regelmatig een testbericht via uw eigen formulier – minstens maandelijks, en altijd na updates, themawissels of wijzigingen in de mailinstellingen. Markeer het duidelijk als test, zodat niemand erop antwoordt.
2. 2Ken uw normale ritme. Levert het formulier gewoonlijk een paar berichten per week op, dan is twee weken stilte een reden om te controleren, geen rustige maand.
3. 3Verstuur via SMTP met authenticatie – via uw mailprovider of een speciale verzenddienst – in plaats van te vertrouwen op PHP mail().
4. 4Gebruik uw eigen domein in From en het adres van de bezoeker in Reply-To. Stel daarna SPF, DKIM en DMARC in voor dat domein, zodat de berichten door de controles komen.
5. 5Bewaar een kopie van elke inzending in de database. Veel formulierplug-ins bieden dat, soms als add-on. Mislukt de mail, dan zijn de aanvragen er nog.
6. 6Controleer het formulier na elke plug-inupdate – inclusief de CAPTCHA, en ook met geweigerde cookies.

Zulke controles worden makkelijk vergeten, daarom loont het ze te automatiseren. Met een account en een geverifieerd domein kan formexposed een duidelijk gemarkeerde testinzending versturen en controleren of die echt aankomt (de bezorgcontrole, alleen na aanmelding). Het detecteert ook stilte – een formulier dat normaal berichten krijgt en plotseling geen enkele meer – en controleert SPF, DKIM en DMARC van de meldingsmails en het verlopen van TLS-certificaat en domein. U krijgt alleen een melding als er iets verandert.

Wilt u gewoon een eerste indruk: een gratis controle op formexposed.com heeft geen account nodig en verzendt niets. Ze laat onder meer zien of een CAPTCHA aanwezig maar defect is – een widget zonder script, een openbare testsleutel, fouten in de browser – een van de stillere manieren waarop een formulier ophoudt te werken. Of berichten echt aankomen, kan alleen een echt testbericht bevestigen, dus stuur er vandaag nog een.