Mail fra din hjemmeside og formularer

Modul 7: Nyhedsbreve og mail fra din hjemmeside · Læsetid: 11 minutter

Læringsmål: Efter denne lektion kan du opsætte websitemail (kontaktformularer, ordrebekræftelser, WordPress-notifikationer), så den afleveres, ikke giver DMARC-problemer og ikke får din pakke misbrugt.

Kernebegreber: PHP mail(), SMTP med login, envelope sender (envelope-afsender), From vs. Reply-To, besøgendes adresse aldrig som From, SMTP-plugin, transaktionsmail, formularspam, captcha, honeypot, afsendelsesgrænse, lokal aflevering når MX peger andetsteds hen

Din hjemmeside er også et mailprogram

Din hjemmeside sender mere mail, end du tror. En kontaktformular mailer dig hver besked. En webshop sender ordrebekræftelser, fakturaer og forsendelsesbeskeder. WordPress mailer ved en ny kommentar, en opdatering eller en nulstilling af adgangskode. For modtageren er det bare mail fra dit domæne, og den bliver kontrolleret lige så strengt som mail fra din postkasse: SPF, DKIM, DMARC, omdømme.

Alligevel går websitemail oftere galt end almindelig mail. Det skyldes som regel en af tre ting: måden mailen sendes på, afsenderadressen, eller misbrug af formularen.

Metode 1: PHP mail()

Den enkleste måde for en hjemmeside at sende mail på er PHP-funktionen mail(). Hjemmesiden afleverer så mailen direkte til webserverens mailprogram, uden at logge ind. Det virker som regel, men der er ulemper:

• Envelope-afsenderen (Return-Path) bliver ofte systemkontoen for din pakke, som gebruiker@server.hosting.example, og ikke din egen adresse. SPF bliver så kontrolleret for serverens domæne, og er dermed ikke tilpasset (alignment) med dit From-domæne (lektion 7.1).
• Om der kommer en DKIM-signatur fra dit domæne på, afhænger af serveren. På nogle servere sker det, på andre ikke.
• Du ser ikke noget tilbage. Kommer mailen ikke frem, eller får du en bounce, så går den til systemkontoen, hvor ingen kigger.
• Ingen grænse pr. formular. Bliver formularen misbrugt, sender serveren i dit navn, indtil grænsen for din pakke er nået.

Metode 2: SMTP med login (bedre)

Lad din hjemmeside sende mail på samme måde som dit mailprogram gør: log ind på den udgående mailserver med en rigtig postkasse, via port 587 (STARTTLS) eller 465 (SSL/TLS), med den fulde mailadresse som brugernavn (lektion 1.4 og 2.1). Så:

• er envelope-afsenderen din egen adresse, og mailen bliver signeret som almindelig mail fra dit domæne;
• havner bounces i en postkasse, du kan læse;
• ligger den sendte mail, hvis du ønsker det, i mappen Sendt;
• kan du sætte en individuel afsendelsesgrænse pr. postkasse.

I WordPress gør du det med en SMTP-plugin. Den erstatter WordPress' standardmailfunktion med afsendelse via SMTP. Du udfylder de samme oplysninger som i et mailprogram: server, port, kryptering, brugernavn og adgangskode. Opret helst en separat postkasse til det, for eksempel website@example.com. Bliver adgangskoden stjålet en dag, er din egen postkasse sikker, og du kan med det samme se, hvilken mail der kommer fra hjemmesiden.

Til et eget PHP-site findes der biblioteker, som sender mail via SMTP, som f.eks. PHPMailer. Læg adgangskoden i en konfigurationsfil uden for webmappen, ikke i koden på en side.

Hos WebOké står oplysningerne til SMTP i DirectAdmin-vejledning 8.1, med servernavnet for din pakke; hos andre udbydere står de i vejledningen eller velkomstmailen, og det fungerer på samme måde.

Mange transaktionsmails? Brug en tjeneste

Sender du hundredvis af ordrebekræftelser om dagen, kan en transaktionstjeneste betale sig: en afsendelsestjeneste til automatisk mail. Den har et godt omdømme og viser dig, hvad der skete med hver mail. Du tilknytter domænet på samme måde som med en nyhedsbrevstjeneste (DKIM via CNAME, lektion 7.1). Hold transaktionsmail og nyhedsbreve adskilt: en mislykket kampagne må ikke påvirke bekræftelsesmailen for dine ordrer.

Den gyldne regel: den besøgendes adresse er aldrig afsenderen

Ved en kontaktformular er det fristende at lade mailen blive sendt "fra" den besøgende. Så kan du trykke direkte på Besvar i dit mailprogram. Det ser sådan ud:

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

Men din server må slet ikke sende mail på vegne af example.net. Antag at example.net har en DMARC-politik p=reject. Den modtagende server (din egen, eller Gmails, hvis du videresender mail) ser en mail med From example.net, som ikke kommer igennem SPF eller DKIM for example.net, og afviser den. Mange store maildomæner har en streng politik: ved en kontrol den 8. november 2026 havde blandt andet yahoo.com, aol.com, ziggo.nl og kpnmail.nl en DMARC-politik p=reject, og icloud.com, gmx.de og web.de havde p=quarantine. En besøgende med en sådan adresse udfylder din formular, og du modtager aldrig beskeden, eller den havner i din spammappe. Domæner med p=none (som på det tidspunkt gmail.com og hotmail.com) kan skærpe deres politik når som helst, og Google skriver udtrykkeligt i sine retningslinjer, at du ikke må efterligne Gmail-adresser som From. Regn derfor aldrig med, at det går godt.

