Hvorfor din kontaktformular er din største spamrisiko

Problemet er ældre, end du tror

Kontaktformularer har været en spamvektor siden begyndelsen af 2000'erne, men problemet er blevet værre, efterhånden som e-mailudbydere har strammet deres krav til autentificering. De fleste kontaktformularer bygges stadig på samme måde: Brugeren udfylder en formular, din server sender en e-mail med brugerens adresse i From-headeren, og du venter på svar.

Det er en klassisk sårbarhed for e-mailspoofing. Spammere kan bruge din formular til at sende e-mail, der ser ud til at komme fra en vilkårlig adresse, de vælger, routet gennem din servers IP. Hvis der sendes nok spam på den måde, bliver dit domæne markeret, og dine legitime transaktionsmails holder op med at nå frem til indbakkerne.

Løsningen er ligetil, men de fleste tutorials gør det stadig forkert.

Hvad der gør kontaktformularer så nemme at udnytte

En typisk kontaktformular accepterer tre felter: navn, e-mail og besked. Server-side-handleren tager den e-mailadresse og lægger den direkte ind i From-headeren på en udgående SMTP-besked. Det er praktisk for svar — du kan bare trykke på "svar" i din indbakke — men det er også en gave til spammere.

Her er, hvad der sker, når en spammer finder din formular:

1. De indsender formularen med et offers e-mailadresse i "from"-feltet
2. Din server sender pligtskyldigt en e-mail med offerets adresse i From-headeren
3. Offerets mailserver ser en e-mail, der hævder at komme fra deres domæne, men som stammer fra din IP
4. Hvis dit domæne mangler korrekte SPF/DKIM/DMARC-poster (eller selv hvis det har dem), kan e-mailen stadig slippe igennem, fordi mange servere er lempelige med kontaktformulartrafik
5. Offeret modtager spam, der ser ud til at komme fra deres egen adresse, eller dit domæne bliver markeret for spoofing

Det er ikke et teoretisk angreb. Det sker konstant. Hvis du driver en kontaktformular og aldrig har tjekket dine mailserverlogs, bliver du sandsynligvis allerede brugt på denne måde.

Den korrekte måde at sende e-mail fra kontaktformularer på

Løsningen er aldrig at placere brugerinput i From-headeren. Gør i stedet følgende:

• From: [email protected] (eller en anden adresse, du kontrollerer)
• Reply-To: Brugerens indsendte e-mailadresse
• Subject: Medtag brugerens navn, hvis du vil, men aldrig deres e-mail
• Body: Medtag alle formulardata, tydeligt mærket

På den måde sender din server kun e-mail fra adresser, du ejer og har autentificeret korrekt. Når du trykker på "svar" i din indbakke, går svaret stadig til brugeren — det er det, Reply-To gør. Men spammere kan ikke bruge din formular til at udgive sig for at være vilkårlige adresser.

De fleste e-mailbiblioteker understøtter dette direkte. I PHP's PHPMailer:

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

I Python's 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,
  // ...
};

Hvis din kontaktformular i dag placerer brugerinput i From-headeren, er det en rettelse på én linje. Gør det i dag.

Rate limiting er ikke valgfrit

Selv med god headerhygiejne er en ubeskyttet kontaktformular stadig en spamvektor. Spammere vil indsende din formular hundredvis af gange med forskellige beskedtekster, og din indbakke vil blive fyldt med skrammel.

Du har brug for rate limiting på flere niveauer:

• Per IP: Højst 5 indsendelser pr. time fra samme IP
• Per e-mail: Højst 3 indsendelser pr. dag fra samme e-mailadresse
• Globalt: Højst 50 indsendelser pr. time på tværs af alle brugere (justér efter din trafik)

Rate limiting hører hjemme i din applikationskode, ikke kun i din webserverkonfiguration. Rate limiting i Nginx og Apache kan hjælpe, men de arbejder på requestniveau og kender ikke til e-mailadresser eller formularspecifikke misbrugsmønstre.

Hvis du bruger et framework, findes der sandsynligvis middleware til rate limiting, som du kan tilføje. Hvis du bygger fra bunden, fungerer en simpel Redis-tæller med udløbende nøgler fint:

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 er ikke skudsikkert — spammere kan rotere IP'er — men det øger omkostningen ved misbrug markant.

CAPTCHA'er er et kompromis, ikke en løsning

Google's reCAPTCHA v3 er usynlig og scorer brugere baseret på adfærd, hvilket lyder ideelt. I praksis blokerer den legitime brugere oftere, end man skulle tro, især brugere på VPN'er, Tor eller delte virksomhedsnetværk.

reCAPTCHA v2 (afkrydsningsfeltet "Jeg er ikke en robot") er mere pålidelig, men tilføjer friktion. Honeypot-felter — skjulte formularfelter, som mennesker ikke udfylder, men bots gør — fanger usofistikerede bots uden nogen brugerbelastning, men de er trivielle for enhver seriøs spammer at omgå.

Den bedste tilgang er lagdelt:

1. Korrekte e-mailheadere (ikke til forhandling)
2. Rate limiting (ikke til forhandling)
3. Honeypot-felt (en nem gevinst uden ulemper)
4. CAPTCHA kun hvis du stadig får betydelig spam efter ovenstående

Hvis du tilføjer en CAPTCHA, så brug reCAPTCHA v3 med en lav tærskel (0,5 eller lavere) og et fallback til v2 for brugere med lav score. Det holder friktionen lav for de fleste brugere, samtidig med at bots stadig blokeres.

Hvornår du bør bruge en tredjeparts formulartjeneste

