Mail forsinket: greylisting, køer og Received-headere

Kort svar: En forsinket mail er næsten altid én af tre ting: greylisting (modtageren afviser første forsøg med vilje og accepterer gensendelsen minutter senere), en kø hos afsender eller modtager (spidsbelastning, midlertidige fejl) – eller sjældnere et tungt spamtjek. Svaret står i mailens Received-headere: hvert hop har et tidsstempel, så du kan se præcis, hvor minutterne blev brugt. Først når forsinkelsen er kronisk eller rammer bredt, er der noget at rette.

Fagligt gennemgået: 2. oktober 2026

„Jeg sendte den for tyve minutter siden!“ Mail føles øjeblikkelig, men er bygget som et stafetløb med indbyggede venteværelser – og nogle af dem er der med vilje.

Guiden viser, hvordan du aflurer en konkret mails rejse, hvordan du undgår den klassiske tidszonefejl, hvad greylisting er (og hvorfor det er en ven), og hvornår forsinkelser faktisk er et symptom på noget, der skal rettes.

Tip: Analysér altid headerne fra modtagerens kopi af mailen. Afsenderens kopi i „Sendt“ har ikke været igennem modtagerens servere og viser derfor ikke, hvor ventetiden opstod.

1. Find headerne på den forsinkede mail

Åbn den forsinkede mail hos modtageren, og vis originalen eller kildekoden. I Gmail hedder det „Vis original“; i de fleste andre mailprogrammer ligger det under mailens egenskaber, detaljer eller kilde. Kopiér hele headerblokken ud i en teksteditor, så er den nemmere at læse.

Hver server, mailen passerede, har stemplet en Received-linje øverst i headerne. Det betyder, at listen skal læses nedefra: nederste Received-linje er første hop (afsenderens egen server), øverste er sidste (modtagerens postkasse).

2. Læs tidsstemplerne – og pas på tidszonerne

Hver Received-linje slutter med et tidsstempel. Forenklet ser det sådan ud (eksemplet er illustrativt med eksempeldomæner):

Received: from mx.example.net by mailbox.example.net; Wed, 30 Sep 2026 10:24:41 +0200
Received: from mail.example.com by mx.example.net; Wed, 30 Sep 2026 08:24:39 +0000
Received: from [10.0.0.5] by mail.example.com; Wed, 30 Sep 2026 10:02:13 +0200

Læg mærke til tidszonen bag hvert stempel: +0200 og +0000 er to timer fra hinanden. Omregn alle tider til samme zone, før du trækker dem fra hinanden. I eksemplet ankom mailen til afsenderens server 10:02:13 dansk tid og blev modtaget af modtagerens server 08:24:39 UTC, altså 10:24:39 dansk tid – et spring på godt 22 minutter mellem de to servere.

Vær også opmærksom på, at et servers ur kan gå forkert. Viser et hop „negativ“ tid, eller hopper tiderne usandsynligt frem og tilbage, er det et ur og ikke en forsinkelse.

3. Placér springet

Hvor ligger springet?	Hvad betyder det?	Hvem kan gøre noget?
Før afsenderserverens første stempel	Mailen sad i afsenderens mailprogram eller system (udbakke, offline)	Afsenderen
Mellem afsenderens og modtagerens server	Levering, kø eller greylisting	Afsender og modtagerens udbyder
Efter modtagerserverens første stempel	Modtagerens interne behandling: spamtjek, videresendelse, filtre	Modtagerens udbyder

Placeringen afgør, hvem der skal kontaktes. Det er spild af tid at rette afsenderopsætningen, hvis springet ligger inde hos modtageren – og omvendt.

4. Greylisting: den bevidste forsinkelse

Greylisting udnytter en forskel på rigtige mailservere og spamudsendere: rigtige servere prøver igen. Modtageren afviser første leveringsforsøg fra en ukendt afsender med en midlertidig 4xx-fejl; afsenderserveren gensender efter nogle minutter, og så accepteres mailen – og afsenderen huskes, så fremtidige mails går direkte igennem.

Deraf det klassiske mønster: den første mail til en ny kontakt tager mange minutter, alle efterfølgende er øjeblikkelige. Det er ikke en fejl – det er et spamfilter, der virker. Hvor længe forsinkelsen bliver, afhænger især af, hvornår afsenderserveren prøver igen; nogle servere prøver efter få minutter, andre venter længere.

Kan forsinkelsen på første kontakt ikke accepteres forretningsmæssigt (fx ordrebekræftelser), er løsningen på modtagersiden (hvidlistning) eller et konsistent afsender-setup, der hurtigt opbygger omdømme – ikke at slå gensendelsen fra.

5. Køer og udskudt levering

