Mejl från din webbplats och formulär

Modul 7: Nyhetsbrev och mejl från din webbplats · Lästid: 11 minuter

Lärandemål: Efter den här lektionen kan du ställa in webbplatsmejl (kontaktformulär, orderbekräftelser, WordPress-meddelanden) så att de levereras, inte skapar DMARC-problem och inte låter ditt paket missbrukas.

Nyckelbegrepp: PHP mail(), SMTP med inloggning, envelope sender (envelope-avsändare), From kontra Reply-To, besökarens adress aldrig som From, SMTP-plugin, transaktionsmejl, formulärspam, captcha, honeypot, sändningsgräns, lokal leverans när MX pekar någon annanstans

Din webbplats är också ett e-postprogram

Din webbplats skickar mer mejl än du tror. Ett kontaktformulär mejlar dig varje meddelande. En webbutik skickar orderbekräftelser, fakturor och leveransbesked. WordPress mejlar vid en ny kommentar, en uppdatering eller en lösenordsåterställning. För mottagaren är det helt enkelt mejl från din domän, och det kontrolleras lika strikt som mejl från din brevlåda: SPF, DKIM, DMARC, rykte.

Ändå går webbplatsmejl fel oftare än vanligt mejl. Det beror oftast på en av tre saker: sättet att skicka på, avsändaradressen eller missbruk av formuläret.

Sätt 1: PHP mail()

Det enklaste sättet för en webbplats att skicka mejl är PHP-funktionen mail(). Webbplatsen lämnar då mejlet direkt till webbserverns e-postprogram, utan att logga in. Det fungerar oftast, men har nackdelar:

• Envelope sender (Return-Path) blir ofta paketets systemkonto, till exempel gebruiker@server.hosting.example, och inte din egen adress. SPF kontrolleras då för serverns domän, och stämmer alltså inte överens med din From-domän (lektion 7.1).
• Om en DKIM-signatur från din domän läggs till beror på servern. På vissa servrar görs det, på andra inte.
• Du ser ingenting. Kommer mejlet inte fram, eller får du en bounce, går den till systemkontot, där ingen tittar.
• Ingen gräns per formulär. Missbrukas formuläret skickar servern i ditt namn tills paketets gräns nås.

Sätt 2: SMTP med inloggning (bättre)

Låt din webbplats skicka på samma sätt som ditt e-postprogram gör: logga in på den utgående mejlservern med en riktig brevlåda, via port 587 (STARTTLS) eller 465 (SSL/TLS), med den fullständiga e-postadressen som användarnamn (lektion 1.4 och 2.1). Då:

• blir envelope sender din egen adress och mejlet signeras precis som vanligt mejl från din domän,
• hamnar bounces i en brevlåda du kan läsa,
• finns det skickade mejlet, om du vill, i mappen Skickat,
• kan du sätta en egen sändningsgräns per brevlåda.

I WordPress gör du det med en SMTP-plugin. Den ersätter WordPress standardfunktion för mejl med sändning via SMTP. Du fyller i samma uppgifter som i ett e-postprogram: server, port, säkerhet, användarnamn och lösenord. Skapa helst en separat brevlåda för detta, till exempel website@example.com. Skulle lösenordet någonsin stjälas är din egen brevlåda säker, och du ser direkt vilket mejl som kommer från webbplatsen.

För en egen PHP-sajt finns bibliotek som skickar via SMTP, till exempel PHPMailer. Lägg lösenordet i en konfigurationsfil utanför webbmappen, inte i koden för en sida.

Hos WebOké hittar du SMTP-uppgifterna i DirectAdmin-guide 8.1, med ditt pakets servernamn; hos andra leverantörer står de i guiden eller välkomstmejlet, och det fungerar på samma sätt.

Mycket transaktionsmejl? Använd en tjänst

Skickar du hundratals orderbekräftelser om dagen lönar sig en transaktionstjänst: en sändningstjänst för automatiska mejl. Den har gott rykte och visar vad som hände med varje mejl. Du kopplar domänen på samma sätt som för en nyhetsbrevstjänst (DKIM via CNAME, lektion 7.1). Håll transaktionsmejl och nyhetsbrev åtskilda: en misslyckad kampanj ska inte påverka bekräftelsemejlet för dina beställningar.

Den gyllene regeln: besökarens adress är aldrig avsändaren

I ett kontaktformulär är det lockande att låta mejlet skickas "från" besökaren. Då kan du klicka direkt på Svara i ditt e-postprogram. Det ser ut så här:

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

Men din server får inte alls skicka mejl i example.nets namn. Anta att example.net har DMARC-policyn p=reject. Den mottagande servern (din egen, eller Gmails om du vidarebefordrar mejl) ser ett mejl med From example.net som inte kommer från example.nets SPF eller DKIM, och nekar det. Många stora e-postdomäner har en strikt policy: en kontroll den 8 november 2026 visade att bland annat yahoo.com, aol.com, ziggo.nl och kpnmail.nl hade DMARC-policyn p=reject, och icloud.com, gmx.de och web.de hade p=quarantine. En besökare med en sådan adress fyller i ditt formulär, och du får aldrig meddelandet, eller det hamnar i din skräppost. Domäner med p=none (som vid det tillfället gmail.com och hotmail.com) kan skärpa sin policy när som helst, och Google skriver uttryckligen i sina riktlinjer att du inte får imitera Gmail-adresser som From. Räkna alltså aldrig med att det går bra.

