Varför ditt kontaktformulär är din största spamrisk

Problemet är äldre än du tror

Kontaktformulär har varit en spamvektor sedan början av 2000-talet, men problemet har blivit värre i takt med att e-postleverantörer har skärpt sina autentiseringskrav. De flesta kontaktformulär är fortfarande byggda på samma sätt: användaren fyller i ett formulär, din server skickar ett e-postmeddelande med användarens adress i From-headern, och du väntar på svar.

Det här är en skolboksexempel på en sårbarhet för e-postspoofing. Spammare kan använda ditt formulär för att skicka e-post som ser ut att komma från vilken adress de vill, routad via din servers IP. Om tillräckligt mycket spam skickas på det här sättet flaggas din domän och din legitima transaktionsbaserade e-post slutar nå inkorgar.

Åtgärden är enkel, men de flesta guider gör fortfarande fel.

Vad som gör kontaktformulär så lätta att utnyttja

Ett typiskt kontaktformulär tar emot tre fält: namn, e-post och meddelande. Serverhanteraren tar den e-postadressen och lägger den direkt i From-headern i ett utgående SMTP-meddelande. Det är praktiskt för svar — du kan bara klicka på "svara" i inkorgen — men det är också en gåva till spammare.

Det här händer när en spammare hittar ditt formulär:

1. De skickar in formuläret med ett offers e-postadress i "from"-fältet
2. Din server skickar plikttroget ett e-postmeddelande med offrets adress i From-headern
3. Offrets e-postserver ser ett e-postmeddelande som påstår sig komma från deras domän, men som har sitt ursprung från din IP
4. Om din domän saknar korrekta SPF/DKIM/DMARC-poster (eller även om den har dem) kan e-postmeddelandet ändå släppas igenom eftersom många servrar är toleranta med trafik från kontaktformulär
5. Offret får spam som ser ut att komma från deras egen adress, eller så flaggas din domän för spoofing

Det här är inte en teoretisk attack. Det händer hela tiden. Om du driver ett kontaktformulär och aldrig har kontrollerat loggarna på din e-postserver används du förmodligen redan på det här sättet.

Rätt sätt att skicka e-post från kontaktformulär

Åtgärden är att aldrig lägga användarinmatning i From-headern. Gör så här i stället:

• From: [email protected] (eller någon adress du kontrollerar)
• Reply-To: Användarens inskickade e-postadress
• Subject: Ta med användarens namn om du vill, men aldrig deras e-postadress
• Body: Ta med alla formulärdata, tydligt märkta

På så sätt skickar din server bara e-post från adresser som du äger och har autentiserat korrekt. När du klickar på "svara" i inkorgen går svaret fortfarande till användaren — det är vad Reply-To gör. Men spammare kan inte använda ditt formulär för att utge sig för att vara godtyckliga adresser.

De flesta e-postbibliotek stöder detta direkt. I PHP:s PHPMailer:

$mail->setFrom('[email protected]', 'Contact Form');
$mail->addReplyTo($_POST['email'], $_POST['name']);

I Pythons smtplib med email.mime:

msg['From'] = '[email protected]'
msg['Reply-To'] = form_data['email']

I Node.js med Nodemailer:

const mailOptions = {
  from: '[email protected]',
  replyTo: req.body.email,
  // ...
};

Om ditt kontaktformulär i dag lägger användarinmatning i From-headern är detta en enradig åtgärd. Gör den i dag.

Rate limiting är inte valfritt

Även med god headerhygien är ett oskyddat kontaktformulär fortfarande en spamvektor. Spammare kommer att skicka in formuläret hundratals gånger med olika meddelandetexter, och din inkorg fylls med skräp.

Du behöver rate limiting på flera nivåer:

• Per IP: Högst 5 inskick per timme från samma IP
• Per email: Högst 3 inskick per dag från samma e-postadress
• Global: Högst 50 inskick per timme över alla användare (justera utifrån din trafik)

Rate limiting hör hemma i din applikationskod, inte bara i din webbserverkonfiguration. Rate limiting i Nginx och Apache kan hjälpa, men de arbetar på begärandenivå och känner inte till e-postadresser eller formulärspecifika missbruksmönster.

Om du använder ett ramverk finns det förmodligen middleware för rate limiting som du kan lägga till. Om du bygger från grunden fungerar en enkel Redis-räknare med utgående nycklar bra:

key = f"contact_form:{ip_address}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, 3600)  # 1 hour
if count > 5:
    return error("Rate limit exceeded")

Det här är inte vattentätt — spammare kan rotera IP-adresser — men det höjer kostnaden för missbruk avsevärt.

CAPTCHAs är en avvägning, inte en lösning

Googles reCAPTCHA v3 är osynligt och poängsätter användare baserat på beteende, vilket låter idealiskt. I praktiken blockerar det legitima användare oftare än du kanske väntar dig, särskilt användare på VPN:er, Tor eller delade företagsnätverk.

reCAPTCHA v2 (kryssrutan "I'm not a robot") är mer tillförlitligt men skapar friktion. Honeypot-fält — dolda formulärfält som människor inte fyller i men som bottar gör — fångar enkla bottar utan påverkan på användaren, men de är triviala för en seriös spammare att kringgå.

Den bästa metoden är lager på lager:

1. Korrekta e-postheaders (inte förhandlingsbart)
2. Rate limiting (inte förhandlingsbart)
3. Honeypot-fält (en enkel vinst, ingen nackdel)
4. CAPTCHA bara om du fortfarande får betydande mängder spam efter ovanstående

