Mail vanaf je website en formulieren

Module 7: Nieuwsbrieven en mail vanaf je website · Leestijd: 11 minuten

Leerdoel: Na deze les kun je websitemail (contactformulieren, bestelbevestigingen, WordPress-meldingen) zo instellen dat hij aankomt, geen DMARC-problemen geeft en je pakket niet laat misbruiken.

Kernbegrippen: PHP mail(), SMTP met inloggen, envelope-afzender, From vs. Reply-To, het bezoekersadres nooit als From, SMTP-plugin, transactiemail, formulierspam, captcha, honeypot, verzendlimiet, lokale aflevering als de MX elders staat

Je website is ook een mailprogramma

Je website verstuurt meer mail dan je denkt. Een contactformulier mailt jou elk bericht. Een webwinkel stuurt bestelbevestigingen, facturen en verzendberichten. WordPress mailt bij een nieuwe reactie, een update of een wachtwoordreset. Voor de ontvanger is dat gewoon mail van jouw domein, en hij wordt net zo streng gecontroleerd als mail uit je mailbox: SPF, DKIM, DMARC, reputatie.

Toch gaat websitemail vaker mis dan gewone mail. Dat komt meestal door een van drie dingen: de manier van versturen, het afzenderadres, of misbruik van het formulier.

Manier 1: PHP mail()

De eenvoudigste manier voor een website om te mailen is de PHP-functie mail(). De website geeft de mail dan direct aan het mailprogramma van de webserver, zonder in te loggen. Het werkt meestal, maar er zitten nadelen aan:

• De envelope-afzender (Return-Path) wordt vaak het systeemaccount van je pakket, zoals gebruiker@server.hosting.example, en niet jouw adres. SPF wordt dan gecontroleerd voor het domein van de server, en is dus niet uitgelijnd met jouw From-domein (les 7.1).
• Of er een DKIM-handtekening van jouw domein op komt, hangt af van de server. Op sommige servers wel, op andere niet.
• Je ziet niets terug. Komt de mail niet aan of krijg je een bounce, dan gaat die naar het systeemaccount, waar niemand kijkt.
• Geen limiet per formulier. Wordt het formulier misbruikt, dan verstuurt de server in jouw naam tot de limiet van je pakket bereikt is.

Manier 2: SMTP met inloggen (beter)

Laat je website versturen zoals je mailprogramma dat doet: inloggen op de uitgaande mailserver met een echte mailbox, via poort 587 (STARTTLS) of 465 (SSL/TLS), met het volledige e-mailadres als gebruikersnaam (les 1.4 en 2.1). Dan:

• is de envelope-afzender jouw adres en wordt de mail getekend zoals gewone mail van je domein;
• komen bounces in een mailbox die je kunt lezen;
• staat de verzonden mail, als je dat wilt, in de map Verzonden;
• kun je per mailbox een eigen verzendlimiet instellen.

In WordPress doe je dat met een SMTP-plugin. Die vervangt de standaard mailfunctie van WordPress door versturen via SMTP. Je vult dezelfde gegevens in als in een mailprogramma: server, poort, beveiliging, gebruikersnaam en wachtwoord. Maak daarvoor bij voorkeur een aparte mailbox, bijvoorbeeld website@example.com. Wordt het wachtwoord ooit gestolen, dan is je eigen mailbox veilig, en je ziet in één oogopslag welke mail van de website komt.

Voor een eigen PHP-site zijn er bibliotheken die via SMTP mailen, zoals PHPMailer. Zet het wachtwoord in een configuratiebestand buiten de webmap, niet in de code van een pagina.

Bij WebOké staan de gegevens voor SMTP in DirectAdmin-handleiding 8.1, met de servernaam van je pakket; bij andere aanbieders staan ze in de handleiding of de welkomstmail en werkt het op dezelfde manier.

Veel transactiemail? Gebruik een dienst

Verstuur je honderden bestelbevestigingen per dag, dan loont een transactiedienst: een verzenddienst voor automatische mail. Die heeft goede reputatie en laat zien wat er met elke mail gebeurde. Je koppelt het domein net als bij een nieuwsbriefdienst (DKIM via CNAME, les 7.1). Houd transactiemail en nieuwsbrieven gescheiden: een mislukte campagne mag niet de bevestigingsmail van je bestellingen raken.

De gouden regel: het bezoekersadres is nooit de afzender

Bij een contactformulier is het verleidelijk om de mail te laten versturen "van" de bezoeker. Dan kun je in je mailprogramma direct op Beantwoorden klikken. Dat ziet er zo uit:

From: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Maar jouw server mag helemaal niet namens example.net mailen. Stel dat example.net een DMARC-beleid p=reject heeft. De ontvangende server (die van jou, of die van Gmail als je mail doorstuurt) ziet een mail met From example.net die niet door SPF of DKIM van example.net komt, en weigert hem. Veel grote maildomeinen hebben een streng beleid: bij een controle op 8 november 2026 hadden onder meer yahoo.com, aol.com, ziggo.nl en kpnmail.nl een DMARC-beleid p=reject, en icloud.com, gmx.de en web.de p=quarantine. Een bezoeker met zo'n adres vult je formulier in, en jij krijgt het bericht nooit of in je spammap. Domeinen met p=none (zoals op dat moment gmail.com en hotmail.com) kunnen hun beleid elk moment aanscherpen, en Google schrijft in zijn richtlijnen uitdrukkelijk dat je Gmail-adressen niet als From mag nabootsen. Reken er dus nooit op dat het goed gaat.