Det korrekta sättet:

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

Avsändaren är din egen adress, så SPF, DKIM och DMARC stämmer. Besökarens adress står i Reply-To. Klickar du på Svara går ditt svar till Pieter. I de flesta formulärplugin hittar du detta under mejlinställningarna: ange under Avsändare (From) en fast adress från din egen domän, och under Reply-To fältet där besökaren fyller i sin adress.

Skydda formulär mot missbruk

Ett formulär utan skydd hittas förr eller senare av bottar. I bästa fall får du skräppost. I värsta fall missbrukas det för att skicka skräppost till andra: om ditt formulär skickar en bekräftelse till "adressen som besökaren fyller i", kan en bott fylla i vilken adress som helst i världen där, med egen text i meddelandet. Då skickar din domän skräppost, med alla konsekvenser för ditt rykte (lektion 5.2).

Skydd i lager:

• Captcha eller en osynlig kontroll (som reCAPTCHA eller Turnstile) stoppar de flesta bottar.
• Honeypot: ett dolt fält som människor inte ser men bottar fyller i. Ifyllt? Då skickas inte meddelandet.
• Ingen fri text i en bekräftelse till besökaren, eller ingen bekräftelse alls till den angivna adressen. Ett enkelt meddelande "Tack, vi har tagit emot ditt meddelande" på sidan räcker.
• En sändningsgräns per brevlåda för webbplatsens brevlåda, lägre än paketets.
• Uppdatera mjukvaran. Gamla plugin är en känd väg in för missbruk.

Märker du att ditt paket plötsligt skickar mycket mejl, eller får du ett meddelande om att dagsgränsen är nådd trots att du själv mejlar lite? Byt då genast lösenorden och undersök vilket formulär eller skript som skickar mejlet (lektion 3.4).

Mejlet finns någon annanstans, webbplatsen här

En vanlig fälla: din webbplats finns hos en leverantör, ditt mejl hos en annan (till exempel Microsoft 365 eller Google Workspace). Din MX pekar mot den andra leverantören. Men webbservern tror fortfarande att den själv hanterar mejlet för din domän, eftersom domänen också finns på dess eget paket. Mejl från formuläret till info@example.com levererar den då lokalt, till en brevlåda på webbservern som ingen tittar i, eller så ger den ett fel som 550 ... mailbox unavailable.

Lösningen är att i webbserverns panel ange att mejlet hanteras någon annanstans. I DirectAdmin hos WebOké är det kryssrutan "Använd denna server för att hantera min e-post" under MX-poster (stäng av den). Andra paneler har liknande inställningar, som "e-postroutning: extern" i cPanel. Ännu bättre: låt webbplatsen skicka via SMTP med en brevlåda hos leverantören där ditt mejl faktiskt finns.

Sammanfattning

• Webbplatsmejl kontrolleras lika strikt som vanligt mejl. Låt webbplatsen skicka via SMTP med inloggning, inte via mail().
• Använd en separat brevlåda för webbplatsen, med en egen sändningsgräns.
• Besökarens adress hör hemma i Reply-To, aldrig i From. Annars misslyckas DMARC, och hos domäner med p=reject (som yahoo.com, ziggo.nl, kpnmail.nl) nekas mejlet.
• Skydda formulär med captcha, honeypot och utan fria bekräftelser till angivna adresser.
• Finns ditt mejl hos en annan leverantör, stäng av lokal leverans på webbservern eller skicka via SMTP hos den leverantören.

Quiz

Uppgift

Uppgift O7.3: Gå igenom webbplatsmejl. Fyll i ett formulär på din egen webbplats med en Gmail- eller Outlook.com-adress som avsändare och granska rubrikraderna för meddelandet som kommer in till dig. Besvara checklistan: vilken adress står i From, står besökarens adress i Reply-To, vad säger spf=, dkim= och dmarc= under Authentication-Results, skickar din webbplats via SMTP eller via mail(), och har formuläret en captcha eller honeypot? Har du ingen egen webbplats, besvara frågorna utifrån exemplet i den här lektionen. Du får sedan modellsvaret.

Läs mer

Stegen i dessa artiklar gäller för panelerna hos WebOké; hos andra leverantörer fungerar det på liknande sätt.

• Ett kontaktformulär på din webbplats: skicka fält via e-post och förhindra spam
• Hur får jag rätt avsändare med mail() i PHP? SMTP
• Det går inte att skicka e-post via PHP, MX-posterna pekar till en annan leverantör
• Gräns för att skicka e-post
• Daglig e-postgräns nådd
• DirectAdmin-guide 8.1: Alla inställningar på ett ställe: servrar, portar och säkerhet
• DirectAdmin-guide 5.10: E-post hos Microsoft 365 eller Google Workspace, webbplats hos WebOké