Mottar ikke e-post – finn hvor den stopper

Når en melding ikke synes i innboksen, kan den ha stoppet i DNS, blitt avvist av e-postleverandøren, rutet til feil konto, satt i karantene eller mottatt riktig uten at appen synkroniserer.

Ikke start med å endre MX. Finn først om problemet gjelder én melding, én adresse, hele domenet eller bare én enhet.

Den inngående kjeden

Avsenders kø
  → DNS-oppslag for mottakerdomenet
  → mottakende e-postserver
  → mottaker/alias/distribusjon
  → spamfilter eller karantene
  → postkasse
  → webmail, IMAP eller POP3 på enheten

Hvert ledd har egne bevis. En riktig MX-post beviser ikke at adressen finnes. En tom innboks i telefonappen beviser ikke at serveren aldri mottok meldingen.

Avgrens problemet med fire spørsmål

Noter tidspunkt med tidssone, full mottakeradresse, avsenderdomene og melding-ID før dere tester videre. Ikke bruk en sensitiv produksjonsmelding som test.

1. Sjekk webmail før e-postappen

Logg inn i leverandørens webmail og søk etter:

• avsenderadresse og avsenderdomene
• emne eller et unikt ord
• omtrentlig tidspunkt
• alle mapper, inkludert søppelpost, arkiv og papirkurv

Kontroller også serverstyrt karantene hvis tjenesten har en egen sikkerhetsportal.

Hvis meldingen finnes i webmail, har DNS, mottakerserver og postkasse sannsynligvis gjort jobben. Problemet ligger normalt i e-postappen, mappevisningen eller lokal synkronisering.

Hvis meldingen ikke finnes, fortsetter dere mot avsenderens returdata og leverandørens sporingsdata.

2. Skaff returmeldingen fra avsenderen

Be avsenderen sende den komplette returmeldingen som tekst eller fil, uten unødvendig opprinnelig innhold. Ta vare på:

• tresifret SMTP-kode
• forbedret statuskode som 4.4.1 eller 5.1.1
• teksten fra serveren som avviste
• hvilken server som svarte
• tidspunkt, mottaker og kø-/melding-ID

Hovedregelen for forbedrede statuskoder er:

• 4.x.x: midlertidig feil; avsenderserveren vil normalt prøve igjen
• 5.x.x: permanent feil; noe må endres før samme levering kan lykkes

En melding uten umiddelbar retur kan fortsatt stå i avsenders kø. Be avsenderens leverandør undersøke leveringsloggen i stedet for å sende mange kopier.

Oversikten over e-postretur og statuskoder forklarer kodemønstrene. Bruk likevel alltid hele teksten fra den aktuelle mottakeren.

3. Test fra mer enn én ekstern leverandør

Send en kort, unik tekstmelding uten vedlegg fra to eksterne kontoer dere kontrollerer, for eksempel hos ulike leverandører. Ikke bruk en annen konto på samme eget domene som eneste test; intern post kan leveres uten å følge den offentlige MX-ruten.

Gi testene ulike emner og noter tidspunkt:

Test mottak A – 2026-08-22 14:05 CEST
Test mottak B – 2026-08-22 14:07 CEST

Resultatet avgrenser feilen:

4. Kontroller domenet og DNS-kjeden

Før MX vurderes isolert, kontroller:

1. at domeneregistreringen er aktiv
2. at riktige navnetjenere er delegert
3. at DNS svarer uten SERVFAIL
4. at eventuell DNSSEC-validering virker
5. at MX-svaret kommer fra den aktive sonen

Et utløpt domene, feil delegering eller ødelagt DNSSEC kan gjøre alle postene utilgjengelige selv om kontrollpanelet viser en MX-verdi.

Bruk for eksempel:

dig NS example.no +short
dig MX example.no +short
delv example.no MX

delv validerer DNSSEC der verktøyet er installert. Et vanlig dig +dnssec kan be om DNSSEC-data, men beviser ikke alene at valideringen lykkes. Sammenlign med leverandørens nøyaktige verdier og spør gjerne den autoritative navnetjeneren direkte. En offentlig resolver kan vise et bufret svar.

