Waarom je contactformulier je grootste spamrisico is

Het probleem is ouder dan je denkt

Contactformulieren zijn al sinds begin jaren 2000 een spamvector, maar het probleem is groter geworden doordat e-mailproviders hun authenticatie-eisen hebben aangescherpt. De meeste contactformulieren zijn nog steeds op dezelfde manier gebouwd: een gebruiker vult een formulier in, je server stuurt een e-mail met het adres van de gebruiker in de From-header, en jij wacht op antwoorden.

Dit is een schoolvoorbeeld van een kwetsbaarheid voor e-mailspoofing. Spammers kunnen je formulier gebruiken om e-mail te verzenden die van elk gewenst adres lijkt te komen, gerouteerd via het IP-adres van je server. Als er op deze manier genoeg spam wordt verstuurd, wordt je domein gemarkeerd en komt je legitieme transactionele e-mail niet meer in inboxen aan.

De oplossing is eenvoudig, maar de meeste tutorials doen het nog steeds verkeerd.

Waarom contactformulieren zo eenvoudig te misbruiken zijn

Een typisch contactformulier accepteert drie velden: naam, e-mail en bericht. De server-side handler neemt dat e-mailadres en plaatst het rechtstreeks in de From-header van een uitgaand SMTP-bericht. Dat is handig voor antwoorden—je kunt gewoon op "beantwoorden" klikken in je inbox—maar het is ook een cadeau voor spammers.

Dit gebeurt er wanneer een spammer je formulier vindt:

1. Ze dienen het formulier in met het e-mailadres van een slachtoffer in het veld "from"
2. Je server stuurt plichtsgetrouw een e-mail met het adres van dat slachtoffer in de From-header
3. De mailserver van het slachtoffer ziet e-mail die beweert van hun domein te komen, maar afkomstig is van jouw IP-adres
4. Als je domein geen goede SPF/DKIM/DMARC-records heeft (of zelfs als het die wel heeft), kan de e-mail nog steeds doorkomen omdat veel servers soepel omgaan met verkeer van contactformulieren
5. Het slachtoffer ontvangt spam die van hun eigen adres lijkt te komen, of je domein wordt gemarkeerd voor spoofing

Dit is geen theoretische aanval. Het gebeurt voortdurend. Als je een contactformulier gebruikt en je nog nooit je mailserverlogs hebt gecontroleerd, word je waarschijnlijk al op deze manier misbruikt.

De juiste manier om e-mail vanuit contactformulieren te verzenden

De oplossing is om nooit gebruikersinvoer in de From-header te plaatsen. Gebruik in plaats daarvan:

• From: [email protected] (of een ander adres dat je beheert)
• Reply-To: Het door de gebruiker opgegeven e-mailadres
• Subject: Neem de naam van de gebruiker op als je wilt, maar nooit diens e-mailadres
• Body: Neem alle formuliergegevens op, duidelijk gelabeld

Zo verzendt je server alleen e-mail vanaf adressen die je bezit en correct hebt geauthenticeerd. Wanneer je in je inbox op "beantwoorden" klikt, gaat het antwoord nog steeds naar de gebruiker—dat is wat Reply-To doet. Maar spammers kunnen je formulier niet gebruiken om zich voor te doen als willekeurige adressen.

De meeste e-mailbibliotheken ondersteunen dit standaard. In PHP's PHPMailer:

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

In Python's smtplib met email.mime:

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

In Node.js met Nodemailer:

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

Als je contactformulier momenteel gebruikersinvoer in de From-header plaatst, is dit een oplossing van één regel. Doe het vandaag nog.

Rate limiting is niet optioneel

Zelfs met correcte headerhygiëne blijft een onbeschermd contactformulier een spamvector. Spammers zullen je formulier honderden keren indienen met verschillende berichtteksten, en je inbox loopt vol met rommel.

Je hebt rate limiting nodig op meerdere niveaus:

• Per IP: Niet meer dan 5 inzendingen per uur vanaf hetzelfde IP-adres
• Per e-mail: Niet meer dan 3 inzendingen per dag vanaf hetzelfde e-mailadres
• Globaal: Niet meer dan 50 inzendingen per uur over alle gebruikers heen (pas dit aan op basis van je verkeer)