Hvis du driver et lille site og ikke vil vedligeholde formularinfrastruktur, håndterer tredjepartstjenester som Formspree, Tally eller Netlify Forms alt dette for dig. De rate-limiter, validerer og sender e-mail fra deres egne domæner, så dit omdømme forbliver rent.

Kompromiset er, at du sender brugerdata til en tredjepart, hvilket kan være i konflikt med din privatlivspolitik eller dine GDPR-forpligtelser. Behandling af data på klientsiden er en voksende trend for privatlivsbevidste teams, men kontaktformularer kræver i sagens natur server-side-behandling — du kan ikke sende e-mail fra browseren uden at eksponere legitimationsoplysninger.

Hvis du håndterer følsomme henvendelser (juridiske, medicinske, finansielle), skal du sandsynligvis drive din egen formularinfrastruktur. Til alt andet er en tredjepartstjeneste et rimeligt valg.

DMARC-problemet

Selv hvis du retter dine kontaktformularheadere, er du ikke sikker, hvis dit domæne mangler en DMARC-politik. DMARC fortæller modtagende mailservere, hvad de skal gøre med e-mail, der fejler SPF- eller DKIM-kontroller. Uden den kan spammere stadig sende e-mail, der ser ud til at komme fra dit domæne, selv hvis de ikke bruger dine servere.

Opsætning af DMARC ligger uden for denne artikels rammer, men hvis du tager e-mailomdømme alvorligt, er det ikke til forhandling. Start med en politik kun til overvågning (p=none) og bevæg dig gradvist til p=quarantine eller p=reject, efterhånden som du verificerer, at din legitime e-mail er korrekt autentificeret.

Hvad med cookiesamtykke og formularsporing?

Hvis din kontaktformular bruger analytics eller marketingpixels til at spore indsendelser, er du sandsynligvis omfattet af GDPR- og ePrivacy-reglerne. De fleste kontaktformularer behøver ikke sporing — du ved allerede, at nogen har indsendt formularen, fordi du har modtaget e-mailen — men hvis du bruger noget som Facebook Pixel eller Google Analytics-events, skal du have udtrykkeligt samtykke, før de scripts indlæses.

Den enkleste tilgang er slet ikke at spore indsendelser fra kontaktformularer. Hvis du absolut skal spore dem, så indlæs kun sporingsscripts, efter brugeren har givet samtykke, og sørg for, at dit samtykkebanner er compliant.

Vigtige pointer

• Placér aldrig brugerindsendte e-mailadresser i From-headeren. Brug Reply-To i stedet.
• Rate limiting er obligatorisk. Implementér det på applikationsniveau, ikke kun på webserveren.
• Honeypot-felter er en gratis gevinst. CAPTCHA'er bør være sidste udvej.
• Tredjeparts formulartjenester er et rimeligt valg for små sites, men de medfører privatlivsmæssige kompromiser.
• Hvis du sender nogen form for e-mail fra dit domæne, har du brug for en DMARC-politik.

FAQ

Q: Kan jeg bare deaktivere kontaktformularen og bruge et mailto-link i stedet?

A: Det kan du, men mailto-links eksponerer din e-mailadresse for scrapers, og du mister muligheden for at indsamle strukturerede data. Hvis spam er overvældende, er et mailto-link bedre end en ødelagt kontaktformular, men at rette formularen er bedre end begge dele.

Q: Hvad hvis jeg af legitime grunde har brug for at sende e-mail fra brugerens adresse?

A: Det har du næsten med sikkerhed ikke. Hvis du tror, du har, prøver du sandsynligvis at løse et workflowproblem (som routing af svar), som Reply-To allerede løser. Hvis du reelt har brug for at sende e-mail fra vilkårlige adresser, har du brug for en dedikeret e-mailtjeneste med korrekt autentificering, ikke en kontaktformular.

Q: Hvordan ved jeg, om min kontaktformular allerede bliver misbrugt?

A: Tjek dine mailserverlogs for udgående SMTP-forbindelser. Hvis du ser en stor mængde udgående e-mail til adresser, du ikke genkender, eller hvis dit domæne er blevet markeret af spamdatabaser som Spamhaus, bliver du sandsynligvis brugt som relay. Værktøjer som MXToolbox kan tjekke dit domænes omdømme.

Q: Er det sikkert at bruge en gratis CAPTCHA-tjeneste?

A: Google's reCAPTCHA er gratis og udbredt, men den sender brugerdata til Google, hvilket kan være i konflikt med din privatlivspolitik. hCaptcha er et privatlivsfokuseret alternativ, der ikke træner AI-modeller på dine brugere. Cloudflare Turnstile er en anden mulighed, som er mindre indgribende end traditionelle CAPTCHA'er.

Q: Hvad er forskellen på SPF, DKIM og DMARC?

A: SPF angiver, hvilke mailservere der må sende e-mail fra dit domæne. DKIM signerer udgående e-mail kryptografisk, så modtagere kan verificere, at den ikke er blevet manipuleret med. DMARC binder dem sammen og fortæller modtagere, hvad de skal gøre, hvis en e-mail fejler SPF- eller DKIM-kontroller. Du har brug for alle tre for korrekt e-mailautentificering.

Kilder

• OWASP: Email Header Injection — Detaljeret forklaring af, hvordan kontaktformularer kan udnyttes til e-mailspoofing.
• RFC 5322: Internet Message Format — Den tekniske standard, der definerer e-mailheadere, herunder From og Reply-To.
• DMARC.org: Overview — Officiel ressource til at forstå og implementere DMARC-politikker.
• Spamhaus: Domain Blocklists — Tjek, om dit domæne er blevet markeret for spam, og forstå, hvordan blocklists fungerer.