Kort svar: Et mailhotel giver dig typisk postkasser på dit domæne med adgang via IMAP eller POP3, mens mail hosting dækker en fuld mailtjeneste med autentificeret afsendelse via SMTP, kryptering med TLS og domænebeskyttelse med SPF, DKIM og DMARC. Navnet på produktet afgør ikke noget, indholdet gør. Bærer mail salg, support eller fakturering, skal du kræve det fulde niveau.
Fagligt gennemgået: 2. oktober 2026
Mange bruger ordene mailhotel og mail hosting, som om de betyder det samme, men i praksis dækker de ofte to forskellige niveauer af maildrift. Den vigtige skillelinje er sjældent navnet, men om du kun får adgang til en postkasse eller en fuld mailtjeneste med afsendelse, kryptering og domæneautentificering.
Den vigtigste tekniske forskel er, at IMAP ikke sender mail. IMAP (RFC 9051) bruges til at tilgå beskeder, mens afsendelse håndteres separat via mail submission (RFC 6409). Er en IMAP- eller POP-klient ikke også sat op med autentificeret SMTP, kan brugeren læse mail, men ikke sende den. Vurder derfor løsningen efter funktioner, protokoller og sikkerhedskrav, ikke efter marketingbetegnelsen.
Hvad er forskellen på mailhotel og mail hosting?
Et mailhotel betyder typisk postkasser og adgang via IMAP eller POP, mens mail hosting normalt dækker mere. Det er den mest praktiske forskel.
Et klassisk mailhotel er ofte en enkel tjeneste, der lader dig oprette adresser som info@ditdomæne.dk og læse dem i Outlook eller Apple Mail. Det kan være fint til små behov, men nogle løsninger stopper reelt ved postkasselaget.
Mail hosting dækker normalt mere. Her indgår ikke bare modtagelse, men også korrekt afsendelse via SMTP Submission, krypterede forbindelser, DNS-poster til SPF, DKIM og DMARC samt administration af flere brugere, aliaser, videresendelser og ofte logning eller support ved leveringsfejl. Mange tror, at en indbakke automatisk betyder en komplet mailtjeneste. Det gør den ikke.
Hvornår er et mailhotel nok, og hvornår kræver du fuld mail hosting?
Et simpelt mailhotel er nok til få brugere og lav risiko, mens mail hosting er det rigtige til domæner, der sender forretningskritiske mails fra både medarbejdere og systemer som WordPress. Valget afhænger af ansvar og ikke kun pris.
Skal du kun modtage og sende et begrænset antal almindelige mails fra et lille domæne, kan et simpelt mailhotel være tilstrækkeligt. Det gælder især, hvis du ikke bruger nyhedsbreve, ordrebekræftelser, CRM-systemer eller flere afsendende enheder.
Så snart mail bliver en del af salgsflow, kundeservice eller compliance, ændrer kravene sig. Sender webshoppen kvitteringer, eller sender et bureau fra kundedomæner, bliver autentificering, afsendelseslogik og leveringssikkerhed helt centrale.
En god tommelfingerregel er enkel: Har tabt eller afvist mail en reel omkostning, bør du vælge mail hosting frem for et minimalt mailhotel. Det gælder også, hvis flere klienter skal sende fra IMAP- eller POP-konti, fordi afsendelse kræver særskilt SMTP AUTH.
Hvad er de 7 vigtigste forskelle på mailhotel og mail hosting?
De syv vigtigste forskelle handler om protokoller, sikkerhed og drift, ikke om ordvalg i en prisliste. Sammenlign løsninger på disse områder:
- Adgang kontra tjeneste: et mailhotel fokuserer ofte på postkasser, mens mail hosting også dækker afsendelse, administration og domænepolitik.
- IMAP og POP: et mailhotel tilbyder ofte kun læseadgang og synkronisering, typisk via IMAP eller POP.
- SMTP Submission: mail hosting inkluderer normalt en egentlig submission-tjeneste til brugerafsendelse, som RFC 6409 adskiller fra almindelig relay-trafik.
- Kryptering: god mail hosting understøtter konsekvent TLS, enten med STARTTLS eller implicit TLS, i tråd med RFC 8314.
- Domæneautentificering: SPF, DKIM og DMARC er ofte fuldt understøttet i mail hosting, men kan være mangelfuldt eller manuelt i simple mailhoteller.
- Fejlsøgning og support: ved leveringsproblemer giver mail hosting oftere adgang til logs, autentificeringskontrol og support på DNS-niveau.
- Driftsniveau: mail hosting er oftere egnet til webshops, systemmails og flere brugere, mens et mailhotel typisk er en basal kontorløsning.
Det er også her, mange sammenligninger går galt. To produkter kan koste næsten det samme, men mangler den ene løsning SMTP AUTH eller korrekt DKIM-signering, er de ikke teknisk sammenlignelige.
Hvordan tjekker du, om en løsning kun giver postkasseadgang eller fuld afsendelse?
Du kan afgøre det på få trin ved at kontrollere IMAP, SMTP Submission og DNS. Kig efter konkrete specifikationer, ikke generelle løfter.
Trin 1: Tjek, om udbyderen nævner både modtagelse og afsendelse. Står der kun IMAP eller POP, er det et advarselstegn. En klient skal også have SMTP Submission for at kunne sende.
Trin 2: Se efter porte og sikkerhed. IMAP kører typisk på 993 med implicit TLS, POP3 på 995, og submission ligger på 587 med STARTTLS eller 465 med implicit TLS. Mangler disse oplysninger helt, er dokumentationen for tynd. Se også SMTP-porte 25, 465 og 587.
Trin 3: Kontrollér, om udbyderen beskriver SPF, DKIM og DMARC. Får du kun MX-records, får du sandsynligvis modtagelse, men ikke hele beskyttelsen omkring afsendelse og domæneidentitet.
En udbredt misforståelse er, at “mail virker”, hvis Outlook kan hente beskeder. Den test siger intet om, hvorvidt domænet kan sende troværdigt, eller om modtagerne vil acceptere mailen.
Sådan tester du din nuværende mailløsning
Har du allerede en løsning, kan du selv lave en hurtig kontrol uden særlige værktøjer:
- DNS-opslag: slå domænets MX-, SPF- (TXT, starter med v=spf1) og DMARC-record (TXT på _dmarc.firma.dk) op i et DNS-værktøj eller med kommandoen nslookup. Mangler SPF eller DMARC, er domænet ikke fuldt beskyttet.
- Klientopsætning: se i mailprogrammet, hvilken server og port der bruges til udgående post, og om der kræves login. Port 25 uden login fra en klient er et faresignal.
- Headerkontrol: send en mail til en Gmail- eller Outlook.com-adresse, åbn “vis original” eller “vis kilde”, og find linjerne med spf=, dkim= og dmarc=. Alle tre bør stå som pass.
Kan du ikke finde svarene, eller fejler et af punkterne, er det et tegn på, at løsningen er nærmere et mailhotel end egentlig mail hosting.
Hvordan virker IMAP, POP, SMTP Submission og SMTP AUTH i praksis?
IMAP læser mail, POP henter mail, og SMTP Submission sender mail med godkendelse. RFC 9051 og RFC 6409 skiller rollerne tydeligt ad. Den korte forklaring står i IMAP, POP3 og webmail.
IMAP er designet til adgang til postkasser på serveren. Det betyder synkronisering af mapper, læste beskeder og lagring på serveren. POP er enklere og henter typisk beskeder ned, ofte med færre samarbejdsfunktioner. Ingen af delene er en afsendelsesprotokol.
Når brugeren trykker “send”, skal klienten over på en submission-tjeneste. Det er her, SMTP Submission og SMTP AUTH kommer ind. Microsoft beskriver i sin dokumentation, at POP3- og IMAP4-klienter bruger autentificeret SMTP til afsendelse, og at brugeren kan læse mail, men ikke sende, hvis SMTP AUTH er slået fra.
Det er en klassisk fejl. Kan du modtage, men ikke sende, er problemet sjældent IMAP, men submission, autentificering eller en politik på kontoen. Fejlfindingen står i kan ikke sende mail, men godt modtage.
Hvordan sætter du TLS, STARTTLS og implicit TLS korrekt op?
Sikker mailtransport kræver som minimum TLS på både adgang og afsendelse. RFC 8314 samler anbefalingerne for IMAP, POP og SMTP Submission.
Trin 1: Brug krypterede porte som standard, dvs. IMAPS på 993, POP3S på 995 og submission på 465 eller 587 med korrekt TLS-konfiguration. Det reducerer risikoen for fejlopsætning i klienterne.
Trin 2: Kontrollér certifikatet og værtsnavnet. Matcher certifikatet ikke servernavnet, får du enten advarsler eller en klient, der falder tilbage til usikker adfærd. Her opstår mange driftsproblemer, selv om serveren teknisk set er online.
Trin 3: Bekræft, at både adgang og afsendelse kræver autentificering. TLS beskytter transporten, men løser ikke alene spoofing eller fejl i domænets DNS. Mange overvurderer hængelåsen: den beskytter forbindelsen, ikke nødvendigvis afsenderens identitet.
Driver du forretningskritisk mail, er TLS bundniveauet. Uden domæneautentificering er du stadig sårbar over for misbrug af dit domænenavn.
Hvad er forskellen på SPF, DKIM og DMARC i simple mailhoteller?
SPF, DKIM og DMARC beskytter domænet, mens TLS beskytter forbindelsen. Myndigheder som det amerikanske CISA beskriver dem som kernekomponenter mod spoofing og phishing.
SPF fortæller, hvilke servere der må sende på vegne af dit domæne. DKIM tilføjer en kryptografisk signatur til mailens headere, så modtageren kan kontrollere, at indholdet stammer fra det angivne domæne og ikke er ændret. DMARC bygger oven på SPF og DKIM og fortæller modtageren, hvad der skal ske, hvis valideringen fejler.
Det vigtige er samspillet. Har du kun SPF, men mails videresendes eller sendes fra flere systemer, kan du stadig få fejl. Har du DKIM uden DMARC, mangler du politik og rapportering. Og har du kun TLS, har du slet ikke håndteret domæneforfalskning.
Simple mailhoteller mangler ofte ikke den tekniske mulighed, men den operationelle modenhed. Du skal måske selv oprette DNS-poster, forstå alignment og tolke rapporter. For små private domæner kan det være acceptabelt. For virksomheder er det sjældent nok.
Hvordan migrerer du et domæne eller en postkasse uden tab af mail?
En sikker mailmigrering kræver timing, DNS-styring og parallel drift i en kort periode. Det handler mere om proces end om held.
Trin 1: Kortlæg alt, der sender fra domænet. Det er ikke kun brugernes mailklienter, men også webshop, kontaktformularer, ERP, booking og scannere. Overses én afsender, opstår der stille fejl efter flytningen.
Trin 2: Sænk TTL på de relevante DNS-poster i god tid, og planlæg et overlap. Flyt derefter postkasser, MX-records og submission-indstillinger kontrolleret. Test gerne med en sekundær konto, før hele domænet skifter.
Trin 3: Validér både modtagelse, afsendelse og autentificering. Send testmails til forskellige modtagere, kontrollér headeren for DKIM, og tjek, om DMARC-politikken opfører sig som forventet.
Test en ekstern modtager, ikke kun interne adresser. Mange fejl skjules, hvis du kun sender inden for samme platform eller domæne. Hele fremgangsmåden står i flyt virksomhedens email uden at miste beskeder.
Hvilke fejl giver typisk leveringsproblemer, spoofing eller afviste mails?
De mest almindelige fejl er manglende SMTP AUTH, forkert DKIM og en DMARC-politik, der ikke passer til virkeligheden. Mailklienten viser symptomet, men årsagen ligger tit i DNS eller submission.
En klassiker er, at brugeren kan hente mail via IMAP, men ikke sende, fordi SMTP AUTH er slået fra eller sat forkert op i klienten.
En anden fejl er delvis autentificering. Et domæne kan have SPF, men sende fra en tjeneste, der ikke står i SPF-recorden. Eller DKIM er aktiveret i en platform, men den offentlige nøgle i DNS er forkert. Så får du sporadiske leveringsfejl, som er svære at se uden headeranalyse.
Den tredje fejl er for slap DMARC. Står politikken på none i lang tid, får du rapporter, men ingen reel håndhævelse. Strammes politikken for hurtigt, uden at alle afsendere er kortlagt, kan legitime mails blive afvist. Rækkefølgen er vigtig. Se også DMARC-rapporten siger fail.
Hvad bør virksomheder, webshops og bureauer kræve af en mailtjeneste?
Virksomheder bør kræve fuld mail hosting med submission, TLS og domæneautentificering. Navnet på produktet betyder mindre end de konkrete krav. En mailtjeneste bør kunne dokumentere sikker afsendelse, tydelig DNS-vejledning, stabil drift og support, der kan hjælpe med mere end oprettelse af en postkasse.
Når du vurderer leverandører, så se efter disse punkter:
- Afsendelse: SMTP Submission med autentificering til alle relevante klienter og systemer.
- Sikkerhed: TLS for adgang og afsendelse samt understøttelse af SPF, DKIM og DMARC.
- Drift: backup, overvågning, fejlsøgning og dokumenteret håndtering af leveringsproblemer.
- Support: dansk hjælp ved DNS, klientopsætning og migrering, ikke kun standardvejledninger.
- Skalerbarhed: flere brugere, aliaser, delte postkasser og integration med web og applikationer.
Driver du webshop eller kundeservice, bør mailtjenesten også fungere godt sammen med websitet. Ordrebekræftelser, nulstilling af adgangskoder og formularmails skal vurderes som en del af samme mailarkitektur, ikke som et separat problem. Det er ofte her, forskellen mellem et basalt mailhotel og reel mail hosting bliver tydeligst.
Hvilke krav stiller Gmail og andre store modtagere til din afsendelse?
De store mailmodtagere har gjort autentificering til et adgangskrav, ikke en anbefaling. Siden februar 2024 har Gmail og Yahoo krævet, at alle afsendere har SPF eller DKIM, sender over TLS og har gyldig reverse DNS (PTR) på den afsendende server. Afsendere af store mængder mail skal desuden have både SPF og DKIM, en DMARC-politik og afmelding med ét klik i markedsføringsmails. Microsoft har siden maj 2025 stillet lignende krav til afsendere af store mængder mail til Outlook.com.
Det gør forskellen mellem mailhotel og mail hosting meget konkret. Leverer din løsning kun en postkasse og et sæt MX-records, opfylder du ikke automatisk kravene, og så ender ordrebekræftelser og tilbud i spam eller bliver afvist. Det handler ikke om, hvor pæn mailen er, men om domænet kan dokumentere, at afsenderen er legitim. Se også Gmail afviser din mail.
| Krav fra store modtagere | Simpelt mailhotel | Fuld mail hosting |
|---|---|---|
| SPF eller DKIM på afsenderdomænet | Ofte kun SPF, og tit noget du selv skal oprette | Både SPF og DKIM med vejledning til DNS-posterne |
| TLS ved transmission | Varierer, og dokumentationen mangler ofte | TLS på både adgang og afsendelse som standard |
| DMARC-politik ved større volumen | Sjældent understøttet eller forklaret | Understøttet med mulighed for rapportering |
| Hjælp ved afviste mails | Typisk begrænset til postkassen | Support på DNS-, header- og leveringsniveau |
Hvorfor er SPF alene ikke nok?
En mail kan bestå SPF uden at være troværdig. SPF kontrollerer det domæne, der bruges i afsendelsen på serverniveau (MAIL FROM), og ikke nødvendigvis det domæne, modtageren ser i From-feltet. Derfor kan en mail teknisk set bestå SPF og stadig se forkert ud.
DKIM og DMARC lukker hullet. DKIM binder signaturen til dit domæne, og DMARC kræver, at mindst én af de to metoder stemmer overens med den synlige afsenderadresse. Vil du forstå detaljerne, er SPF, DKIM og DMARC forklaret for virksomheder et godt sted at starte.
Hvad betyder GDPR for valget mellem mailhotel og mail hosting?
Mail er persondata i praksis. Kundehenvendelser, ordrer, CV’er og supportsager lander i postkassen, og derfor bør du vurdere mailløsningen som en databehandling og ikke kun som en teknisk tjeneste. Sender en medarbejder til en forkert modtager, kan det være et brud på persondatasikkerheden efter GDPR, uanset hvor god serveren er.
Det stiller tre krav til dig som virksomhed:
- Vælg en leverandør, der kan dokumentere behandlingssikkerhed: dataplacering, databehandleraftale og adgangskontrol skal være på plads, før du flytter postkasser.
- Vurder, om mail overhovedet er den rigtige kanal: fortrolige eller følsomme oplysninger hører ofte hjemme i en sikker portal, ikke i en almindelig mail.
- Hav klare interne rutiner: regler for modtagere, autofuldførelse i klienten og instruktion af medarbejdere reducerer de fejl, som ingen teknik kan fange.
Et simpelt mailhotel giver sjældent hjælp til disse spørgsmål. Mail hosting med dansk support gør det lettere at få svar på, hvor data ligger, og hvordan adgang og logning håndteres, men ansvaret for, hvad du sender, ligger stadig hos dig. Se også mail i EU: hvad du skal se efter.
Hvorfor giver det mening at samle mail og web hos samme leverandør?
For webshops og bureauer med flere domæner hænger mail sjældent alene. Websitet sender ordrebekræftelser, kontaktformularer og nulstilling af adgangskoder fra samme domæne som medarbejdernes postkasser, og alle afsendere skal stå korrekt i SPF, DKIM og DMARC. Ligger web og mail hos to forskellige leverandører, ender du ofte som mellemmand, når en DNS-post skal rettes, eller en leveringsfejl skal spores.
Samler du driften ét sted, får du én support, der kan se hele kæden fra webshop til modtager. Det gør især en forskel for bureauer, der administrerer kundedomæner og skal kunne svare hurtigt, når en kunde melder om afviste mails. Omvendt kan det også være en fordel at holde dem adskilt, så et nedbrud på den ene tjeneste ikke rammer den anden. Begge dele kan fungere, når DNS er sat rigtigt op (se flyt mail og web hver for sig).
Hos Hostious findes email hosting i tre pakker: Email Lite med 5 GB pr. postkasse for 29 kr./md., Email Pro med 20 GB for 59 kr./md. og Email Enterprise med 50 GB for 99 kr./md., alle ekskl. moms. Alle har ubegrænset antal postkasser, IMAP, POP3, SMTP og webmail, spam- og virusfilter og dansk support døgnet rundt, og de kan kombineres med WordPress- og WooCommerce-hosting på samme domæne.
Mange udskyder et skift, fordi de frygter nedetid, rod i mapperne eller tab af historik. Frygten er forståelig, men det er et procesproblem, ikke et argument for at blive på en utilstrækkelig løsning. Med en gennemtestet plan står du bagefter med en opsætning, der opfylder kravene fra både modtagere og lovgivning.
Læs også
- Hub: Mail: fejl og fejlfinding – alle guides om emnet samlet ét sted
- Sådan vælger du den rigtige email hostingpakke
- Mailserver til virksomheder med høj sikkerhed
- 9 tegn på at din mailhosting skal opgraderes
- Email hosting hos Hostious – ubegrænset antal postkasser fra 29 kr./md. ekskl. moms
Ofte stillede spørgsmål om mailhotel og mail hosting
Hvad er forskellen på et mailhotel og mail hosting?
Et mailhotel giver dig postkasser på dit domæne, ofte som tillæg til et webhotel. Mail hosting er en fuld mailtjeneste med autentificeret afsendelse (SMTP), SPF, DKIM og DMARC, spamfilter og drift. Navnet afgør det ikke, indholdet gør.
Hvornår er et almindeligt mailhotel nok?
Til få postkasser med beskeden trafik og lav afhængighed. Så snart mail bærer salg, support og fakturering, bør levering, sikkerhed og gendannelse være dokumenteret, og så er du reelt ovre i mail hosting.
Kan jeg have mail og website hos hver sin udbyder?
Ja, det er helt normalt og kan være en fordel: DNS-records peger web og mail hver sit sted, og et nedbrud på den ene tjeneste rammer ikke den anden. Husk, at alle afsendere stadig skal stå i SPF og signere med DKIM.
Hvilke porte skal jeg bruge til mail?
Til modtagelse IMAP på port 993 eller POP3 på port 995, begge med TLS. Til afsendelse SMTP på port 587 med STARTTLS eller port 465 med implicit TLS, altid med login. Port 25 bruges mellem mailservere og er ofte lukket for almindelige klienter.
Udgivet 3. juli 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026