SMTP-port 25, 465 eller 587 – hva skal du bruke?

For en vanlig e-postapp er riktig valg normalt port 587 med STARTTLS eller port 465 med TLS fra første byte. Port 25 brukes primært når e-postservere leverer til hverandre, ikke som et tilfeldig alternativ når Outlook eller mobilen ikke får sendt.

Den korte beslutningen er:

Dette er vanlige mønstre, ikke Vymo-spesifikke serverinnstillinger. Bruk alltid servernavnet, porten, TLS-modusen og innloggingsmetoden fra kontoens aktivering eller leverandørens oppdaterte dokumentasjon.

Port 587 er standardisert meldinginnlevering

RFC 6409 reserverer port 587 for innlevering av nye meldinger. E-postappen opptrer som klient mot en Message Submission Agent, MSA, som kontrollerer brukeren og kan håndheve lokale regler før meldingen går inn i det offentlige e-postsystemet.

På port 587 starter forbindelsen med SMTP og oppgraderes til TLS med kommandoen STARTTLS. Et sikkert klientoppsett må kreve at oppgraderingen lykkes og validere serverens sertifikat før legitimasjon eller melding sendes.

Port 587 er ofte førstevalget når leverandøren oppgir:

• kryptering som STARTTLS
• SMTP-autentisering aktivert
• fullt servernavn som matcher sertifikatet
• hele e-postadressen eller en angitt kontoidentitet som brukernavn

«STARTTLS» betyr ikke at det er greit å fortsette i klartekst hvis oppgraderingen feiler. For innlevering skal klienten stoppe i stedet for å sende passordet over en ubeskyttet forbindelse.

Port 465 bruker TLS fra første byte

På port 465 begynner TLS-håndtrykket umiddelbart når TCP-forbindelsen opprettes. SMTP-kommandoene sendes først etter at den krypterte forbindelsen er etablert. Dette kalles implicit TLS eller «submissions».

RFC 8314 registrerer port 465 for Message Submission over TLS. Porten er derfor ikke bare en foreldet levning, slik eldre guider ofte hevder.

Port 465 er riktig når leverandøren oppgir:

• port 465
• implicit TLS, SSL/TLS eller TLS fra start
• SMTP-autentisering
• et bestemt servernavn

Begrepet «SSL» lever videre i mange klientmenyer selv om moderne forbindelser skal bruke TLS. Det avgjørende er kombinasjonen leverandøren støtter og at klienten validerer et moderne TLS-oppsett.

465 mot 587 er ikke en konkurranse i sikkerhet

Begge kan være sikre. Forskjellen er når TLS begynner:

RFC 8314 beskriver ingen vesentlig forskjell i sikkerhetsegenskapene når begge implementasjoner er korrekte, TLS er påkrevd og sertifikatet valideres. Velg den kombinasjonen leverandøren faktisk tilbyr for kontoen.

Ikke sett port 465 sammen med STARTTLS bare fordi begge ordene ser sikre ut. Ikke sett port 587 til implicit TLS dersom leverandøren sier STARTTLS. Feil modus gir ofte umiddelbar håndtrykksfeil eller tidsavbrudd.

Port 25 brukes til servertransport

Når en avsenderserver skal levere til mottakerdomenet, slår den opp domenets MX-poster og kobler normalt til MX-serveren på port 25. Det er denne rollen den grunnleggende SMTP-transporten i RFC 5321 beskriver.

Server-til-server-transport skiller seg fra en ansatts e-postapp:

• den bruker MX og DNS-ruting
• den har ikke normalt en sluttbruker som logger inn med postkassepassord
• den må håndtere kø og nye forsøk ved midlertidige feil
• den vurderes på IP-omdømme, DNS, autentisering og mottakerpolicy
• transport-TLS forhandles mellom systemene

Port 25 kan teknisk brukes til innlevering i enkelte avtalte miljøer, men det gjør den ikke til riktig standardvalg i en vanlig app. Mange internettleverandører og skyplattformer begrenser utgående port 25 for å redusere spam og misbruk.

Hvis port 25 er blokkert på en bærbar PC, skal løsningen normalt være korrekt autentisert innlevering på 587 eller 465. Ikke be nettverket åpne direkte servertransport bare for å omgå feil klientinnstillinger.

Hva med port 2525?

Noen e-post- og utsendingsleverandører tilbyr port 2525 som et leverandørspesifikt alternativ når standardporter er blokkert. Den er ikke den standardiserte porten for meldinginnlevering på samme måte som 587.

Bruk 2525 bare når deres leverandør uttrykkelig dokumenterer:

• riktig servernavn
• om TLS er implicit eller oppgraderes
• at TLS er påkrevd
• hvilken autentisering som skal brukes
• at tjenesten og kontoen deres støtter porten

Ikke gjett at alle SMTP-servere lytter på 2525.

Velg etter systemet som sender

Outlook, Apple Mail og mobil

Bruk automatisk leverandørinnlogging når den finnes. Ved manuelt oppsett bruker dere normalt 587 med STARTTLS eller 465 med implicit TLS. Ikke kopier MX-serveren som SMTP-server; MX beskriver hvor andre servere leverer innkommende e-post.

Den praktiske oppsettsguiden for Outlook, Apple Mail og iPhone viser hvilke kontofelt som skal samles inn før endringer.