Rate limiting hoort in je applicatiecode, niet alleen in de configuratie van je webserver. Rate limiting in Nginx en Apache kan helpen, maar die werkt op requestniveau en kent geen e-mailadressen of misbruikpatronen die specifiek zijn voor formulieren.

Als je een framework gebruikt, is er waarschijnlijk rate-limiting middleware die je kunt toevoegen. Als je vanaf nul bouwt, werkt een eenvoudige Redis-counter met aflopende sleutels prima:

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")

Dit is niet waterdicht—spammers kunnen IP-adressen roteren—maar het verhoogt de kosten van misbruik aanzienlijk.

CAPTCHA's zijn een afweging, geen oplossing

Google's reCAPTCHA v3 is onzichtbaar en beoordeelt gebruikers op basis van gedrag, wat ideaal klinkt. In de praktijk blokkeert het vaker legitieme gebruikers dan je zou verwachten, vooral gebruikers op VPNs, Tor of gedeelde bedrijfsnetwerken.

reCAPTCHA v2 (het selectievakje "Ik ben geen robot") is betrouwbaarder, maar voegt frictie toe. Honeypot-velden—verborgen formulierinvoer die mensen niet invullen maar bots wel—vangen weinig geavanceerde bots zonder impact op gebruikers, maar zijn triviaal te omzeilen voor elke serieuze spammer.

De beste aanpak is gelaagd:

1. Correcte e-mailheaders (niet-onderhandelbaar)
2. Rate limiting (niet-onderhandelbaar)
3. Honeypot-veld (makkelijke winst, geen nadeel)
4. CAPTCHA alleen als je na het bovenstaande nog steeds aanzienlijke hoeveelheden spam ontvangt

Als je een CAPTCHA toevoegt, gebruik dan reCAPTCHA v3 met een lage drempel (0,5 of lager) en een fallback naar v2 voor gebruikers die slecht scoren. Zo blijft de frictie voor de meeste gebruikers laag, terwijl bots toch worden geblokkeerd.

Wanneer je een formulierdienst van een derde partij gebruikt

Als je een kleine site beheert en geen formulierinfrastructuur wilt onderhouden, handelen diensten van derden zoals Formspree, Tally of Netlify Forms dit allemaal voor je af. Ze passen rate limiting toe, valideren en verzenden e-mail vanaf hun eigen domeinen, zodat jouw reputatie schoon blijft.

De afweging is dat je gebruikersgegevens naar een derde partij stuurt, wat kan botsen met je privacybeleid of GDPR-verplichtingen. Gegevens client-side verwerken is een groeiende trend voor teams die privacy belangrijk vinden, maar contactformulieren vereisen van nature server-side verwerking—je kunt geen e-mail vanuit de browser verzenden zonder inloggegevens bloot te stellen.

Als je gevoelige vragen behandelt (juridisch, medisch, financieel), moet je waarschijnlijk je eigen formulierinfrastructuur draaien. Voor al het andere is een dienst van een derde partij een redelijke keuze.

Het DMARC-probleem

Zelfs als je de headers van je contactformulier corrigeert, ben je niet veilig als je domein geen DMARC-beleid heeft. DMARC vertelt ontvangende mailservers wat ze moeten doen met e-mail die SPF- of DKIM-controles niet doorstaat. Zonder DMARC kunnen spammers nog steeds e-mail verzenden die van jouw domein lijkt te komen, zelfs als ze je servers niet gebruiken.

Het instellen van DMARC valt buiten de scope van dit artikel, maar als je e-mailreputatie serieus neemt, is het niet-onderhandelbaar. Begin met een beleid dat alleen monitort (p=none) en ga geleidelijk over naar p=quarantine of p=reject zodra je hebt geverifieerd dat je legitieme e-mail correct is geauthenticeerd.

Hoe zit het met cookietoestemming en formuliertracking?

