SMTP

SMTP er den protokol, der bruges til at indsende og overføre udgående e-mail. Forkortelsen står for Simple Mail Transfer Protocol. Når et mailprogram eller en hjemmeside sender en besked, bruges SMTP typisk til at aflevere den til en mailserver, som fører den videre.

SMTP handler om afsendelse og transport, ikke om at læse indbakken. Modtagelse i en mailklient bruger normalt andre protokoller eller en webtjeneste. Det er også forskelligt fra et MX-record, som fortæller afsenderen, hvilke servere der modtager mail for domænet.

På en WordPress-hjemmeside bliver kontaktformularer ofte sendt gennem PHP’s lokale mailfunktion som standard. Det kan virke, men afsenderidentitet, logning og leveringssikkerhed er ofte bedre, når siden bruger en rigtig SMTP- eller transaktionel mailtjeneste.

SMTP-serveren kræver normalt et servernavn, en port, en krypteringsmetode og login. Almindelige porte er 587 til message submission med STARTTLS og 465 til implicit TLS. Den rigtige opsætning kommer fra mailudbyderen; man bør ikke prøve tilfældige kombinationer i produktion.

SMTP garanterer ikke, at modtageren læser mailen eller at den lander i indbakken. Protokollen kan bekræfte, at en server har accepteret beskeden, men spamfiltre, politikker, modtagerfejl og senere videresendelse kan stadig påvirke leveringen.

Vælg først den rette afsendelsestjeneste. En almindelig virksomhedskonto kan være nok til få formularer, mens en webshop med ordrebekræftelser og mange mails bør bruge en transaktionel tjeneste med log, kapacitet og domænegodkendelse.

Opsæt servernavn, port og kryptering præcis efter leverandørens vejledning. Brug ikke port 25 fra hjemmesiden, medmindre infrastrukturen specifikt kræver det. Port 587 er normalt beregnet til autentificeret indsendelse, mens port 465 bruges af mange tjenester med kryptering fra forbindelsens start.

Brug en afsenderadresse på et domæne, virksomheden kontrollerer. En formular på firma.dk bør ikke forsøge at sende som den besøgendes Gmail-adresse. Sæt i stedet virksomhedens adresse som From og brugerens adresse som Reply-To. Det passer bedre med SPF og DKIM.

Tilføj og kontrollér DNS-poster for SPF, DKIM og DMARC hos domænets nameserver-udbyder. De fortæller modtagere, hvilke systemer der må sende for domænet, og hvordan uautoriserede beskeder skal håndteres. SMTP-login alene er ikke hele afsendergodkendelsen.

Aktivér logning af formularafsendelser uden at gemme følsomme data længere end nødvendigt. Loggen bør vise tidspunkt, formular, modtager, status og eventuel fejl. Så kan virksomheden skelne mellem “formularen blev aldrig udløst”, “SMTP afviste login” og “modtageren afviste mailen”.

Test både succes og fejl. Send til forskellige eksterne udbydere, kontrollér spammapper og svarfunktionen, og afprøv hvad der sker, hvis SMTP-tjenesten er utilgængelig. En vigtig formular bør vise en ærlig fejl eller have kø, ikke bare en falsk takkeside.

En håndværkervirksomhed modtager normalt 30 tilbudsforespørgsler om måneden. Efter en opdatering falder tallet pludseligt til 8. Hjemmesiden viser stadig “Tak for din besked”, og derfor antager ejeren, at markedet er blevet stille.

En test viser, at webhotellets lokale mailfunktion afviser beskeder med kundens e-mail som afsender. Formularen registrerer stadig succes, fordi pluginet kun har afleveret beskeden til den lokale funktion. Der findes ingen log over den efterfølgende afvisning.

Hjemmesiden kobles til en autentificeret SMTP-tjeneste. From-adressen bliver formular@firma.dk, mens kundens adresse bruges som Reply-To. SPF og DKIM opdateres, og pluginet gemmer leveringsstatus. De manglende henvendelser kan ikke genskabes, men nye beskeder bliver nu dokumenteret.

På en måned sender formularen 34 beskeder. 33 accepteres straks, mens én fejler på grund af et midlertidigt forbindelsesproblem og sendes igen. Virksomheden kan nu se forskellen mellem antal formularer og antal afleverede mails.

En webshop har samme behov i større skala. Ordrebekræftelser, nulstilling af password og gavekort er transaktionelle beskeder, som ikke bør afhænge af en tilfældig lokal mailfunktion uden kø eller log.

Den mest almindelige fejl er at bruge en privat mailkonto og dens password direkte i et plugin uden at tænke på adgang, tofaktorlogin eller ændringer. Brug app-password, OAuth eller en dedikeret tjeneste efter udbyderens anbefaling, og begræns hvem der kan se oplysningerne.

