Contactformulier-e-mails belanden in spam — de webserver-afzender-fix (2026)

Gepubliceerd 2026-07-08

Cijfers per 2026-06-29 · methodologie v7. Geaggregeerde censusgegevens over 261 miljoen beoordeelde domeinen. Zie hoe wij beoordelen.

Contactformulier- en website-e-mails belanden in spam omdat uw webserver ze zonder authenticatie verstuurt — geen SPF-autorisatie, geen DKIM-handtekening. De betrouwbare oplossing is die mail via geauthenticeerde SMTP routeren, niet de server whitelisten. 46,4% van de 261.086.232 domeinen die in de Defaults.Exposed-census zijn beoordeeld (gegevens per 2026-06-29), publiceert helemaal geen SPF-record.

De reparatievolgorde doet ertoe, en de meeste tutorials draaien haar om. Voer een gratis scan uit om te zien wat uw domein daadwerkelijk publiceert; routeer de mail van de site via geauthenticeerde SMTP (uw mailboxprovider of een transactionele e-maildienst) zodat ze een echte DKIM-handtekening krijgt; repareer het From-adres van het formulier; en voeg het IP van de server pas als allerlaatste redmiddel toe aan SPF.

Waarom belanden e-mails van mijn website in spam?

Vanwege wie ze werkelijk verstuurt. Wanneer een bezoeker uw contactformulier invult, wordt de e-mail niet door uw mailprovider verstuurd — de webserver genereert hem zelf, meestal via PHP’s mail(). Vanaf de ontvangende kant gezien:

komt dat bericht van een IP dat uw SPF-record niet autoriseert (uw SPF dekt uw mailprovider, niet uw webhost);
draagt het geen DKIM-handtekening, dus niets koppelt het cryptografisch aan uw domein;
vertrekt het vaak vanaf een gedeeld hosting-IP waarvan de reputatie wordt bepaald door de sites van honderden vreemden.

Niet-geauthenticeerde mail vanaf een IP met gemengde reputatie is precies waarvoor spamfilters bestaan — Gmail en Outlook zien een willekeurige server die beweert u te zijn. Het bredere beeld is somber: 46,4% van de domeinen publiceert helemaal geen SPF, en slechts 10,59% (27.640.987 van 261.086.232 beoordeelde domeinen, census per 2026-06-29) handhaaft een DMARC-beleid.

Waarom treft dit juist WordPress-sites?

WordPress verstuurt al zijn e-mail — formuliernotificaties, wachtwoordresets, orderbevestigingen — via één functie, wp_mail(), die standaard PHP mail() op de webserver inpakt. Elke WordPress-site die niet bewust anders is geconfigureerd, is dus vanaf het begin een niet-geauthenticeerde verzender. Formulierplugins (Contact Form 7, WPForms, Gravity Forms) geven mail allemaal door aan dezelfde functie: het lijkt een pluginprobleem, maar het is een transportprobleem.

De oplossing is niet een andere formulierplugin maar een SMTP-plugin (WP Mail SMTP en zijn equivalenten), die alles wat wp_mail() verstuurt omleidt via een echt, geauthenticeerd mailaccount — infrastructuur die uw SPF al autoriseert, met een DKIM-handtekening erbij.

Welke verzendmethode moet de site gebruiken?

Verzendmethode	SPF	DKIM	Overleeft een hostingmigratie?	Oordeel
PHP `mail()` / standaard `wp_mail()` vanaf de webserver	faalt	geen	n.v.t. — overal kapot	het probleem, geen optie
Geauthenticeerde SMTP via uw mailboxprovider (Google Workspace, Microsoft 365, enz.)	slaagt	ondertekend	ja — onafhankelijk van hosting	de oplossing voor de meeste sites
Transactionele e-maildienst (SES, Postmark, Brevo, enz.) met uw domein geverifieerd	slaagt	ondertekend	ja	de oplossing bij volume (e-commerce, grote formulieren)
IP van de webserver toegevoegd aan uw SPF-record	slaagt (alleen SPF)	geen	nee — breekt geruisloos wanneer het IP wijzigt	uitsluitend terugvaloptie — zie hieronder

Voor een paar notificaties per dag is SMTP via de mailbox waarvoor u al betaalt de kortste weg; bij echt volume is een transactionele dienst ervoor gebouwd. Beide geven u DKIM — de IP-whitelisting-sluiproute nooit.

Hoe repareer ik de bezorgbaarheid van contactformulier-e-mail?

Voer de gratis scan uit op defaults.exposed voordat u iets aanraakt. De scan laat zien welke SPF, DKIM en DMARC uw domein daadwerkelijk publiceert — of u het transport van het formulier repareert, een ontbrekend record, of beide. Helemaal geen SPF? Begin met hoe u SPF repareert.
Maak een aparte SMTP-identiteit voor de site aan — bijvoorbeeld [email protected] bij uw mailboxprovider, of een geverifieerd verzenddomein bij een transactionele dienst. Gebruik een app-wachtwoord of API-sleutel die u kunt intrekken, niet het mailboxwachtwoord van een persoon.
Routeer de mail van de site erdoorheen. WordPress: installeer een SMTP-plugin en laat die naar dat account wijzen. Andere stacks: configureer de mailer van het framework in plaats van lokale mail().
Repareer het From-adres (het antipatroon hieronder): From moet uw eigen domein zijn; de bezoeker gaat in Reply-To.
Is de verzender een transactionele dienst, voeg dan de DKIM-records van die dienst toe (meestal een paar CNAMEs) zodat mail met uw domein wordt ondertekend — de DNS-stappen zijn een spiegel van de SPF-installatiegidsen.
Verstuur een testinzending en scan opnieuw. De headers moeten spf=pass en dkim=pass voor uw domein tonen; werk daarna alles weg wat de scan verder aanmerkt via repareer SPF en repareer DKIM.

