E-post i retur – les statuskoden riktig

En returmelding, også kalt DSN, bounce eller leveringsstatusvarsel, beskriver hva som skjedde med én eller flere mottakere. Den kan si at levering feilet permanent, er forsinket, ble videresendt eller i enkelte tilfeller lyktes.

Den viktigste regelen er: les statusen per mottaker. Hvis en melding ble sendt til fem adresser, kan fire ha fått den selv om den femte ga retur.

Finn maskindelen, ikke bare overskriften

Mange leverandører viser først en menneskeskrevet oppsummering som «adressen finnes ikke» eller «meldingen ble blokkert». Lenger ned ligger strukturerte felt.

Et forkortet eksempel:

Reporting-MTA: dns; outbound.sender.example

Final-Recipient: rfc822; ukjent@example.no
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.no
Diagnostic-Code: smtp; 550 5.1.1 User unknown
Last-Attempt-Date: Sat, 22 Aug 2026 14:05:00 +0200

Her er de sentrale feltene:

Feltsettet følger formatet i RFC 3464 . Ikke alle leverandører viser alle feltene, og noen pakker dem inn i et grafisk varsel.

550 og 5.1.1 er ulike kodetyper

Et diagnostisk svar kan inneholde:

550 5.1.1 User unknown

Delene har ulike roller:

• 550 er et tresifret SMTP-svar på en protokollkommando.
• 5.1.1 er en forbedret statuskode med klasse, emneområde og detalj.
• User unknown er serverens fritekst og kan variere mellom leverandører.

Ikke søk bare etter 550. Den koden kan følge adressefeil, policyfeil, autentiseringsfeil og andre avvisninger. Bruk hele kombinasjonen og dokumentasjonen til serveren som svarte.

Første del: lyktes, midlertidig eller permanent

Ved et SMTP-svar begynner også den tresifrede koden normalt med 2, 4 eller 5 etter samme hovedretning. Men den forbedrede koden gir mer presis, registrert betydning. Se hvor i SMTP-forløpet et svar oppstår for å skille klientinnlevering, serverkø og mottakeravvisning.

En 4-kode betyr ikke alltid «bare vent»

Hvis Action er delayed og statusen er 4.x.x, står meldingen gjerne fortsatt i kø. Se etter Will-Retry-Until og la sendesystemet håndtere nye forsøk.

Hvis Action er failed, kan en opprinnelig midlertidig feil ha vart til køtiden utløp. 4.4.7 betyr for eksempel at leveringstiden utløp. Da må årsaken undersøkes før en person manuelt sender på nytt.

Andre del: hvilket område feilet?

Den tredje delen angir detaljen. Den oppdaterte kildelisten er IANAs register for forbedrede SMTP-statuskoder . Ikke bygg en intern parser på en tilfeldig bloggoversikt; registeret kan få nye koder.

Vanlige koder og målrettede tiltak

Leverandører kan bruke egne tekster og av og til mindre presise kodevalg. Tabellen er et startpunkt; den konkrete Diagnostic-Code og mottakerens dokumentasjon avgjør tiltaket.

Adressefeil

Ved 5.1.x:

1. Kontroller tegnene før og etter @.
2. Bekreft adressen gjennom nettsted, avtale eller en kjent kontaktkanal.
3. Se om mottakeren nylig har byttet jobb, navn eller leverandør.
4. Oppdater kildesystemet, ikke bare én sendt melding.
5. Undertrykk permanent ugyldige mottakere i utsendelseslister.

Ikke bruk en annen tilfeldig adresse på samme domene for å «finne noen». Meldingen kan inneholde opplysninger bare den opprinnelige mottakeren skulle få.

Kvote og meldingsstørrelse

En fil på 20 MB kan bli større når den kodes inn i e-postmeldingen. Signaturbilder, tekstalternativ og andre MIME-deler teller også. Derfor kan en melding overskride grensen selv om vedlegget ser mindre ut enn den oppgitte maksimumsverdien.

Ved størrelsesfeil:

• fjern unødvendige vedlegg og signaturbilder
• komprimer filen uten å ødelegge kvalitet eller metadata
• del gjennom en godkjent løsning med riktig tilgang og utløp
• oppgi i e-posten hva mottakeren får tilgang til

Ikke last sensitive dokumenter opp til en tilfeldig gratistjeneste bare for å komme under grensen. Bruk guiden til sikker filoverføring når innholdet krever kontroll.

Ruting og midlertidige feil

Ved 4.4.x eller annen midlertidig status:

