E-post fra nettstedet ditt og skjemaer

Modul 7: Nyhetsbrev og e-post fra nettstedet ditt · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kan du sette opp e-post fra nettstedet (kontaktskjemaer, bestillingsbekreftelser, WordPress-varsler) slik at den kommer frem, ikke skaper DMARC-problemer og ikke lar pakken din bli misbrukt.

Nøkkelbegreper: PHP mail(), SMTP med innlogging, envelope sender, From vs. Reply-To, besøkendes adresse aldri som From, SMTP-programtillegg, transaksjonell e-post, skjemaspam, captcha, honeypot, utsendingsgrense, lokal levering når MX ligger et annet sted

Nettstedet ditt er også et e-postprogram

Nettstedet ditt sender mer e-post enn du tror. Et kontaktskjema sender deg en e-post for hver melding. En nettbutikk sender bestillingsbekreftelser, fakturaer og forsendelsesmeldinger. WordPress sender e-post ved en ny kommentar, en oppdatering eller en tilbakestilling av passord. For mottakeren er dette vanlig e-post fra domenet ditt, og den kontrolleres like strengt som e-post fra postboksen din: SPF, DKIM, DMARC, omdømme.

Likevel går e-post fra nettsteder oftere galt enn vanlig e-post. Det skyldes som regel en av tre ting: måten den sendes på, avsenderadressen, eller misbruk av skjemaet.

Metode 1: PHP mail()

Den enkleste måten for et nettsted å sende e-post på, er PHP-funksjonen mail(). Nettstedet gir da e-posten direkte til e-postprogrammet på webserveren, uten innlogging. Det fungerer som regel, men har ulemper:

• Envelope sender (Return-Path) blir ofte systemkontoen til pakken din, som gebruiker@server.hosting.example, og ikke din egen adresse. SPF kontrolleres da for domenet til serveren, og er altså ikke justert med From-domenet ditt (leksjon 7.1).
• Om det legges på en DKIM-signatur fra ditt domene, avhenger av serveren. På noen servere skjer det, på andre ikke.
• Du ser ingenting tilbake. Kommer ikke e-posten frem, eller får du en bounce, går den til systemkontoen, som ingen sjekker.
• Ingen grense per skjema. Blir skjemaet misbrukt, sender serveren i ditt navn helt til grensen for pakken din er nådd.

Metode 2: SMTP med innlogging (bedre)

La nettstedet sende e-post på samme måte som e-postprogrammet ditt gjør: logg inn på den utgående mailserveren med en ekte postboks, via port 587 (STARTTLS) eller 465 (SSL/TLS), med hele e-postadressen som brukernavn (leksjon 1.4 og 2.1). Da:

• blir envelope sender din egen adresse, og e-posten signeres som vanlig e-post fra domenet ditt;
• havner bounces i en postboks du kan lese;
• står den sendte e-posten, hvis du vil, i mappen Sent;
• kan du sette en egen utsendingsgrense per postboks.

I WordPress gjør du dette med et SMTP-programtillegg. Det erstatter standardfunksjonen for e-post i WordPress med sending via SMTP. Du fyller inn de samme opplysningene som i et e-postprogram: server, port, sikkerhet, brukernavn og passord. Opprett helst en egen postboks til dette, for eksempel website@example.com. Blir passordet noen gang stjålet, er din egen postboks trygg, og du ser med ett blikk hvilken e-post som kommer fra nettstedet.

For et eget PHP-nettsted finnes det biblioteker som sender via SMTP, som PHPMailer. Legg passordet i en konfigurasjonsfil utenfor web-mappen, ikke i koden til en side.

Hos WebOké finner du opplysningene for SMTP i DirectAdmin-veiledning 8.1, med servernavnet til pakken din; hos andre leverandører står de i veiledningen eller velkomst-e-posten, og det fungerer på samme måte.

Mye transaksjonell e-post? Bruk en tjeneste

Sender du hundrevis av bestillingsbekreftelser per dag, lønner det seg med en transaksjonstjeneste: en utsendingstjeneste for automatisk e-post. Den har godt omdømme og viser deg hva som skjedde med hver melding. Du kobler domenet på samme måte som hos en nyhetsbrevtjeneste (DKIM via CNAME, leksjon 7.1). Hold transaksjonell e-post og nyhetsbrev atskilt: en mislykket kampanje skal ikke kunne påvirke bekreftelsesmeldingen for bestillingene dine.

Gullregelen: besøkendes adresse er aldri avsenderen

Ved et kontaktskjema er det fristende å la e-posten sendes "fra" den besøkende. Da kan du klikke rett på Svar i e-postprogrammet ditt. Det ser slik ut:

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

Men serveren din har ikke lov til å sende e-post på vegne av example.net. Si at example.net har en DMARC-policy p=reject. Den mottakende serveren (din egen, eller Gmails hvis du videresender e-post) ser en melding med From example.net som ikke kommer gjennom SPF eller DKIM fra example.net, og avviser den. Mange store maildomener har en streng policy: ved en kontroll 8. november 2026 hadde blant andre yahoo.com, aol.com, ziggo.nl og kpnmail.nl DMARC-policyen p=reject, og icloud.com, gmx.de og web.de hadde p=quarantine. En besøkende med en slik adresse fyller ut skjemaet ditt, og du får aldri meldingen, eller den havner i spam-mappen. Domener med p=none (som på det tidspunktet gmail.com og hotmail.com) kan skjerpe policyen sin når som helst, og Google skriver uttrykkelig i retningslinjene sine at du ikke har lov til å etterligne Gmail-adresser som From. Regn derfor aldri med at det går bra.