Nettsted, kontaktskjema og nettbutikk

Et nettsted bør sende gjennom en autorisert meldingstjeneste eller leverandørens dokumenterte relay, ikke åpne en anonym SMTP-tjeneste. Avklar:

• om autentisering skjer med egen konto, token eller annen mekanisme
• hvilken Fra-adresse tjenesten får bruke
• om svaradresse skal settes separat
• hvilken SPF- og DKIM-identitet tjenesten bruker
• volumgrenser, returhåndtering og logging

Bruk ikke en ansatts hovedpassord i et nettsted dersom leverandøren tilbyr en avgrenset systemidentitet. Hemmeligheter skal ligge i sikker konfigurasjon, ikke i kildekode.

Skriver, skanner og eldre fagsystem

Eldre utstyr støtter kanskje ikke moderne TLS eller autentisering. Ikke slå av kryptering på hele e-postkontoen for å holde én enhet i live. Bedre alternativer kan være:

• en oppdatert firmware og støttet TLS-modus
• en avgrenset relay-tjeneste på internt nett
• en egen systemidentitet med minst mulig rettighet
• utskifting av utstyr som ikke kan beskyttes

Dokumenter hva enheten sender, hvilke mottakere den trenger og hvem som eier løsningen.

Egen e-postserver

Direkte levering på port 25 er drift av e-postinfrastruktur, ikke bare valg av en port. Serveren trenger blant annet stabil offentlig identitet, fremover- og reverse DNS, køhåndtering, TLS, misbruksvern, omdømmeoppfølging og korrekt SPF, DKIM og DMARC.

For en liten bedrift er autentisert relay hos en etablert leverandør ofte enklere å drifte enn direkte levering fra en tilfeldig skyserver.

Servernavn og sertifikat må passe sammen

Porten kan være riktig mens servernavnet er feil. TLS-klienten skal kontrollere at sertifikatet er gyldig for navnet den kobler til.

Bruk for eksempel leverandørens dokumenterte smtp.leverandor.example, ikke:

• en rå IP-adresse
• et MX-navn dere gjettet
• et gammelt serveralias som peker videre
• bedriftens eget domene hvis sertifikatet gjelder et annet navn

Godta ikke sertifikatadvarselen permanent. Den beskytter mot feilkobling og mellommannsangrep.

Diagnostiser feilen før du bytter port

Ikke prøv 25, 465, 587 og 2525 i tilfeldig rekkefølge med samme innstilling. En tilfeldigvis åpen port kan tilhøre en annen protokollmodus, og gjentatte innloggingsforsøk kan sperre kontoen.

Test nettverk og TLS uten å dele passord

En enkel tilkoblingstest kan vise om nettverket når serveren:

nc -vz smtp.leverandor.example 587

Den beviser ikke at STARTTLS, sertifikat eller innlogging fungerer. For å inspisere TLS-forhandlingen på 587 kan en tekniker bruke:

openssl s_client -starttls smtp -connect smtp.leverandor.example:587 -servername smtp.leverandor.example

For implicit TLS på 465:

openssl s_client -connect smtp.leverandor.example:465 -servername smtp.leverandor.example

Eksempelnavnet må erstattes med leverandørens dokumenterte server. Ikke skriv AUTH, brukernavn eller passord i en delt terminalutskrift. En vellykket TLS-test beviser heller ikke at kontoen har lov til å sende.

Test gjerne samme konto i leverandørens webmail og på et annet nettverk:

• Webmail virker, appen feiler: undersøk klientinnstillinger og innlogging.
• Appen virker på mobilnett, ikke kontornett: undersøk brannmur, proxy eller TLS-inspeksjon.
• Ingen klienter virker: undersøk konto og leverandørstatus.
• Innlevering virker, men meldingen returneres: gå videre til servertransport og returkode.

Portvalg påvirker ikke DMARC-alignment

Å bytte fra 465 til 587 kan rette en protokollmismatch. Det reparerer ikke SPF, DKIM, DMARC, omdømme eller listekvalitet.

Når innleveringsserveren har akseptert meldingen, avgjør dens utgående infrastruktur hvilke IP-er, returdomener og DKIM-signaturer mottakeren ser. Kontroller en reell melding etter oppsettet. Se hvordan SMTP transporterer meldingen og hvordan SPF, DKIM og DMARC vurderes .

Et trygt valg i praksis

1. Finn leverandørens dokumenterte SMTP-server for den konkrete kontotypen.
2. Velg nøyaktig kombinasjon av port og TLS-modus.
3. Krev TLS og behold sertifikatkontroll.
4. Bruk støttet autentisering og korrekt kontoidentitet.
5. Test med én liten melding til en ekstern adresse.
6. Bevar feilmelding, tidspunkt og Message-ID.
7. Kontroller meldingshodet når leveringen lykkes.

Hvis e-posten fortsatt stopper, bruk feilsøkingsguiden for e-post som ikke sendes i stedet for å endre flere porter.

Vymos kontoaktivering er fasiten for Vymos egne serververdier. Har dere mistet opplysningene, kontakt kundeservice med domenenavn og kontoens e-postadresse, men aldri passord eller gjenopprettingskoder. Nye bedrifter kan se e-postpakker og priser .