Om du lägger till en CAPTCHA, använd reCAPTCHA v3 med en låg tröskel (0,5 eller lägre) och en fallback till v2 för användare som får låg poäng. Det håller friktionen låg för de flesta användare samtidigt som bottar fortfarande blockeras.

När du bör använda en tredjepartstjänst för formulär

Om du driver en liten webbplats och inte vill underhålla formulärinfrastruktur hanterar tredjepartstjänster som Formspree, Tally eller Netlify Forms allt detta åt dig. De begränsar flödet, validerar och skickar e-post från sina egna domäner, så ditt rykte förblir rent.

Avvägningen är att du skickar användardata till en tredje part, vilket kan strida mot din integritetspolicy eller dina skyldigheter enligt GDPR. Att behandla data på klientsidan är en växande trend för integritetsmedvetna team, men kontaktformulär kräver i grunden serverbaserad behandling — du kan inte skicka e-post från webbläsaren utan att exponera autentiseringsuppgifter.

Om du hanterar känsliga förfrågningar (juridiska, medicinska, finansiella) behöver du förmodligen driva din egen formulärinfrastruktur. För allt annat är en tredjepartstjänst ett rimligt val.

DMARC-problemet

Även om du åtgärdar headers i ditt kontaktformulär är du inte säker om din domän saknar en DMARC-policy. DMARC talar om för mottagande e-postservrar vad de ska göra med e-post som inte klarar SPF- eller DKIM-kontroller. Utan det kan spammare fortfarande skicka e-post som ser ut att komma från din domän, även om de inte använder dina servrar.

Att konfigurera DMARC ligger utanför den här artikelns omfattning, men om du menar allvar med e-postrykte är det inte förhandlingsbart. Börja med en policy enbart för övervakning (p=none) och gå gradvis vidare till p=quarantine eller p=reject när du har verifierat att din legitima e-post är korrekt autentiserad.

Hur är det med samtycke till cookies och formulärspårning?

Om ditt kontaktformulär använder analysverktyg eller marknadsföringspixlar för att spåra inskick omfattas du förmodligen av GDPR och ePrivacy-regler. De flesta kontaktformulär behöver ingen spårning — du vet redan att någon skickade in formuläret eftersom du fick e-postmeddelandet — men om du använder något som Facebook Pixel eller Google Analytics-händelser behöver du uttryckligt samtycke innan dessa skript laddas.

Den enklaste metoden är att inte spåra inskick från kontaktformulär alls. Om du måste spåra dem, ladda spårningsskript först efter att användaren har samtyckt, och se till att din samtyckesbanner är compliant.

Viktiga slutsatser

• Lägg aldrig användarinskickade e-postadresser i From-headern. Använd Reply-To i stället.
• Rate limiting är obligatoriskt. Implementera det på applikationsnivå, inte bara i webbservern.
• Honeypot-fält är en gratis vinst. CAPTCHAs bör vara en sista utväg.
• Tredjepartstjänster för formulär är ett rimligt val för små webbplatser, men de innebär integritetsmässiga avvägningar.
• Om du skickar någon e-post från din domän behöver du en DMARC-policy.

FAQ

Q: Kan jag bara inaktivera kontaktformuläret och använda en mailto-länk i stället?

A: Det kan du, men mailto-länkar exponerar din e-postadress för scrapers, och du förlorar möjligheten att samla in strukturerade data. Om spam är överväldigande är en mailto-länk bättre än ett trasigt kontaktformulär, men att åtgärda formuläret är bättre än båda.

Q: Vad händer om jag behöver skicka e-post från användarens adress av legitima skäl?

A: Det behöver du nästan säkert inte. Om du tror att du gör det försöker du troligen lösa ett arbetsflödesproblem (som svarsroutning) som Reply-To redan löser. Om du verkligen behöver skicka e-post från godtyckliga adresser behöver du en dedikerad e-posttjänst med korrekt autentisering, inte ett kontaktformulär.

Q: Hur vet jag om mitt kontaktformulär redan missbrukas?

A: Kontrollera loggarna på din e-postserver för utgående SMTP-anslutningar. Om du ser en hög volym utgående e-post till adresser du inte känner igen, eller om din domän har flaggats av spamdatabaser som Spamhaus, används du förmodligen som relä. Verktyg som MXToolbox kan kontrollera din domäns rykte.

Q: Är det säkert att använda en gratis CAPTCHA-tjänst?

A: Googles reCAPTCHA är gratis och används brett, men den skickar användardata till Google, vilket kan strida mot din integritetspolicy. hCaptcha är ett integritetsinriktat alternativ som inte tränar AI-modeller på dina användare. Cloudflare Turnstile är ett annat alternativ som är mindre påträngande än traditionella CAPTCHAs.

Q: Vad är skillnaden mellan SPF, DKIM och DMARC?

A: SPF listar vilka e-postservrar som får skicka e-post från din domän. DKIM signerar utgående e-post kryptografiskt så att mottagare kan verifiera att den inte har manipulerats. DMARC binder ihop dem och talar om för mottagare vad de ska göra om ett e-postmeddelande inte klarar SPF- eller DKIM-kontroller. Du behöver alla tre för korrekt e-postautentisering.

Källor

• OWASP: Email Header Injection — Detaljerad förklaring av hur kontaktformulär kan utnyttjas för e-postspoofing.
• RFC 5322: Internet Message Format — Den tekniska standarden som definierar e-postheaders, inklusive From och Reply-To.
• DMARC.org: Overview — Officiell resurs för att förstå och implementera DMARC-policyer.
• Spamhaus: Domain Blocklists — Kontrollera om din domän har flaggats för spam och förstå hur blocklistor fungerar.