5. Slik skal MX leses

Et MX-svar kan se slik ut:

10 mx1.provider.example.
20 mx2.provider.example.

Det laveste tallet har høyest prioritet. En sender prøver normalt den foretrukne serveren først og bruker andre mål ved behov.

Kontroller:

• at alle mål tilhører den aktive e-postleverandøren
• at gamle og nye leverandører ikke er blandet uten en plan
• at hvert mål er et vertsnavn, ikke en IP-adresse
• at målet har fungerende A- og/eller AAAA-oppslag
• at det ikke er stavefeil eller dobbelt domenesuffiks
• at prioriteringene er satt slik leverandøren krever

dig A mx1.provider.example +short
dig AAAA mx1.provider.example +short

Et MX-mål skal være et kanonisk vertsnavn, ikke avhenge av en CNAME-aliaskjede. Følg leverandørens oppgitte mål i stedet for å lage eget navn foran dem.

Manglende MX og null-MX er forskjellige

Den historiske SMTP-regelen er at en sender kan forsøke domenets A/AAAA-adresse når det ikke finnes noen MX-post. Det betyr at «ingen MX» ikke teknisk sett alltid er det samme som «ingen mottak», selv om et vanlig administrert e-postoppsett skal ha MX-postene leverandøren krever.

En eksplisitt null-MX ser slik ut:

0 .

Den forteller at domenet ikke tar imot e-post. Null-MX er riktig for domener som bevisst ikke skal motta, men feil på et domene med aktive postkasser.

6. Tenk på TTL før du endrer igjen

DNS-cache styres av TTL-en som gjaldt da et svar ble hentet. Hvis TTL ble senket samtidig som MX ble byttet, kan gamle svar allerede være bufret med den tidligere, høyere verdien.

Under en overgang kan noen avsendere derfor nå gammel leverandør mens andre når ny. Ikke «rette» situasjonen med stadig nye MX-endringer. Hold både gammel og ny mottaksløsning under kontroll gjennom den planlagte overgangsperioden og overvåk begge.

Se flytte e-post uten tap for migreringsrekkefølgen.

7. Kontroller konto, alias og intern ruting

Når domenet når riktig leverandør, må mottakeradressen fortsatt finnes eller rutes:

• Er kontoen aktiv og riktig stavet?
• Er aliaset koblet til riktig aktiv konto?
• Er distribusjonslisten begrenset til bestemte avsendere?
• Er plus-adressering som navn+kode@ støttet?
• Har en regel flyttet eller slettet meldingen?
• Er en gammel videresending eller ferieregel fortsatt aktiv?
• Er kontoen sperret etter faktura-, sikkerhets- eller administratorhendelse?

Ikke aktiver catch-all som en rask reparasjon på ett manglende alias. Det kan skjule feil adresser og åpne for store mengder post til tilfeldige navn.

Adressearkitekturen for bedriften forklarer når et alias faktisk er nok.

8. Kvote og lagring

En full postkasse kan gi permanent eller midlertidig avvisning, avhengig av leverandørens policy. Kontroller kvoten i leverandørens webmail eller administrasjon, ikke bare ledig plass på telefonen.

Før dere sletter:

• identifiser hva som bruker plassen
• avklar krav til bevaring
• sikre nødvendig eksport eller arkiv
• tøm papirkurv bare når innholdet kan slettes
• kontroller om delte mapper eller Sendt teller med

Å øke kvoten løser kapasitet, men ikke manglende arkiv- eller bevaringsrutine.

9. Filter, karantene og regler

Meldingen kan være akseptert av serveren og likevel skjult fra vanlig innboks. Sjekk:

• søppelpost og serverkarantene
• blokkerte avsendere og domener
• regler som flytter, videresender eller sletter
• godkjent-/avvist-lister
• sikkerhetspolicy for vedlegg og lenker
• om en administratorregel gjelder hele domenet

