När kontaktformuläret säger ”Tack” men inget mejl kommer fram

Tänk dig en liten fysioterapimottagning. Dess webbplats har ett kontaktformulär, och formuläret fungerar – eller ser åtminstone ut att göra det. Besökare fyller i det, klickar på ”Skicka” och ser ett vänligt ”Tack, vi återkommer snart”. Det ingen ser: meddelandena slutade nå mottagningens inkorg för en tid sedan. Det finns inget fel, ingen studs i någons inkorg, ingen röd lampa någonstans. Formuläret fallerar i tysthet.

Varför ingen märker något

Ett formulärs ”Tack”-sida betyder oftast bara en sak: webbplatsen har lämnat vidare meddelandet. Om en e-postserver godtar det, sorterar det som spam eller avvisar det längs vägen sker senare, utom synhåll för formuläret. PHP:s funktion mail() rapporterar till exempel att det lyckats så snart det lokala systemet tar emot meddelandet för leverans – inte när det når någon. Besökaren får alltså en bekräftelse och går vidare. Ägaren ser under tiden en tom inkorg och antar att det bara är en lugn månad. Färre förfrågningar är sällan alarmerande i sig: semestrar, vädret, konjunkturen – det finns alltid en förklaring som låter rimligare än ”formuläret är trasigt”.

De vanliga orsakerna

• SMTP-lösenordet eller e-postleverantören har ändrats. Formuläret fortsätter att logga in med de gamla uppgifterna och e-postservern vägrar – i tysthet, så långt besökaren kan se.
• PHP mail() utan autentisering. Webbservern skickar e-post direkt, utan att logga in på en riktig e-postserver. Många mottagande servrar behandlar sådan e-post som misstänkt: den hamnar i skräpposten eller avvisas direkt.
• SPF, DKIM och DMARC stämmer inte överens. Många formulär lägger besökarens adress i From-fältet. Meddelandet påstår då att det kommer från, säg, en gmail.com-adress men skickas av din webbserver – exakt det som DMARC är utformat för att stoppa.
• En pluginuppdatering eller ett temabyte förstör formuläret eller dess CAPTCHA. En ändrad mall tappar ett fält, ett skript laddas inte längre, eller CAPTCHA-widgeten visas utan sitt skript – och varje inskick misslyckas i valideringen.
• Den mottagande brevlådan är full. E-postservern vägrar ta emot nya meddelanden, och studsen går till en adress som ingen läser.
• Cookiebannern blockerar formulärskriptet. Om samtyckesverktyget klassar CAPTCHA:n eller formulärskriptet som ”marknadsföring” kan besökare som avvisar cookies få ett formulär som inte går att skicka, eller vars inskick avvisas eftersom en token saknas.
• Ett utgånget TLS-certifikat eller en utgången domän. Besökare ser en varning i webbläsaren och lämnar sidan, eller så kan e-postservern inte längre nås säkert. Om domänen för den mottagande brevlådan går ut slutar e-posten till den helt enkelt att komma fram.
• Ett cachningslager levererar inaktuella sidor. En helsidescache kan leverera ett formulär med en utgången säkerhetstoken (en nonce eller CSRF-token). Servern avvisar inskicket, och beroende på konfigurationen ser besökaren inget tydligt fel.

Fällan med From-adressen

Den tredje orsaken förtjänar en närmare titt, eftersom många formulärlösningar har den inbyggd som standard. DMARC kontrollerar om domänen i den synliga From-adressen stämmer med en domän som SPF eller DKIM går i god för. Om formuläret skickar ett meddelande ”från” besökarens adress är din server inte behörig att skicka för den domänen, så kontrollen misslyckas. Beroende på DMARC-policyn för besökarens domän och på din egen e-postleverantör hamnar meddelandet i skräpposten eller avvisas. Lösningen är enkel: skicka från en adress på din egen domän och lägg besökarens adress i Reply-To. Ett klick på ”Svara” når fortfarande besökaren.

Vad du kan göra

1. 1Skicka regelbundet ett testmeddelande via ditt eget formulär – minst en gång i månaden, och alltid efter uppdateringar, temabyten eller ändringar av e-postinställningarna. Märk det tydligt som test så att ingen svarar på det.
2. 2Känn till din normala rytm. Om formuläret vanligtvis ger några meddelanden i veckan är två veckors tystnad ett skäl att kontrollera, inte en lugn månad.
3. 3Skicka via SMTP med autentisering – via din e-postleverantör eller en särskild utskickstjänst – i stället för att förlita dig på PHP mail().
4. 4Använd din egen domän i From och besökarens adress i Reply-To. Konfigurera sedan SPF, DKIM och DMARC för den domänen så att meddelandena klarar kontrollerna.
5. 5Spara en kopia av varje inskick i databasen. Många formulärplugin erbjuder detta, ibland som tillägg. Om e-posten fallerar finns förfrågningarna ändå kvar.
6. 6Kontrollera formuläret efter varje pluginuppdatering – inklusive CAPTCHA:n, och även med avvisade cookies.

Kontroller som dessa är lätta att glömma, och därför lönar det sig att automatisera dem. Med ett konto och en verifierad domän kan formexposed skicka ett tydligt märkt testinskick och kontrollera om det faktiskt kommer fram (leveranskontrollen, endast efter aktivt val). Den upptäcker också tystnad – ett formulär som normalt får meddelanden plötsligt inte får några – och kontrollerar SPF, DKIM och DMARC för aviseringsmejlen samt när TLS-certifikat och domän går ut. Du larmas bara när något förändras.

Om du bara vill ta en första titt: en gratisgranskning på formexposed.com kräver inget konto och skickar ingenting. Den visar bland annat om en CAPTCHA finns men är trasig – en widget utan sitt skript, en offentlig testnyckel, fel i webbläsaren – ett av de tystare sätten på vilka ett formulär slutar fungera. Om meddelanden verkligen kommer fram kan bara ett riktigt testmeddelande bekräfta, så skicka ett i dag.