Den rigtige måde:

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

Afsenderen er din egen adresse, så SPF, DKIM og DMARC stemmer. Den besøgendes adresse står i Reply-To. Trykker du på Besvar, går dit svar til Pieter. I de fleste formularplugins finder du dette under mailindstillingerne: sæt en fast adresse fra dit eget domæne som Afsender (From), og sæt det felt, hvor den besøgende indtaster sin adresse, som Reply-To.

Beskyt formularer mod misbrug

En formular uden beskyttelse bliver før eller siden fundet af bots. I bedste fald får du spam. I værste fald misbruger de den til at sende spam til andre: hvis din formular sender en bekræftelse til "den adresse, den besøgende indtaster", kan en bot indtaste en hvilken som helst adresse i verden, med sin egen tekst i beskeden. Så sender dit domæne spam, med alle konsekvenser for dit omdømme (lektion 5.2).

Beskyttelse i lag:

• Captcha eller en usynlig kontrol (som reCAPTCHA eller Turnstile) stopper de fleste bots.
• Honeypot: et skjult felt, som mennesker ikke ser, men bots udfylder. Er det udfyldt? Så bliver beskeden ikke sendt.
• Ingen fri tekst i en bekræftelse til den besøgende, eller slet ingen bekræftelse til den angivne adresse. En simpel besked "Tak, vi har modtaget din besked" på siden er nok.
• En afsendelsesgrænse pr. postkasse for websitepostkassen, lavere end grænsen for din pakke.
• Opdater software. Gamle plugins er en kendt indgang for misbrug.

Opdager du, at din pakke pludselig sender meget mail, eller får du en besked om, at dagsgrænsen er nået, selvom du selv sender lidt mail? Skift da straks adgangskoderne, og undersøg, hvilken formular eller script der sender mailen (lektion 3.4).

Mail ligger et andet sted, hjemmesiden her

En almindelig faldgrube: din hjemmeside ligger hos én udbyder, din mail hos en anden (for eksempel Microsoft 365 eller Google Workspace). Din MX peger på den anden udbyder. Men webserveren tror stadig, at den selv håndterer mailen for dit domæne, fordi domænet også ligger på dens egen pakke. Mail fra formularen til info@example.com afleverer den så lokalt, i en postkasse på webserveren, som ingen kigger i, eller den giver en fejl som 550 ... mailbox unavailable.

Løsningen er at angive i webserverens kontrolpanel, at mailen håndteres et andet sted. I DirectAdmin hos WebOké er det afkrydsningsfeltet "Brug denne server til at håndtere mine e-mails" under MX Records (slå det fra). Andre kontrolpaneler har tilsvarende indstillinger, som "e-mailrouting: ekstern" i cPanel. Endnu bedre: lad hjemmesiden sende mail via SMTP med en postkasse hos den udbyder, hvor din mail reelt ligger.

Opsummering

• Websitemail kontrolleres lige så strengt som almindelig mail. Lad siden sende mail via SMTP med login, ikke via mail().
• Brug en separat postkasse til hjemmesiden, med en egen afsendelsesgrænse.
• Den besøgendes adresse hører hjemme i Reply-To, aldrig i From. Ellers fejler DMARC, og hos domæner med p=reject (som yahoo.com, ziggo.nl, kpnmail.nl) bliver mailen afvist.
• Beskyt formularer med captcha, honeypot og uden fri bekræftelsestekst til angivne adresser.
• Ligger din mail hos en anden udbyder, så slå lokal aflevering fra på webserveren, eller send mail via SMTP hos den udbyder.

Quiz

Opgave

Opgave O7.3: Gennemgå hjemmesidemail. Udfyld en formular på din egen hjemmeside med en Gmail- eller Outlook.com-adresse som afsender, og se på headerne for den besked, der kommer ind til dig. Besvar tjeklisten: hvilken adresse står i From, står den besøgendes adresse i Reply-To, hvad siger spf=, dkim= og dmarc= under Authentication-Results, sender dit site mail via SMTP eller via mail(), og har formularen en captcha eller honeypot? Har du ikke selv en hjemmeside, så besvar spørgsmålene for eksemplet i denne lektion. Du får derefter modelsvaret.

Læs mere

Trinnene i disse artikler gælder for kontrolpanelerne hos WebOké; hos andre udbydere fungerer det på tilsvarende måde.

• En kontaktformular på din hjemmeside: få felter sendt via mail og undgå spam
• Hvordan får jeg den rigtige afsender med mail() i PHP? SMTP
• Mail kan ikke sendes via PHP, MX-poster peger et andet sted hen
• Grænse for afsendelse af mail
• Daglig e-mailgrænse nået
• DirectAdmin vejledning 8.1: Alle indstillinger samlet: servere, porte og sikkerhed
• DirectAdmin vejledning 5.10: E-mail hos Microsoft 365 eller Google Workspace, hjemmeside hos WebOké