En anden fejl er at sende for mange beskeder gennem en konto med lave grænser. Nyhedsbreve hører normalt til i en nyhedsbrevstjeneste, ikke gennem virksomhedens almindelige SMTP-login. Store udsendelser kan blokere både kampagnen og den daglige mail.

Pas på plugins, der gemmer hele formularindholdet i en mail-log for altid. Logning er nyttig, men kan skabe en ekstra database med personoplysninger. Vælg retention, adgang og indhold bevidst.

Endelig kan en vellykket SMTP-test give falsk tryghed. En test til samme udbyder kan virke, mens eksterne domæner afviser beskeder. Kontrollér flere modtagere og den fulde domænegodkendelse, ikke kun forbindelsen.

SMTP blev oprindeligt designet i en enklere tid, og moderne sikkerhed er bygget på med udvidelser, autentificering og TLS. Derfor kan opsætningen virke mere kompleks end protokollens navn lover. Kompleksiteten beskytter blandt andet mod misbrug og aflytning.

En server kan svare med midlertidige 4xx-fejl eller permanente 5xx-fejl. Midlertidige fejl bør ofte prøves igen, mens permanente fejl kræver rettelse. En god mailtjeneste håndterer kø og viser årsagen i et forståeligt dashboard.

SSL-certifikat på webdomænet og TLS på SMTP-forbindelsen er beslægtede sikkerhedsidéer, men separate opsætninger. At hjemmesiden har hængelås betyder ikke automatisk, at formularmailen er korrekt krypteret og autentificeret.

En webhook kan bruges som alternativ eller supplement til e-mail. En formular kan sende data direkte til et CRM-system og derefter sende en mailnotifikation. Det reducerer risikoen for, at hele leadet kun findes i én besked, men integrationen skal stadig overvåges.

Vores guide til hvad et CMS er forklarer platformens rolle. SMTP ligger et lag under den synlige redigering, men er afgørende, når systemet skal give besked om det, brugeren har gjort.

En formular bør have en sekundær sikkerhed, hvis henvendelser er forretningskritiske. Det kan være lagring i WordPress med begrænset adgang, en CRM-integration eller en kø hos mailtjenesten. E-mailnotifikationen bliver så en besked om leadet, ikke det eneste sted leadet eksisterer.

Rate limits og afsenderomdømme skal respekteres. Hvis et plugin går i loop og sender tusindvis af mails, kan udbyderen blokere kontoen. Begrænsninger, alarmer og kø gør det lettere at stoppe en fejl, før den rammer virksomhedens almindelige kommunikation.

Brug separate afsenderstrømme til marketing og transaktionelle beskeder, når volumen er stor. Et problem med et nyhedsbrev bør ikke forhindre kunder i at modtage ordrebekræftelser eller passwordmails. Nogle tjenester tilbyder separate domæner, subdomæner eller pools til formålet.

Opdater SMTP-credentials kontrolleret. Når en medarbejder stopper eller et password ændres, kan formularerne ellers bryde uden synlig fejl. Brug en dedikeret konto eller API-nøgle, opbevar den sikkert, og notér hvor den bruges, så rotation kan testes.

Kontaktformularens synlige kvittering bør skelne mellem “modtaget af hjemmesiden” og “sendt som e-mail”, hvis systemet gemmer data først og sender senere. Den tekniske arkitektur behøver ikke forklares til brugeren, men beskeden må ikke love en levering, som endnu ikke er bekræftet.

Når en SMTP-tjeneste bruger et separat return-path-domæne, skal DNS-posterne også konfigureres. Det hjælper med bounce-håndtering og domænealignment. Følg udbyderens trin i stedet for kun at indsætte brugernavn og password i WordPress.

Overvåg afvisninger og klager. En transaktionel tjeneste kan lukke eller begrænse afsendelsen, hvis mange adresser er ugyldige eller modtagere markerer mail som spam. Formularer bør validere adresser rimeligt, men uden at afvise lovlige, usædvanlige formater.

Sørg desuden for, at systemmails har en tydelig afsender og svaradresse. “WordPress <wordpress@server123.host>” skaber usikkerhed og kan blive afvist. Brug en adresse, som virksomheden ejer, og som nogen faktisk overvåger, hvis modtageren svarer. Test også de almindelige skabeloner efter ændringer i tema eller webshop, så afsendelsen ikke kun virker i en isoleret SMTP-test.

På en hjemmeside er SMTP ofte den skjulte forbindelse mellem kontaktformularen og indbakken. Den bør behandles som en driftsfunktion, ikke som en detalje, der kun testes ved lanceringen.