• kontroller om alle mottakere på domenet rammes
• se etter driftsmelding hos relevant leverandør
• kontroller domenestatus, NS, DNSSEC og MX
• la avsenderserverens kø gjøre kontrollerte nye forsøk
• ikke start flere manuelle kopier med nye melding-ID-er

Hvis køen til slutt gir opp, ta vare på både den endelige DSN-en og tidligere forsinkelsesvarsel. Tidslinjen kan vise om feilen var konstant eller skiftet mellom servere.

Policy og autentisering

5.7.x er et bredt område. Mulige årsaker inkluderer:

• avsenderen har ikke lov til å bruke SMTP-serveren
• mottakeren blokkerer kilde, avsender eller innhold
• SPF, DKIM eller flere autentiseringskontroller feiler
• DMARC-alignment mangler
• reverse DNS bryter mottakerens policy
• en distribusjonsliste tillater bare medlemmer
• rate- eller misbruksvern stopper trafikken

Ikke legg automatisk en IP i SPF fordi svaret inneholder ordet «authentication». Finn faktisk envelope-from, DKIM-domene, selector, sende-IP og synlig Fra-domene.

Hvis returteksten navngir en offentlig liste eller sier at sende-IP-en er registrert, følg arbeidsflyten for å kontrollere og fjerne en relevant listeoppføring . En generell 5.7.x er ikke alene bevis på svartelisting.

Bruk feilsøkingsguiden for e-post som ikke sendes og guiden til e-post som havner i spam etter hva returteksten sier.

Delvis levering til flere mottakere

En DSN inneholder én blokk per berørt mottaker. Kontroller hver Final-Recipient, Action og Status.

Eksempel:

Ikke anta at hele meldingen feilet fordi returvarselet nevner én adresse. En ny utsending til alle kan gi duplikater til dem som allerede fikk den.

Når fikk mottakeren meldingen «likevel»?

Mulige forklaringer er:

• en annen mottaker i samme utsending fikk den
• den første meldingen var forsinket og en senere kopi ble sendt
• et alias eller en videresending leverte til en annen postkasse
• returmeldingen var falsk eller gjaldt en annen melding
• mottakerserveren aksepterte meldingen før et senere lokalt system genererte varsel

Korreler med melding-ID, tidspunkt og den enkelte mottakeren. Ved et endelig SMTP-avslag for akkurat den mottakeren har serveren normalt ikke akseptert ansvaret for den leveringen.

Returmeldinger kan også være falske

En DSN er en e-post og kan forfalskes eller brukes som phishing. Vær skeptisk hvis den:

• gjelder en melding dere ikke sendte
• ber om innlogging eller betaling
• inneholder en knapp til et ukjent domene
• mangler kobling til avsender, mottaker og tidspunkt
• har vedlegg som må åpnes for å «frigjøre» meldingen

Ikke klikk for å «levere på nytt». Sjekk Sendt, avsendersystemets logg og melding-ID. En retur til en melding virksomheten aldri sendte kan også være backscatter etter at noen forfalsket avsenderadressen.

Automatisert håndtering

Et utsendelsessystem bør behandle DSN per mottaker og minst lagre:

• melding-/envelope-ID
• mottaker
• action og status
• diagnostisk kode
• første og siste forsøk
• kilde og kampanje/strøm
• beslutning om nytt forsøk eller undertrykking

Ikke undertrykk alle 4.x.x permanent. Ikke send videre til alle 5.x.x. Regler må skille adresse, policy, størrelse, ratebegrensning og køutløp. Bevar avmeldinger og permanente undertrykkelser ved plattformbytte.

Behandle innholdet som utrygge data før det vises i dashboard eller brukes i automatisering. Fritekst fra en ekstern server skal ikke kunne injisere HTML, kommandoer eller loggformat.

Dette sender du til support

• hele DSN-filen eller de strukturerte feltene
• opprinnelig melding-ID og eventuell kø-ID
• berørt mottaker og avsenderdomene
• tidspunkt med tidssone
• om andre mottakere hos samme leverandør virket
• om feilen er gjentatt og fra hvilken avsenderstrøm
• DNS- eller autentiseringsendringer rett før feilen

Fjern unødvendig originalt meldingsinnhold og personopplysninger, men ikke klipp bort statusfeltet og serverteksten. Send aldri passord eller private nøkler.

Har du e-post hos Vymo, kan du kontakte Vymo med statusdataene . Vymos publiserte planer lover ikke et selvbetjent logg- eller leveringsdashboard, så presise tidspunkt og identifikatorer er viktige for en konkret undersøkelse.

Hvis problemet gjelder innkommende post til deres eget domene, fortsett med mottaksguiden for MX, filter og postkasse .