E-posten sendes ikke – finn hvor den stopper

«E-posten sendes ikke» kan bety minst fire forskjellige ting. Meldingen kan ligge fast på enheten, SMTP-serveren kan avvise innloggingen, en annen server kan returnere meldingen senere, eller mottakeren kan ha tatt imot den uten å vise den i innboksen.

Ikke start med å endre DNS. Finn først hvilket ledd som stopper meldingen. Da unngår du å lage en ny feil mens du prøver å rette den første.

Først: hvilken situasjon har du?

Noter tidspunkt med tidssone, avsender, mottaker og hele feilmeldingen før du tester videre. Ikke send den samme meldingen mange ganger. Gjentatte tester kan skape kø, duplikater og unødvendige spam-signaler.

1. Test fra webmail

Send en kort melding uten vedlegg fra webmail til en adresse du kontrollerer hos en annen leverandør.

• Webmail virker, men e-postappen feiler: Kontoen og leverandørens utgående tjeneste fungerer sannsynligvis. Undersøk oppsettet eller lagrede legitimasjonsdata i appen.
• Webmail feiler også: Ta vare på feilen og sjekk kontoens status, kvote og eventuelle driftsmeldinger før du endrer appen.
• Meldingen blir sendt, men kommer ikke frem: Gå videre til returmelding, sporingsdata og mottakerfiltrering.

Testen avgrenser problemet. Den beviser ikke at all levering fungerer, men skiller ofte en lokal klientfeil fra en konto- eller leveringsfeil.

2. Hvis meldingen ligger i utboksen

En melding som aldri blir levert til SMTP-serveren har ennå ikke nådd det offentlige e-postsystemet. Kontroller:

1. at enheten faktisk er på nett
2. om appen står i frakoblet modus
3. om én stor eller skadet melding blokkerer resten av køen
4. om kontoen ber om nytt passord
5. om lagringsplassen på enheten eller kontoen er full
6. om appen kan sende en kort tekstmelding uten signatur og vedlegg

Hvis én bestemt melding blokkerer køen, lagre innholdet før du flytter eller sletter den. Unngå å fjerne en hel konto fra enheten før du vet at lokale, ikke-synkroniserte data er bevart.

3. Kontroller SMTP-innstillingene, ikke MX

E-postappen leverer utgående meldinger til en submission-server. Guiden til SMTP fra app, via kø og MX, til mottakerserver viser hvor dette leddet ligger. Standardisert meldinginnlevering skjer normalt på port 587, mens port 465 brukes til SMTP med TLS fra første byte. Port 25 brukes primært mellom servere og er vanligvis feil valg for en vanlig e-postapp. Se port- og TLS-matrisen før en port endres.

Bruk verdiene leverandøren har gitt deg:

• nøyaktig servernavn
• port
• STARTTLS eller implisitt TLS
• autentiseringsmetode
• brukernavn, ofte hele e-postadressen
• vanlig passord, app-passord eller annen metode som kontoen krever

Ikke gjett servernavnet ut fra domenets MX-post. MX forteller hvor innkommende server-til-server-post skal leveres. Det er ikke nødvendigvis adressen e-postappen skal bruke for utgående post.

RFC 6409 skiller meldinginnlevering fra SMTP-transport mellom servere. Vymos kontoverdier finnes i oppsettsguiden for e-post . Bruk alltid verdiene fra aktiveringen dersom de avviker fra et generelt eksempel.

Ikke «løs» TLS-feil ved å slå av kryptering

En TLS-feil kan skyldes feil servernavn, gammel programvare, feil klokke på enheten, inspeksjon i nettverket eller et sertifikatproblem. Å velge «ingen kryptering» skjuler ikke årsaken på en trygg måte.

Test først:

• samme konto i oppdatert webmail eller en oppdatert app
• samme enhet på et annet betrodd nettverk
• at dato og klokkeslett er riktige
• at servernavn og TLS-type er skrevet nøyaktig som oppgitt

Hvis appen viser et sertifikatnavn som ikke samsvarer med serveren du skrev inn, ikke godta unntaket ukritisk. Ta skjermbilde av varslet og kontakt leverandøren.

4. Tolk innloggingsfeilen presist

«Authentication failed» betyr ikke alltid bare feil passord. Mulige årsaker er:

• gammelt passord lagret i appen
• feil brukernavn
• kontoen er sperret etter mange forsøk
• leverandøren krever app-passord eller en annen innloggingsmetode
• SMTP-autentisering er deaktivert for kontoen
• appen forsøker en metode serveren ikke støtter

Bekreft først at du kan logge inn på den offisielle kontosiden eller webmailen. Hvis passordet nylig ble endret, oppdater det på alle enheter. En gammel telefon som fortsetter å prøve feil passord kan utløse ny sperring.

Mistenker du at andre har brukt kontoen, bør du ikke nøye deg med å få sendingen i gang. Bytt legitimasjon fra en betrodd enhet, avslutt aktive økter der dette er mulig, kontroller videresendingsregler og varsle administrator.

5. «Relay denied» handler om autorisasjon

SMTP-serveren må vite hvilken konto som leverer meldingen og hvilke avsenderadresser kontoen har lov til å bruke. «Relay denied», «not permitted to send as» eller lignende kan bety at:

• SMTP-autentisering ikke er aktivert i appen
• innkommende og utgående konto bruker forskjellige brukernavn
• Fra-adressen ikke er godkjent som konto eller alias
• appen bruker en gammel serverprofil
• en administrativ policy blokkerer ekstern videresending eller avsenderen

Ikke opphev sikkerhetspolicyer globalt for å få én klient til å virke. Finn kontoen, avsenderadressen og den konkrete regelen som avviser forsøket.