Waarom verstuurt het formulier “vanaf” het e-mailadres van de bezoeker?

De meest voorkomende zelf toegebrachte wond in formulierconfiguratie, en veel plugins deden het vroeger standaard: de notificatie komt binnen als From: het adres van de bezoeker, zodat u op beantwoorden kunt klikken. Het voelt handig, en het is vervalsing. Uw server heeft geen enkel recht om mail te versturen als [email protected] — het faalt op SPF en DKIM voor gmail.com, en het DMARC-beleid van Gmail vertelt ontvangende servers om het naar de spam te sturen of te weigeren. De oplossing kost niets:

From: een adres op uw eigen domein (de SMTP-identiteit uit stap 2)
Reply-To: het adres van de bezoeker — een antwoord gaat nog steeds rechtstreeks naar hem of haar

Elke gangbare formulierplugin ondersteunt dit; het zijn twee velden in de notificatie-instellingen.

Waarom niet gewoon het IP van de server aan mijn SPF-record toevoegen?

Het is de oplossing waar de meeste forumdraden als eerste naar grijpen, en niet voor niets slechts de terugvaloptie. ip4:<server> (of een a-mechanisme voor uw webhost) aan SPF toevoegen laat de kale check inderdaad slagen — maar:

Op gedeelde hosting autoriseert u vreemden. Het IP hoort bij de machine, niet bij u; elke andere site op die server kan nu SPF-geldige mail versturen als uw domein.
Het breekt geruisloos. Hosts migreren servers en rouleren IP’s zonder het u te vertellen; uw SPF blijft een adres autoriseren dat u maanden geleden hebt verlaten.
Het geeft u geen DKIM. SPF alleen breekt bij doorsturen en kan u niet richting DMARC-handhaving dragen zoals een handtekening dat kan.

Reserveer deze route voor het werkelijk beperkte geval: een dedicated server met een statisch IP dat u beheert en een applicatie die geen SMTP kan spreken — en combineer hem waar mogelijk met DKIM-ondertekening op de machine zelf.

Controleert SPF überhaupt het adres dat mijn formulier in “From” zet?

Nee — en daar struikelt de helft van de doe-het-zelfdiagnoses over. Ontvangende servers evalueren SPF tegen het Return-Path-domein (RFC5321.MailFrom), niet de From-header. Webservers stempelen vaak hun eigen hostnaam op het Return-Path, waardoor uw SPF-record nooit is geraadpleegd — de ontvangende server controleerde SPF voor srv0421.examplehost.com. Geauthenticeerde SMTP lost ook dit op: het Return-Path wordt uw domein, zodat de SPF-pass eindelijk voor u telt. Het is ook waarom DKIM ertoe doet — DMARC-alignment vereist een pass die is gekoppeld aan het domein in From, en een DKIM-handtekening reist mee met het bericht.

Veelgestelde vragen

Repareert een SMTP-plugin ook wachtwoordreset- en WooCommerce-e-mails? Ja. Op WordPress loopt alles via wp_mail(), dus het omleiden ervan repareert formuliernotificaties, wachtwoordresets en order-e-mails in één beweging.

Heb ik nog steeds SPF- en DKIM-records nodig als ik een SMTP-plugin gebruik? Ja — de plugin verandert welke infrastructuur uw mail verstuurt; de records zijn wat haar autoriseert. Hoort uw domein bij de 46,4% van de 261.086.232 beoordeelde domeinen zonder SPF-record (census, 2026-06-29), dan redt geauthenticeerde SMTP alleen u niet. De e-mailchecklist voor nieuwe domeinen behandelt de volledige set records.

Mijn formulier-e-mails slagen op SPF maar falen nog steeds op DMARC — hoe kan dat? Vrijwel altijd het From-spoofing-antipatroon hierboven, of SPF dat slaagt voor het Return-Path-domein van de host in plaats van dat van u. Repareer eerst From/Reply-To; faalt het daarna nog, dan is het ontbrekende stuk een aligned DKIM-handtekening — zie “DKIM signature not valid”. Falen ook SaaS-tools buiten de website, dan behandelt de gids over SPF-falen bij SaaS de reparatievolgorde.

Is dit alles de moeite waard voor een contactformulier met weinig verkeer? Het formulier is meestal waar het geld binnenkomt — een gemiste aanvraag is een klant van wie u nooit hebt geweten dat u hem verloor. En de oplossing is gratis; de drempel is wéten dat de webserver al die tijd de niet-geauthenticeerde verzender was.

Stuur de eigenaar het rapport

Bent u de ontwikkelaar of contractor die dit repareert: zodra de testinzending slaagt, voert u de gratis scan opnieuw uit en stuurt u het beoordeelde rapport door naar de eigenaar van de site — een gedateerd verslag in gewone taal dat het domein correct authenticeert, en het bewijsstuk dat hij nodig heeft voor de volgende cyberverzekeringsverlenging of beveiligingsvragenlijst van een klant. Leest u dit als eigenaar omdat er geen aanvragen meer binnenkomen: stuur deze pagina en uw scanrapport naar degene die uw website beheert — een klus van één middag, met een voor-en-na dat hij u kan laten zien.

Controleer uw domein → · SPF faalt voor uw SaaS-tools? → · Repareer SPF → · Hoe wij beoordelen → · Uitsluitend geaggregeerde gegevens. Gegevens opgeslagen en verwerkt in de EU.