Als je contactformulier analytics- of marketingpixels gebruikt om inzendingen te volgen, val je waarschijnlijk onder GDPR- en ePrivacy-regels. De meeste contactformulieren hebben geen tracking nodig—je weet al dat iemand het formulier heeft ingediend omdat je de e-mail hebt ontvangen—maar als je iets gebruikt zoals Facebook Pixel of Google Analytics events, heb je expliciete toestemming nodig voordat die scripts laden.

De eenvoudigste aanpak is om inzendingen van contactformulieren helemaal niet te tracken. Als je ze toch moet tracken, laad trackingscripts dan alleen nadat de gebruiker toestemming heeft gegeven, en zorg ervoor dat je toestemmingsbanner compliant is.

Belangrijkste punten

• Plaats nooit door gebruikers opgegeven e-mailadressen in de From-header. Gebruik in plaats daarvan Reply-To.
• Rate limiting is verplicht. Implementeer het op applicatieniveau, niet alleen op de webserver.
• Honeypot-velden zijn gratis winst. CAPTCHA's zouden een laatste redmiddel moeten zijn.
• Formulierdiensten van derden zijn een redelijke keuze voor kleine sites, maar ze brengen privacyafwegingen met zich mee.
• Als je e-mail verzendt vanaf je domein, heb je een DMARC-beleid nodig.

FAQ

Q: Kan ik het contactformulier gewoon uitschakelen en in plaats daarvan een mailto-link gebruiken?

A: Dat kan, maar mailto-links stellen je e-mailadres bloot aan scrapers, en je verliest de mogelijkheid om gestructureerde gegevens te verzamelen. Als spam overweldigend is, is een mailto-link beter dan een kapot contactformulier, maar het formulier repareren is beter dan beide.

Q: Wat als ik om legitieme redenen e-mail moet verzenden vanaf het adres van de gebruiker?

A: Dat hoef je vrijwel zeker niet. Als je denkt van wel, probeer je waarschijnlijk een workflowprobleem op te lossen (zoals het routeren van antwoorden) dat Reply-To al oplost. Als je echt e-mail vanaf willekeurige adressen moet verzenden, heb je een dedicated e-maildienst met correcte authenticatie nodig, geen contactformulier.

Q: Hoe weet ik of mijn contactformulier al wordt misbruikt?

A: Controleer je mailserverlogs op uitgaande SMTP-verbindingen. Als je een hoog volume uitgaande e-mail ziet naar adressen die je niet herkent, of als je domein is gemarkeerd door spamdatabases zoals Spamhaus, word je waarschijnlijk als relay gebruikt. Tools zoals MXToolbox kunnen de reputatie van je domein controleren.

Q: Is het veilig om een gratis CAPTCHA-dienst te gebruiken?

A: Google's reCAPTCHA is gratis en wordt breed gebruikt, maar stuurt gebruikersgegevens naar Google, wat kan botsen met je privacybeleid. hCaptcha is een privacygerichte alternatief dat geen AI-modellen traint op je gebruikers. Cloudflare Turnstile is een andere optie die minder opdringerig is dan traditionele CAPTCHA's.

Q: Wat is het verschil tussen SPF, DKIM en DMARC?

A: SPF vermeldt welke mailservers e-mail vanaf je domein mogen verzenden. DKIM ondertekent uitgaande e-mail cryptografisch, zodat ontvangers kunnen verifiëren dat ermee niet is geknoeid. DMARC brengt ze samen en vertelt ontvangers wat ze moeten doen als een e-mail SPF- of DKIM-controles niet doorstaat. Je hebt alle drie nodig voor correcte e-mailauthenticatie.

Bronnen

• OWASP: Email Header Injection — Gedetailleerde uitleg van hoe contactformulieren kunnen worden misbruikt voor e-mailspoofing.
• RFC 5322: Internet Message Format — De technische standaard die e-mailheaders definieert, waaronder From en Reply-To.
• DMARC.org: Overview — Officiële bron voor het begrijpen en implementeren van DMARC-beleid.
• Spamhaus: Domain Blocklists — Controleer of je domein is gemarkeerd voor spam en begrijp hoe blocklists werken.