Hvis en legitim melding ligger i spam, bevar meldingshodet før du markerer den som ikke spam. Da kan dere se SPF, DKIM, DMARC, kilde-IP og filterresultat.

Ikke tillat hele avsenderdomenet globalt bare for å få én melding frem. Det kan omgå nyttige kontroller for alle som forfalsker eller kompromitterer samme domene. Finn den konkrete regelen og vurder risikoen.

10. Videresending gir en ekstra leveringskjede

Ved videresending skjer dette:

opprinnelig avsender → deres e-postleverandør → ekstern innboks

SPF kan feile fordi den videresendende serveren blir ny kilde-IP. DKIM kan overleve hvis meldingen ikke endres, mens endret innhold kan bryte signaturen. SRS og ARC kan hjelpe i bestemte oppsett, men må støttes og driftes av tjenestene i kjeden.

Test derfor både:

• direkte levering til postkassen hos domenets leverandør
• den videre leveringen til ekstern adresse

Hvis direkte levering virker, men videresending feiler, er MX normalt ikke årsaken. Undersøk videresendingslogg, autentiseringsresultat og ekstern mottakers returkode.

11. Hvis webmail virker, men appen er tom

Da er problemet sannsynligvis etter postkassen:

• appen er frakoblet eller har autentiseringsfeil
• feil konto eller mappe vises
• synkroniseringsperioden er begrenset
• et filter eller fokusert innboks skjuler meldingen
• mappen er ikke abonnert i IMAP-klienten
• lokal lagring eller indeks er skadet
• POP3 har lastet ned og eventuelt fjernet post fra serveren

Ikke slett og legg til kontoen på nytt før lokale, ikke-synkroniserte meldinger og mapper er sikret. Test først med webmail, en annen enhet og leverandørens nøyaktige IMAP-verdier.

Les e-postklientoppsett uten gjetting for klientspesifikke kontroller.

12. Se etter tegn på kompromittering

Ukjente regler som videresender eller sletter innkommende post kan være tegn på at en konto er kompromittert. Andre varsler er:

• ukjente innlogginger eller enheter
• endret gjenopprettingsinformasjon
• ny automatisk videresending
• meldinger markert som lest uten forklaring
• leverandørvarsler om mistenkelig aktivitet

Ikke bare slett regelen og fortsett. Sperr tilgang etter virksomhetens hendelsesrutine, bytt legitimasjon fra en betrodd enhet, avslutt økter der det er mulig, kontroller andre regler og vurder hvilke data som kan være lest eller sendt.

En kontrollert handlingsrekkefølge

1. Ta vare på tidspunkt, mottaker, retur og melding-ID.
2. Søk i webmail, alle mapper og karantene.
3. Test samme adresse fra to eksterne leverandører.
4. Test en annen adresse på samme domene.
5. Kontroller domenestatus, NS, DNSSEC og MX.
6. Kontroller konto, alias, kvote, regler og videresending.
7. Søk i leverandørens leveringslogg dersom den er tilgjengelig.
8. Rett ett identifisert ledd og test på nytt.
9. Dokumenter årsak og varig tiltak.

Ikke endre domene, MX, SPF, videresending og e-postapp samtidig. Da mister dere muligheten til å vite hva som faktisk påvirket leveringen.

Dette sender du til support

En god sak inneholder:

• domene og den berørte mottakeradressen
• avsenderdomene; full adresse når det er nødvendig og kan deles
• tidspunkt med tidssone
• om andre avsendere og mottakeradresser virker
• om meldingen finnes i webmail eller karantene
• full returmelding og statuskode
• melding-ID eller kø-ID
• hvilke kontroller som allerede er gjort

Send ikke passord eller sensitivt meldingsinnhold. Et skjermbilde av innboksen uten tekniske data er sjelden nok til å spore leveringen.

Har du e-post hos Vymo, kan du kontakte Vymo med feildataene . Vymos publiserte planer lover ikke et selvbetjent leveringssporingsverktøy eller bestemte loggdetaljer, så oppgi dataene support trenger for å undersøke den konkrete hendelsen.