Når kontaktformularen siger “Tak”, men der ikke kommer nogen mail

Forestil dig en lille fysioterapiklinik. Dens website har en kontaktformular, og formularen virker – eller det ser i hvert fald sådan ud. Besøgende udfylder den, klikker på “Send” og ser et venligt “Tak, vi vender snart tilbage”. Det, ingen ser: Beskederne holdt for et stykke tid siden op med at nå klinikkens indbakke. Der er ingen fejl, ingen returmail i nogens indbakke, intet rødt lys nogen steder. Formularen svigter i stilhed.

Hvorfor ingen opdager det

En formulars “Tak”-side betyder som regel kun én ting: Websitet har sendt beskeden videre. Om en mailserver accepterer den, sorterer den som spam eller afviser den undervejs, sker senere, uden for formularens synsfelt. PHP's mail()-funktion melder f.eks. succes, så snart det lokale system accepterer beskeden til levering – ikke når den når frem til nogen. Så den besøgende får en bekræftelse og går videre. Ejeren ser imens en tom indbakke og antager, at det bare er en stille måned. Færre henvendelser er sjældent alarmerende i sig selv: ferier, vejret, økonomien – der er altid en forklaring, der lyder mere plausibel end “formularen er i stykker”.

De sædvanlige årsager

• SMTP-adgangskoden eller mailudbyderen er ændret. Formularen bliver ved med at logge ind med de gamle oplysninger, og mailserveren afviser – i stilhed, så vidt den besøgende kan se.
• PHP mail() uden autentificering. Webserveren sender mail direkte uden at logge ind på en rigtig mailserver. Mange modtagende servere betragter sådan mail som mistænkelig: Den havner i spam eller afvises helt.
• SPF, DKIM og DMARC stemmer ikke overens. Mange formularer sætter den besøgendes adresse i From-feltet. Beskeden påstår så at komme fra f.eks. en gmail.com-adresse, men sendes af din webserver – præcis det, DMARC er designet til at stoppe.
• En plugin-opdatering eller et temaskifte ødelægger formularen eller dens CAPTCHA. En ændret skabelon fjerner et felt, et script indlæses ikke længere, eller CAPTCHA-widgetten vises uden sit script – og hver indsendelse fejler valideringen.
• Den modtagende postkasse er fuld. Mailserveren afviser nye beskeder, og returmailen går til en adresse, som ingen læser.
• Cookiebanneret blokerer formularscriptet. Hvis samtykkeværktøjet klassificerer CAPTCHA'en eller formularscriptet som “marketing”, kan besøgende, der afviser cookies, få en formular, der ikke kan indsendes, eller hvis indsendelser afvises, fordi et token mangler.
• Et udløbet TLS-certifikat eller domæne. Besøgende ser en advarsel i browseren og forlader siden, eller mailserveren kan ikke længere nås sikkert. Hvis domænet for den modtagende postkasse udløber, holder mail til den simpelthen op med at komme frem.
• Et cachelag leverer forældede sider. En helsidecache kan levere en formular med et udløbet sikkerhedstoken (en nonce eller et CSRF-token). Serveren afviser indsendelsen, og afhængigt af opsætningen ser den besøgende ingen tydelig fejl.

Fælden med From-adressen

Den tredje årsag fortjener et nærmere blik, fordi mange formularopsætninger har den indbygget som standard. DMARC kontrollerer, om domænet i den synlige From-adresse svarer til et domæne, som SPF eller DKIM går i god for. Hvis formularen sender en besked “fra” den besøgendes adresse, har din server ikke tilladelse til at sende for det domæne, så kontrollen fejler. Afhængigt af DMARC-politikken for den besøgendes domæne og af din egen mailudbyder havner beskeden i spam eller afvises. Løsningen er enkel: Send fra en adresse på dit eget domæne, og sæt den besøgendes adresse i Reply-To. Et klik på “Svar” når stadig frem til den besøgende.

Hvad du skal gøre

1. 1Send regelmæssigt en testbesked via din egen formular – mindst månedligt og altid efter opdateringer, temaskift eller ændringer i mailindstillingerne. Marker den tydeligt som test, så ingen besvarer den.
2. 2Kend din normale rytme. Hvis formularen normalt giver et par beskeder om ugen, er to ugers stilhed en grund til at tjekke, ikke en stille måned.
3. 3Send via SMTP med autentificering – gennem din mailudbyder eller en dedikeret afsendertjeneste – i stedet for at stole på PHP mail().
4. 4Brug dit eget domæne i From og den besøgendes adresse i Reply-To. Sæt derefter SPF, DKIM og DMARC op for det domæne, så beskederne består kontrollerne.
5. 5Gem en kopi af hver indsendelse i databasen. Mange formularplugins tilbyder det, sommetider som tilføjelse. Hvis mailen svigter, er henvendelserne der stadig.
6. 6Tjek formularen efter hver plugin-opdatering – inklusive CAPTCHA'en og også med afviste cookies.

Den slags kontroller er lette at glemme, og derfor betaler det sig at automatisere dem. Med en konto og et verificeret domæne kan formexposed sende en tydeligt mærket testindsendelse og kontrollere, om den faktisk kommer frem (leveringskontrollen, kun efter tilvalg). Den opdager også stilhed – en formular, der normalt får beskeder, men pludselig ingen får – og kontrollerer SPF, DKIM og DMARC for notifikationsmailene samt udløb af TLS-certifikat og domæne. Du får kun en alarm, når noget ændrer sig.

Hvis du bare vil have et første indtryk: En gratis kontrol på formexposed.com kræver ingen konto og indsender intet. Den viser blandt andet, om en CAPTCHA er til stede, men ødelagt – en widget uden sit script, en offentlig testnøgle, fejl i browseren – en af de mere stille måder, en formular holder op med at virke på. Om beskeder virkelig kommer frem, kan kun en rigtig testbesked bekræfte, så send en i dag.