Den riktige måten:

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

Avsenderen er din egen adresse, så SPF, DKIM og DMARC stemmer. Adressen til den besøkende står i Reply-To. Klikker du på Svar, går svaret ditt til Pieter. I de fleste skjema-programtillegg finner du dette under e-postinnstillingene: sett en fast adresse fra ditt eget domene som Avsender (From), og legg feltet der den besøkende fyller inn sin adresse, under Reply-To.

Beskytt skjemaer mot misbruk

Et skjema uten beskyttelse blir før eller siden funnet av roboter. I beste fall får du spam. I verste fall misbruker de det til å sende spam til andre: hvis skjemaet ditt sender en bekreftelse til "adressen den besøkende fyller inn", kan en robot fylle inn en hvilken som helst adresse i verden der, med egen tekst i meldingen. Da sender domenet ditt spam, med alle konsekvenser for omdømmet ditt (leksjon 5.2).

Beskyttelse i lag:

• Captcha eller en usynlig kontroll (som reCAPTCHA eller Turnstile) stopper de fleste roboter.
• Honeypot: et skjult felt som mennesker ikke ser, men roboter fyller ut. Er det fylt ut? Da sendes ikke meldingen.
• Ingen fri tekst i en bekreftelse til den besøkende, eller ingen bekreftelse i det hele tatt til den oppgitte adressen. En enkel melding "Takk, vi har mottatt meldingen din" på siden er nok.
• En utsendingsgrense per postboks for nettstedets postboks, lavere enn grensen for pakken din.
• Oppdater programvaren. Gamle programtillegg er en kjent inngang for misbruk.

Merker du at pakken din plutselig sender mye e-post, eller får du et varsel om at daggrensen er nådd mens du selv sender lite e-post? Endre da passordene umiddelbart og finn ut hvilket skjema eller skript som sender e-posten (leksjon 3.4).

E-post ett sted, nettsted et annet

En vanlig fallgruve: nettstedet ditt ligger hos én leverandør, e-posten din hos en annen (for eksempel Microsoft 365 eller Google Workspace). MX-en din peker til den andre leverandøren. Men webserveren tror fortsatt at den selv håndterer e-posten for domenet ditt, fordi domenet også ligger på dens egen pakke. E-post fra skjemaet til info@example.com leverer den da lokalt, i en postboks på webserveren som ingen sjekker, eller den gir en feil som 550 ... mailbox unavailable.

Løsningen er å angi i webserverens kontrollpanel at e-posten håndteres et annet sted. I DirectAdmin hos WebOké er dette avkrysningsboksen "Bruk denne serveren til å håndtere e-postene mine" under MX Records (slå av). Andre kontrollpaneler har lignende innstillinger, som "e-postruting: ekstern" i cPanel. Enda bedre: la nettstedet sende via SMTP med en postboks hos leverandøren der e-posten din egentlig ligger.

Oppsummering

• E-post fra nettsteder kontrolleres like strengt som vanlig e-post. La nettstedet sende via SMTP med innlogging, ikke via mail().
• Bruk en egen postboks for nettstedet, med en egen utsendingsgrense.
• Adressen til den besøkende hører hjemme i Reply-To, aldri i From. Ellers feiler DMARC, og hos domener med p=reject (som yahoo.com, ziggo.nl, kpnmail.nl) blir e-posten avvist.
• Beskytt skjemaer med captcha, honeypot og uten fri tekst i bekreftelser til oppgitte adresser.
• Ligger e-posten din hos en annen leverandør, slå av lokal levering på webserveren eller send via SMTP hos den leverandøren.

Quiz

Oppgave

Oppgave O7.3: Gå gjennom nettstedets e post. Fyll ut et skjema på ditt eget nettsted med en Gmail- eller Outlook.com-adresse som avsender, og se på headerne til meldingen som kommer frem til deg. Besvar sjekklisten: hvilken adresse står i From, står adressen til den besøkende i Reply-To, hva sier spf=, dkim= og dmarc= under Authentication-Results, sender nettstedet ditt via SMTP eller via mail(), og har skjemaet en captcha eller honeypot? Har du ikke noe eget nettsted, besvar da spørsmålene for eksempelet i denne leksjonen. Du får deretter modellsvaret.

Les mer

Trinnene i disse artiklene gjelder for kontrollpanelene til WebOké; hos andre leverandører fungerer det på samme måte.

• Et kontaktskjema på nettsiden din: send inn felt på e-post og unngå spam
• Hvordan får jeg riktig avsender med mail() i PHP? SMTP
• Sending av e-post via PHP virker ikke, MX-postene peker et annet sted
• Grense for utsending av e-post
• Daglig grense for e-post er nådd
• DirectAdmin-veiledning 8.1: Alle innstillinger på én plass: servere, porter og sikkerhet
• DirectAdmin-veiledning 5.10: E-post hos Microsoft 365 eller Google Workspace, nettsted hos WebOké