De goede manier:

From: Website example.com <website@example.com>
Reply-To: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

De afzender is je eigen adres, dus SPF, DKIM en DMARC kloppen. Het adres van de bezoeker staat in Reply-To. Klik je op Beantwoorden, dan gaat je antwoord naar Pieter. In de meeste formulierplugins vind je dit bij de instellingen van de mail: zet bij Afzender (From) een vast adres van je eigen domein, en bij Reply-To het veld waarin de bezoeker zijn adres invult.

Formulieren tegen misbruik beschermen

Een formulier zonder bescherming wordt vroeg of laat gevonden door bots. In het beste geval krijg jij spam. In het slechtste geval misbruiken ze het om spam naar anderen te sturen: als je formulier een bevestiging stuurt naar "het adres dat de bezoeker invult", kan een bot daar elk adres ter wereld invullen, met eigen tekst in het bericht. Dan verstuurt jouw domein spam, met alle gevolgen voor je reputatie (les 5.2).

Bescherming in lagen:

• Captcha of een onzichtbare controle (zoals reCAPTCHA of Turnstile) houdt de meeste bots tegen.
• Honeypot: een verborgen veld dat mensen niet zien en bots wel invullen. Ingevuld? Dan wordt het bericht niet verstuurd.
• Geen vrije tekst in een bevestiging aan de bezoeker, of helemaal geen bevestiging naar het opgegeven adres. Een simpele melding "Bedankt, we hebben je bericht ontvangen" op de pagina is genoeg.
• Een verzendlimiet per mailbox voor de websitemailbox, lager dan die van je pakket.
• Software bijwerken. Oude plugins zijn een bekende ingang voor misbruik.

Merk je dat je pakket ineens veel mail verstuurt of krijg je een melding dat de daglimiet bereikt is terwijl je zelf weinig mailt? Wijzig dan direct de wachtwoorden en kijk welk formulier of script de mail verstuurt (les 3.4).

Mail staat elders, website hier

Een veelvoorkomende valkuil: je website staat bij de ene partij, je mail bij een andere (bijvoorbeeld Microsoft 365 of Google Workspace). Je MX wijst naar die andere partij. Maar de webserver denkt nog dat hij zelf de mail voor jouw domein afhandelt, omdat het domein ook op zijn eigen pakket staat. Mail van het formulier naar info@example.com levert hij dan lokaal af, in een mailbox op de webserver waar niemand kijkt, of hij geeft een fout als 550 ... mailbox unavailable.

De oplossing is in het paneel van de webserver aangeven dat de mail elders wordt afgehandeld. In DirectAdmin bij WebOké is dat het vinkje "Gebruik deze server om mijn e-mails af te handelen" bij MX Records (uitzetten). Andere panelen hebben vergelijkbare instellingen, zoals "e-mailrouting: extern" in cPanel. Nog beter: laat de website via SMTP mailen met een mailbox bij de partij waar je mail echt staat.

Samenvatting

• Websitemail wordt net zo streng gecontroleerd als gewone mail. Laat de site via SMTP met inloggen mailen, niet via mail().
• Gebruik een aparte mailbox voor de website, met een eigen verzendlimiet.
• Het adres van de bezoeker hoort in Reply-To, nooit in From. Anders faalt DMARC, en bij domeinen met p=reject (zoals yahoo.com, ziggo.nl, kpnmail.nl) wordt de mail geweigerd.
• Bescherm formulieren met captcha, honeypot en zonder vrije bevestigingen naar opgegeven adressen.
• Staat je mail bij een andere partij, zet lokale aflevering op de webserver uit of mail via SMTP bij die partij.

Quiz

Opdracht

Opdracht O7.3: Websitemail nalopen. Vul een formulier op je eigen website in met een Gmail- of Outlook.com-adres als afzender en bekijk de kopregels van het bericht dat bij jou binnenkomt. Beantwoord de checklist: welk adres staat in From, staat het bezoekersadres in Reply-To, wat zeggen spf=, dkim= en dmarc= bij Authentication-Results, verstuurt je site via SMTP of via mail(), en heeft het formulier een captcha of honeypot? Heb je geen eigen website, beantwoord de vragen dan voor het voorbeeld in deze les. Je krijgt daarna het modelantwoord.

Verder lezen

De stappen in deze artikelen gelden voor de panelen van WebOké; bij andere aanbieders werkt het vergelijkbaar.

• Een contactformulier op je website: velden laten mailen en spam voorkomen
• Hoe kan ik in php met mail() de juiste afzender krijgen? smtp
• Mail versturen via PHP lukt niet, de MX-records wijzen naar elders
• Limiet voor het versturen van mail
• Dagelijkse e-maillimiet bereikt
• DirectAdmin handleiding 8.1: Alle instellingen op een rij: servers, poorten en beveiliging
• DirectAdmin handleiding 5.10: E-mail bij Microsoft 365 of Google Workspace, website bij WebOké