Kort svar: En bounce-mail indeholder præcis de tre ting, du skal bruge: statuskoden (4xx = midlertidig, 5xx = permanent), den udvidede kode (fx 5.1.1 = ukendt adresse, 5.7.x = afvist af politik/sikkerhed) og modtagerserverens egen tekst, der ofte forklarer eller linker til årsagen. Læs de tre felter, før du gør noget – så ved du, om fejlen er modtagerens adresse, jeres omdømme eller en teknisk opsætning.
“Beskeden kunne ikke leveres” udløser ofte panik eller – værre – gentagne forsøg på at sende igen. Men bouncen er ikke en fejlmeddelelse, der skal væk; den er en diagnose, der skal læses. Modtagerens server fortæller præcist, hvad der skete – på et sprog, der er nemt at afkode, når man kender de få koder, der går igen.
Kontrolramme: Vejledningen er skrevet pr. 30. august 2026. Eksemplet i billedet er genskabt med anonymiserede adresser.
Bounce-mailen (teknisk: en NDR eller DSN) kommer fra en “Mail Delivery Subsystem”-afsender og gengiver modtagerserverens sidste svar. Kig efter linjen med statuskoderne – den ser typisk sådan ud:
Første ciffer deler verden i to. 4xx er midlertidigt: modtagerserveren siger “prøv igen senere” – og det gør din server automatisk i typisk 1-3 døgn, før den opgiver. En 4xx-notifikation (“delivery delayed”) kræver altså som udgangspunkt ingen handling; årsagen er ofte greylisting eller køer, eller en fuld postkasse hos modtageren. 5xx er permanent: serveren afviser endeligt, og gensend uden ændringer giver samme resultat – her skal koden læses.
| Kode | Betyder | Din handling |
|---|---|---|
| 5.1.1 (user unknown) | Adressen findes ikke | Tjek stavning; fjern adressen fra lister |
| 5.2.2 (mailbox full) | Postkassen er fuld | Kontakt modtageren ad anden vej |
| 5.7.1 (rejected/policy) | Afvist af modtagerens politik – ofte SPF/DKIM/DMARC eller omdømme | Læs serverens tekst; tjek jeres autentifikation |
| 5.7.26 / „not authenticated“ | Mangler SPF/DKIM-godkendelse | Se autentifikations-guiden nedenfor |
| 4.2.1 / 4.7.0 (deferred) | Midlertidigt udskudt (greylisting, rate limit) | Afvent – serveren prøver selv igen |
| 5.3.4 (message too big) | Mailen overskrider størrelsesgrænsen | Se vedhæftnings-guiden |
| 552/550 „spam“ i teksten | Indhold eller omdømme udløste spamfilter | Tjek indhold, links og afsenderomdømme |
5.7.x-familien er den, der kræver teknisk handling hos afsenderen: den betyder, at modtageren ikke stoler på mailen. Tjek i rækkefølge: at SPF, DKIM og DMARC er på plads og består (start i autentifikations-guiden, og tæl SPF-opslagene); om afvisningen kun rammer én modtagerudbyder (Gmail har fx egne krav – se Gmail-guiden); og om serverens tekst nævner en blokliste – i så fald står der typisk et opslagslink direkte i bouncen. Gælder afvisningerne bredt og pludseligt, så kontakt supporten med hele bounce-teksten – den er præcis dokumentationen, vi skal bruge.
Sagen er lukket, når en ny testmail til samme modtager leveres (eller adressen er bekræftet død og fjernet fra alle lister), og når årsagskategorien er noteret: modtagerens adresse, jeres autentifikation eller indhold/omdømme. Gem bouncen, til sagen er løst – og gør det til en vane at læse koden før gensend: tre gensend til en 5.1.1-adresse ser ud som spam-adfærd og skader netop det omdømme, du forsøger at beskytte.
En ægte bounce er ufarlig tekst. Men svindlere efterligner formatet – klik aldrig på links i en bounce for en mail, du ikke har sendt, og tjek at den vedhæftede originalmail faktisk er din.
Det kaldes backscatter: spammere forfalsker din adresse som afsender, og fremmede servere sender afvisningerne til dig. Det stoppes ikke af dig direkte – men en stram DMARC-politik gør din adresse langt mindre attraktiv at forfalske.
Typisk 1-3 døgn med stigende intervaller, hvorefter den opgiver og sender en endelig bounce. Du behøver altså ikke gøre noget før den endelige besked – og haster det, så brug en anden kanal i stedet for gensend.