Får afsenderserveren en midlertidig fejl – modtagerens server er travl, der er rate limiting, eller postkassen er fuld med et 4xx-svar – lægger den mailen i kø og prøver igen med stigende intervaller. Mailstandarden (RFC 5321) anbefaler, at afsenderen bliver ved i mindst 4–5 dage, før den opgiver; i praksis afhænger det af serverens opsætning. Først derefter kommer en endelig bounce.

Får du en „delivery delayed“-notifikation, er det præcis dét, der sker: information, ikke alarm. Massive samtidige udsendelser (nyhedsbreve fra eget domæne) kan også selv skabe køen – endnu en grund til at lade nyhedsbrevssystemer sende fra deres egen infrastruktur på et underdomæne.

Forsinkelse inde hos modtageren

Ligger springet efter modtagerserverens første stempel, er mailen kommet frem, men har ventet internt. Typiske forklaringer:

• Spam- og virusscanning: store vedhæftninger og arkiver tager længere tid at scanne, og nogle systemer holder mistænkelige mails tilbage til en ekstra kontrol.
• Videresendelse: sendes mailen videre til en anden adresse eller udbyder, starter en ny leveringsrunde – med egne køer og eventuel greylisting hos den næste modtager. Videresendelse kan også få SPF-tjek til at fejle hos den endelige modtager; se guiden om autosvar og videresendelse.
• Karantæne: nogle spamfiltre lægger mails i karantæne og frigiver dem først efter godkendelse – så føles det som en forsinkelse, selvom mailen bare har ligget et andet sted.

Her er det modtagerens udbyder eller IT-ansvarlige, der kan se i deres logs, hvad der skete.

6. Hvornår skal der handles?

• Kronisk forsinkelse til samme modtagerdomæne: jeres omdømme eller autentificering halter hos netop den udbyder – tjek SPF, DKIM og DMARC og se Gmail-guiden for kravene hos de store.
• Forsinkelse på alt udgående: afsenderserverens kø er presset eller fejlkonfigureret – det er et supportspørgsmål med Received-headerne som dokumentation.
• Systemmails (ordrer, kvitteringer) hænger: tjek om sitet sender via rigtig SMTP med login – og om baggrundsjobs kører; se ordremail-guiden.
• Timer eller dage uden levering og uden bounce: behandl det som tabt, brug en anden kanal – og undersøg bagefter med headerne fra en testmail.

Sådan skriver du en god supportsag

Vedhæft de fulde headere fra modtagerens kopi – ikke et skærmbillede af mailen. Skriv afsender- og modtageradresse, hvornår mailen blev sendt (med tidszone), og hvor springet ligger efter din analyse. Har du flere eksempler, så vælg to-tre stykker fra forskellige dage; et mønster er lettere at finde end en enkeltstående hændelse.

7. Verifikation

Billedet er sundt, når en testmail til en ny ekstern adresse leveres inden for minutter (evt. med ét greylisting-ophold på første forsøg), gentagne mails til samme modtager går øjeblikkeligt igennem, og Received-analysen på en stikprøve viser sekunder – ikke minutter – på jeres egne hop.

Gør Received-læsningen til første refleks ved næste „mailen kom aldrig frem“-sag: den flytter samtalen fra fornemmelser til tidsstempler.

Læs også

• Hub: Mail: fejl og fejlfinding
• Sådan læser du en bounce-mail
• Gmail afviser din mail
• Postkassen er fuld
• SMTP-porte 25, 465 og 587
• Email hosting hos Hostious – med spam- og virusfilter og dansk support

Ofte stillede spørgsmål om forsinket mail

Kan jeg slå greylisting fra?

Kun på din egen indgående mail (som modtager) – og tænk dig om: greylisting stopper mængder af spam gratis. Som afsender kan du intet slå fra hos modtagerne; dér hjælper kun konsistent afsenderopsætning og omdømme.

Hvorfor er første mail til en ny kontakt altid langsom?

Det er greylistings signatur: første forsøg afvises midlertidigt, gensendelsen accepteres, og afsenderen huskes. Mønsteret „første gang langsomt, derefter øjeblikkeligt“ er beviset – og helt normalt.

Betyder „delivery delayed“ at mailen er tabt?

Nej – tværtimod: serveren fortæller, at den stadig prøver. Først hvis der senere kommer en endelig bounce, er leveringen opgivet – og så står årsagen i bounce-koderne.

Hvor længe prøver en mailserver at levere en mail?

Mailstandarden anbefaler, at afsenderen prøver i mindst 4–5 dage med stigende intervaller, men den præcise tid afhænger af serverens opsætning. Kommer der hverken mail eller bounce inden for et par dage, bør du undersøge sagen.