6. Når serveren har tatt imot meldingen

Et vellykket SMTP-svar betyr at neste server har akseptert ansvar for meldingen. Det betyr ikke nødvendigvis at meldingen er lest eller ligger i innboksen. Senere levering kan fortsatt feile, og mottakersystemet kan filtrere meldingen.

Ta vare på:

• tidspunkt og tidssone
• meldingens Message-ID hvis tilgjengelig
• serverens kø-ID eller sporings-ID
• avsender og mottaker
• full returmelding, uten å videresende passord eller unødvendig meldingsinnhold

Disse opplysningene gjør det mulig for leverandøren å finne den riktige hendelsen i loggene. «Det virket ikke i går» er sjelden nok til presis feilsøking.

7. Les returmeldingen nedenfra og opp

En returmelding inneholder gjerne både en tresifret SMTP-kode, en forbedret statuskode som 5.1.1, og tekst fra serveren som avviste meldingen. Den fulle kombinasjonen er viktigere enn ett enkelt tall.

Den første delen av en forbedret statuskode gir hovedretningen:

• 2.x.x betyr at handlingen lyktes
• 4.x.x betyr en midlertidig feil som normalt kan prøves igjen av serveren
• 5.x.x betyr en permanent feil som krever en endring før samme melding kan leveres

Den andre delen peker på feilområdet:

Dette følger modellen i RFC 3463 . Leverandører legger til egen tekst og kan bruke flere registrerte detaljkoder. Søk derfor på hele statuskoden og leverandørens egen forklaring, ikke bare på «550».

Hvorfor gamle kodetabeller villeder

550 betyr ikke alltid «adressen finnes ikke», og 554 betyr ikke alltid «spam». Den forbedrede koden og teksten kan skille ugyldig mottaker fra manglende autorisasjon, autentiseringsfeil eller annen policy. En side som gir én forklaring per tresifrede kode, kan sende deg i feil retning.

8. Når DNS er relevant

DNS blir relevant for utgående levering når en mottakerserver eller returmelding peker på avsenderautentisering, domenepolicy, omvendt DNS eller ruting. Kontroller da det faktiske sendesystemet:

• SPF-posten må autorisere riktig infrastruktur uten å bli for bred
• utgående meldinger må faktisk signeres med DKIM, ikke bare ha en nøkkel i DNS
• DKIM- eller SPF-domenet må være aligned med synlig Fra-domene for DMARC
• DMARC-posten må være gyldig og passe til avsenderkartleggingen
• direkte sendende servere kan trenge sammenhengende fremover- og reversoppslag

Ikke legg til en tilfeldig IP i SPF eller bytt MX fordi én melding ble filtrert. Finn først hvilken server som sendte, hvilket domene den brukte for SPF/DKIM og hva mottakeren faktisk avviste.

For utsending til personlige Gmail-kontoer har Google egne, oppdaterte krav til e-postavsendere . Volum, autentisering, DNS, TLS, klagerate og avmeldingsmekanisme kan være relevante. Et grønt SPF-resultat alene garanterer ikke levering.

Se SPF, DKIM og DMARC forklart og DMARC-rapporter etter RFC 9990 før du endrer policy.

Navngir avvisningen en blokkeringsliste eller den faktiske sende-IP-en, bruk guiden til svartelistesjekk og avlisting før dere sender en fjerningsforespørsel.

9. Når MX faktisk bør undersøkes

Ditt eget domenes MX-poster er først og fremst relevante når andre ikke får sendt til domenet, eller når en returmelding peker på ruting til dette domenet. De er ikke et normalt første tiltak når e-postappen din ikke får logget inn på utgående server.

Ved et mottaksproblem bør du kontrollere:

• at MX peker til den aktive e-postleverandøren
• at gamle og nye leverandører ikke er blandet
• at målene finnes og er skrevet riktig
• at domenet og DNS-sonen fortsatt er aktive

Les feilsøking når e-post ikke mottas for den andre retningen av leveringskjeden.

10. Ingen returmelding og ingenting i innboksen

Be mottakeren kontrollere mer enn søppelpostmappen:

• karantene eller sikkerhetsportal
• innboksregler og videresending
• faner, arkiv og «alle meldinger»
• om adressen ble skrevet riktig
• om en fellespostkasse eller distribusjonsliste har egne begrensninger

Samtidig bør avsenderens administrator søke i leveringsloggen. Hvis loggen viser at mottakerserveren aksepterte meldingen, må mottakerens leverandør eller administrator normalt undersøke neste ledd. Oppgi kø-ID, tidspunkt og mottaker; ikke be dem lete bare etter emneteksten.

En kontrollert testmatrise

Bruk noen få tester som isolerer variabelen:

Endre én ting om gangen og noter resultatet. Hvis du endrer passord, port, servernavn og DNS samtidig, mister du muligheten til å vite hva som løste eller forverret problemet.

Dette sender du til support

En god supportsak inneholder:

1. tidspunkt med tidssone
2. avsender og mottakerdomene; full adresse bare når det er nødvendig og kan deles forsvarlig
3. om feilen gjelder alle mottakere eller bare noen
4. om webmail fungerer
5. e-postapp, versjon, enhet og operativsystem
6. hele feilmeldingen eller returmeldingen
7. melding-ID, kø-ID eller sporings-ID
8. hva som allerede er testet

Send aldri passord, app-passord eller private nøkler. Fjern uvedkommende meldingsinnhold fra skjermbilder og returer.

Har du e-post hos Vymo, kan du kontakte Vymo med feildetaljene . Har du en annen leverandør, bør den leverandøren først kontrollere innlogging, konto og sine leveringslogger. Vymo kan ikke se sporingsdata i en tredjeparts e-postsystem.