Een klant belde me gisteren. Ze had al drie weken geen aanvragen meer ontvangen via haar website. Ze dacht dat het gewoon rustig was. Het was haar drukste seizoen.
Het formulier stond er nog. Zag er prima uit. Knoppen werkten. Maar de mails kwamen nergens aan. Dit is een van de vervelendste storingen die je kunt hebben, omdat niemand het merkt totdat de schade al is aangericht. Geen foutmelding, geen rode banner, gewoon stilte.
Hoe een formulier eigenlijk een mail verstuurt
Voordat je kunt debuggen, moet je begrijpen wat er technisch gebeurt. Wanneer iemand op “Verzenden” klikt, stuurt WordPress een verzoek naar een PHP-functie, die via de mailserver van je hosting een e-mail probeert te versturen. Die mailserver kijkt vervolgens of hij toestemming heeft om mail te sturen namens jouw domein.
Daar gaat het al mis. Shared hostingservers staan erom bekend dat hun IP-adressen op spamlijsten staan. Ontvangende mailservers, zoals die van Gmail of Outlook, weigeren die mail gewoon. Geen bounce, geen foutmelding, niets. De mail verdwijnt in het niets.
De standaard WordPress-mailfunctie, wp_mail(), gebruikt de PHP mail()-functie van de server. Die heeft geen authenticatie. Geen handtekening, geen bewijs dat jij degene bent die mailt. Moderne spamfilters vertrouwen dat niet meer.
De drie plekken waar het misgaat
In vijftien jaar heb ik formulierstoringen teruggebracht tot drie hoofdoorzaken. Niet altijd even makkelijk te onderscheiden, maar ze zijn er altijd.
De servermail werkt niet. Dit is de meest voorkomende. Je hosting stuurt de mail, maar de ontvangende server weigert hem. Geen SPF-record, geen DKIM-handtekening, IP op een blacklist. De mail komt niet aan en jij weet het niet.
De plugin is kapot of conflicteert. Na een update van WordPress of een andere plugin kan je formulierplugin opeens andere verwachtingen hebben. Een bekende boosdoener: een beveiligingsplugin die PHP-functies blokkeert. Of een cacheplugin die de formulierpagina zo agressief cachet dat het formulier niet meer correct verwerkt wordt.
Het e-mailadres klopt niet. Dit klinkt simpel, maar ik zie het geregeld. Het ontvangende adres in de formulierinstellingen is een tikfout, of het postvak is vol, of het adres bestaat niet meer omdat iemand het bedrijf heeft verlaten.
Hoe je het snel test zonder tools te kopen
Je hebt geen dure software nodig om een formulierprobleem te diagnosticeren. Begin met het meest basale: stuur een testbericht via het formulier en check meteen daarna de spammap van het ontvangende adres. Meer dan de helft van de gevallen die ik zie, eindigt hier al.
Als dat niets oplevert, ga je kijken of WordPress überhaupt een mail probeert te sturen. Installeer tijdelijk een lichtgewicht plugin die alle uitgaande mails logt. Die laat je zien of wp_mail() wordt aangeroepen en of er een foutmelding terugkomt. Als de mail wél wordt verstuurd maar niet aankomt, zit het probleem bij de bezorging. Als de mail niet eens verstuurd wordt, zit het probleem bij de plugin of de configuratie.
Een snelle sanity check die ik altijd doe:
- Open de formulierinstellingen en controleer het ontvangende e-mailadres
- Stuur een testmail en bekijk de maillog
- Controleer of er een foutmelding staat in de logfile van de server
- Check of de beveiligingsplugin iets blokkeert
Dit kost je vijf minuten en sluit al het laaghangende fruit uit.
SMTP als structurele oplossing
Als je zeker weet dat het servermail-probleem is, is de enige echte oplossing SMTP. In plaats van de PHP-mailfunctie van je server te gebruiken, stuur je de mail via een externe mailserver die wél vertrouwd wordt. Denk aan de mailserver van je eigen domein, of een dedicated transactionele mailservice.
Je configureert dit via een SMTP-plugin in WordPress. Die vraagt om een hostname, poort, gebruikersnaam en wachtwoord. Dat zijn de gegevens van de mailserver die je wilt gebruiken. Gebruik je al een zakelijk mailadres via je hostingpakket, dan heb je die gegevens al in je bezit.
Na het instellen stuur je een testmail via de plugin zelf. Die geeft direct feedback of de verbinding lukt. Als het werkt, is je formulierprobleem in de meeste gevallen opgelost.
Één kanttekening: sla de SMTP-instellingen niet op in de database als plaintext. Gebruik een plugin die je toestaat om wachtwoorden als omgevingsvariabelen in te stellen, of sla ze op in het wp-config.php-bestand buiten de webroot. Een databasedump die uitlekt, bevat anders ook je mailcredentials.
Voorkomen dat je dit drie weken later ontdekt
Het echte probleem bij mijn klant was niet dat het formulier kapot ging. Het probleem was dat ze het niet wist. Drie weken lang geen aanvragen, en ze dacht dat het gewoon rustig was.
De oplossing daarvoor is monitoring, maar dan eenvoudig. Stuur elke keer dat het formulier wordt ingevuld ook een kopie naar een tweede e-mailadres, bij een andere provider. Als je normaal gesproken op Gmail ontvangt, stuur een kopie naar een Outlook-adres. Als beide stil zijn, is er iets mis. Als één van de twee ontvangt, weet je dat het aan de bezorging ligt.
Nog simpeler: sla formulierinzendingen op in de database. De meeste serieuze formulierplugins hebben deze optie. Dan heb je altijd een overzicht van wat er is binnengekomen, ongeacht of de mail het heeft gehaald. Je kunt dan dagelijks of wekelijks even kijken of het aantal inzendingen realistisch is voor het seizoen.
Een formulier dat stilletjes kapot gaat, is erger dan een formulier dat zichtbaar kapot is. Bij een zichtbare fout belt iemand je. Bij een stille fout wacht je gewoon op aanvragen die nooit komen.