Hva er SMTP, og hvordan sendes e-post?

SMTP er protokollen som brukes til å levere en ny e-post fra appen din til e-postsystemet og til å transportere meldingen mellom servere. Når du trykker Send, går meldingen derfor gjennom flere separate ledd før mottakeren kan lese den.

Det viktigste skillet er mellom innlevering og transport:

• E-postappen leverer meldingen til din leverandørs innleveringsserver med autentisering.
• Leverandørens e-postserver finner mottakerens system og forsøker å levere meldingen dit.
• Mottakersystemet godtar, avviser eller utsetter forsøket, og kan deretter filtrere meldingen.

En melding i mappen Sendt beviser bare at appen har behandlet den som sendt. Det er ikke det samme som at mottakerserveren har godtatt den, at den ligger i innboksen eller at noen har lest den.

SMTP betyr Simple Mail Transfer Protocol

SMTP er en tekstbasert protokoll der en klient og en server utveksler kommandoer og svar. Den grunnleggende transportstandarden er RFC 5321 , mens RFC 6409 skiller brukerens meldinginnlevering fra servertransport.

Rollene har egne navn:

I en moderne skytjeneste kan flere roller ligge i samme plattform. Skillet er likevel nyttig når en feil skal lokaliseres.

E-postens vei i åtte ledd

1. Appen bygger meldingen

E-postappen lager overskrifter som synlig Fra, Til, Emne, Dato og Message-ID, og koder tekst, HTML og vedlegg med MIME. Dette er selve meldingen mottakeren senere kan se.

Appen trenger i tillegg servernavn, port, TLS-modus og en støttet innloggingsmetode for å levere meldingen til leverandøren. Ved moderne kontoer håndteres dette ofte gjennom leverandørinnlogging. Ved manuelt oppsett må verdiene komme fra leverandørens dokumentasjon eller aktivering.

2. Appen oppretter en beskyttet forbindelse

For vanlig meldinginnlevering brukes normalt port 587 med STARTTLS eller port 465 med TLS fra første byte. Begge kan være sikre når server og klient krever TLS og validerer sertifikatet korrekt.

Ikke løs en sertifikatfeil ved å slå av kryptering eller sertifikatkontroll. Feilen kan bety at servernavnet er galt, en mellomliggende nettverksløsning endrer forbindelsen, eller at serverens sertifikat faktisk er feil.

Den egne guiden sammenligner SMTP-port 25, 465 og 587 .

3. Innleveringsserveren autentiserer avsenderen

Innleveringsserveren må vite hvilken bruker eller tjeneste som leverer meldingen. Den kan også kontrollere hvilke Fra-adresser kontoen har lov til å bruke. Et gyldig passord gir ikke nødvendigvis rett til å sende som en tilfeldig kollega eller et ubekreftet alias.

Typiske avvisninger i dette leddet handler om:

• feil brukernavn, passord eller token
• blokkert konto eller for mange mislykkede forsøk
• deaktivert SMTP-autentisering
• innloggingsmetode klienten ikke støtter
• Fra-adresse kontoen ikke har send-som-rettighet til
• meldingsstørrelse eller lokal policy

Et åpent relay som lar hvem som helst sende videre uten autorisasjon, er ikke en praktisk snarvei. Det blir raskt misbrukt til spam og skader serverens omdømme.

4. Serveren tar ansvar eller svarer med feil

En forenklet SMTP-dialog kan inneholde:

EHLO klient.example
MAIL FROM:<retur@dittfirma.no>
RCPT TO:<mottaker@example.net>
DATA

I praksis kommer TLS, autentisering og flere utvidelser i tillegg. Serveren svarer etter kommandoene med tresifrede statuskoder.

Når innleveringsserveren avslutter mottaket med et vellykket svar, har den normalt akseptert ansvar for videre behandling. Hvis appen mister forbindelsen akkurat rundt sluttkvitteringen, kan status bli uklar: serveren kan ha mottatt meldingen selv om appen ikke så svaret. Derfor kan blind gjentakelse skape duplikater.

5. Avsenderserveren finner mottakerens MX

For adressen navn@example.net spør avsendersystemet DNS etter MX-poster for example.net. MX-postene oppgir hvilke servernavn som tar imot e-post og deres prioritet.

MX forteller ikke hvilken server e-postappen din skal bruke til utgående innlevering. Det er en vanlig feil å kopiere mottaksserveren inn i SMTP-feltet i appen. Bruk leverandørens innleveringsinnstillinger.

Hvis flere MX-poster finnes, forsøker systemet normalt etter prioritet og tilgjengelighet. En lavere prioritert server skal være en reell del av leverandørens mottaksoppsett, ikke en gammel konto som tilfeldigvis fortsatt svarer.

Les mer om MX-prioritet, mottak og trygg endring .

6. Serverne forhandler om levering

Avsenderens MTA kobler seg normalt til mottakerens MTA på port 25. Mottakeren annonserer funksjonene den støtter etter EHLO, og partene kan blant annet forhandle om TLS og maksimal meldingsstørrelse.

Transport-TLS beskytter forbindelsen mellom to servere på det aktuelle hoppet. Det er ikke ende-til-ende-kryptering av innholdet. Meldingen kan passere flere systemer, og autoriserte servere må kunne behandle den.

Mottakeren kan kontrollere:

• om mottakeradressen finnes eller kan rutes
• størrelse og meldingsformat
• sendende IP, DNS og omdømme
• SPF, DKIM og DMARC
• spam-, skadevare- og innholdsregler
• lokal hastighets- og sikkerhetspolicy

Autentisering avgjør ikke innboksplassering alene. En legitim, autentisert melding kan fortsatt filtreres på grunn av klager, listekvalitet, skadevare eller andre signaler.

7. Midlertidige feil går i kø

SMTP skiller mellom midlertidige og permanente svar:

Et 4xx-svar kan skyldes midlertidig kapasitet, grålisting, DNS-problemer eller lokal policy. Hvor lenge og hvor ofte avsendersystemet prøver, bestemmes av systemets køregler innenfor SMTP-prinsippene.

Et 5xx-svar kan bety ugyldig mottaker, manglende autorisasjon, innholdspolicy eller permanent rutefeil. Tallet alene er ikke nok. Bevar hele svaret, inkludert forbedret kode som 5.1.1 og serverens tekst.

Guiden til SMTP- og statuskoder i returmeldinger viser hvordan feilen klassifiseres uten å gjette.

8. Mottakersystemet leverer eller filtrerer

Når mottakerserveren har godtatt meldingen, kan den legge den i en postkasse, en karantene, en regelmotor eller en annen intern rute. Et vellykket 250-svar fra mottakeren betyr at den har tatt ansvar i det SMTP-steget. Det er ikke en lesebekreftelse og lover ikke plassering i hovedinnboksen.

Mottakeren kan ha aliaser, distribusjonsgrupper, videresending og filterregler som flytter meldingen videre. Feilsøking etter aksept krever derfor sporingsdata hos mottakersystemet, ikke nye SMTP-innstillinger på avsenderens telefon.

Konvolutten er ikke det samme som meldingen

SMTP bruker en teknisk konvolutt rundt meldingen:

Konvoluttmottakere trenger ikke være identiske med To-feltet. Blindkopimottakere står for eksempel i SMTP-konvolutten, men skal ikke avsløres i det synlige meldingshodet.

Konvoluttavsenderen kan være en teknisk bounce-adresse hos en leverandør. SPF kontrollerer normalt domenet i denne returidentiteten. DMARC vurderer deretter om et bestått SPF- eller DKIM-domene er alignet med domenet i synlig From.

Det er derfor mulig å se spf=pass for et leverandørdomene og samtidig dmarc=fail for bedriftens synlige domene. Den komplette guiden forklarer SPF, DKIM, DMARC og alignment .

SMTP sender; IMAP og POP gir tilgang

SMTP brukes til utgående innlevering og servertransport. Det brukes ikke som hovedprotokoll for å synkronisere innboksen til telefonen.

• IMAP lar klienten arbeide mot mapper og meldinger på serveren.
• POP3 henter meldinger etter en enklere modell og kan gi mer lokal lagring.
• Webmail viser postkassen gjennom en nettapplikasjon, men bruker fortsatt leverandørens e-postsystem bak.

En konto kan derfor motta e-post via IMAP selv om SMTP-innleveringen feiler, eller sende via SMTP mens innbokssynkronisering er satt opp feil. Skill retningene under feilsøking. Se IMAP mot POP3 for lagring og synkronisering.

TLS beskytter transporten, ikke hele sannheten

TLS kan beskytte legitimasjon og meldingsdata mot enkel avlytting på forbindelsen. Ved klientinnlevering skal kryptering kreves og sertifikatet valideres. RFC 8314 regner klarteksttilgang som foreldet.

Mellom e-postservere har TLS historisk ofte vært opportunistisk: partene bruker det når det tilbys, men vanlig SMTP-ruting må også håndtere servere og feil som ikke passer et strengt krav. Mekanismer som MTA-STS og DANE kan gi en domenestyrt transportpolicy i bestemte oppsett. Bruk MTA-STS- og TLS-RPT-guiden før håndheving.

TLS sier ikke at avsenderen er ærlig, at vedlegget er ufarlig eller at kontoen ikke er kompromittert. Autentisering, innholdsfiltrering og menneskelige kontrollrutiner trengs fortsatt.

Finn hvilket SMTP-ledd som feiler

Ikke endre MX, SPF eller DMARC fordi appen avviser passordet. Ikke endre passord fordi én ekstern mottaker gir en tydelig policyfeil. Beviset må passe til leddet dere endrer.

Den detaljerte feilsøkingsguiden viser hva dere gjør når e-posten ikke sendes .

Opplysninger support trenger

Før dere ber om hjelp, noter:

• avsender og mottaker, eventuelt anonymisert
• tidspunkt med tidssone
• om webmail virker
• om mottak, sending eller begge feiler
• hvilken app og enhet som brukes
• servernavn, port og valgt TLS-modus uten passord
• hele feilmeldingen eller returmeldingen
• Message-ID eller sporings-ID når den finnes

Dette gjør det mulig å finne riktig system uten å be om innloggingshemmeligheter. Send aldri passord, app-passord, gjenopprettingskoder eller aktive sesjonstoken til support.

Trenger bedriften e-postkontoer på eget domene, kan dere se Vymos e-postpakker, lagring og pris . Ved en konkret feil kan offentlige DNS-resultater og anonymiserte statuskoder sendes via kundeservice .