Mange bruger ordene mailhotel og mail hosting som om de betyder det samme, men i praksis dækker de ofte to ret forskellige niveauer af maildrift. Den vigtige skillelinje er sjældent navnet på produktet, men om du kun får adgang til en postkasse, eller en fuld mailtjeneste med afsendelse, kryptering og domæneautentificering. Kort fortalt Mailhotel betyder […]
Mange bruger ordene mailhotel og mail hosting som om de betyder det samme, men i praksis dækker de ofte to ret forskellige niveauer af maildrift. Den vigtige skillelinje er sjældent navnet på produktet, men om du kun får adgang til en postkasse, eller en fuld mailtjeneste med afsendelse, kryptering og domæneautentificering.
Kort fortalt
- Mailhotel betyder ofte postkasse-adgang via IMAP eller POP, mens Mail hosting typisk dækker en fuld mailtjeneste med afsendelse via SMTP Submission, TLS og domænebeskyttelse med SPF, DKIM og DMARC.
- Den vigtigste tekniske forskel er, at IMAP ikke sender mail. Ifølge RFC 9051 bruges IMAP til adgang til beskeder, mens afsendelse håndteres separat via mail submission som beskrevet i RFC 6409.
- En sikker opsætning kræver normalt krypteret transport med STARTTLS eller implicit TLS, som samles i anbefalingerne i RFC 8314 for IMAP, POP og SMTP Submission.
- Hvis en IMAP- eller POP-klient ikke også er sat op med authenticated SMTP eller SMTP AUTH, kan brugeren ofte læse mail men ikke sende den.
- For virksomheder er forskellen praktisk: mail hosting er det rigtige valg, hvis domænet skal beskyttes mod spoofing, mails skal leveres stabilt, og flere brugere eller systemer skal sende fra samme domæne.
Det gør valget enklere: vurder løsningen efter funktioner, protokoller og sikkerhedskrav, ikke efter marketingbetegnelsen. Især virksomheder, webshops og bureauer bør se på, om mailtjenesten faktisk understøtter korrekt afsendelse, DNS-opsætning og løbende drift.
Mailhotel betyder typisk postkasser og adgang via IMAP eller POP, mens Mail hosting dækker normalt 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 postkasse-laget.
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, aliases, videresendelser og ofte logning eller support ved leveringsfejl. Mange tror, at en indbakke automatisk betyder en komplet mailtjeneste. Det gør den ikke.
Et simpelt mailhotel er nok til få brugere og lav risiko, mens mail hosting er bedre til domæner, der sender forretningkritiske mails via Microsoft 365 eller WordPress. Valget afhænger af ansvar og ikke kun pris.
Hvis du kun skal 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. Hvis webshoppen sender kvitteringer, eller et bureau sender fra kundedomæner, bliver autentificering, logik for afsendelse og leveringssikkerhed afgørende.
“Hostious.io kombinerer 24/7 dansk support med gratis og sikker migrering, hvilket er praktisk, når maildomæner og postkasser skal flyttes uden lang nedetid.”
En god tommelfingerregel er enkel: Hvis tabt eller afvist mail har 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 ofte kræver særskilt SMTP AUTH.
De 7 vigtigste forskelle handler om protokoller, sikkerhed og drift, ikke om ordvalg i en prisliste. Her er de punkter, som oftest afgør kvaliteten.
Efter en kort vurdering af behovet bør du sammenligne løsninger på disse syv områder:
Det er også her, mange sammenligninger går galt. To produkter kan koste næsten det samme, men hvis den ene løsning mangler SMTP AUTH eller korrekt DKIM-signering, er de ikke teknisk sammenlignelige.
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 først, om udbyderen nævner både modtagelse og afsendelse. Står der kun IMAP eller POP, er det et advarselstegn. En klient skal normalt også have SMTP Submission for at kunne sende.
Trin 2: Se efter porte og sikkerhed. IMAP kører ofte på 993 med implicit TLS, POP3 på 995, og submission ligger typisk på 587 med STARTTLS eller 465 med implicit TLS. Hvis disse oplysninger mangler helt, er dokumentationen ofte for tynd.
Trin 3: Kontroller, om udbyderen beskriver SPF, DKIM og DMARC. Hvis du kun får 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 modtagere vil acceptere mailen.
IMAP læser mail, POP henter mail, og SMTP Submission sender mail via godkendelse. RFC 9051 og RFC 6409 skiller de roller tydeligt ad.
IMAP er designet til adgang til postkasser på serveren. Det betyder synkronisering af mapper, læste beskeder og serverbaseret lagring. POP er enklere og henter typisk beskeder ned, ofte med færre samarbejdsfunktioner. Ingen af delene er i sig selv 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 365 beskriver netop, at POP3- og IMAP4-klienter bruger authenticated SMTP til afsendelse. Hvis SMTP AUTH er deaktiveret, kan brugeren godt læse sin mail og stadig være ude af stand til at sende.
Det er en klassisk fejl i opsætninger. Hvis du kan modtage men ikke sende, er problemet ofte ikke IMAP, men submission, autentificering eller policy på kontoen.
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. Det vil typisk sige IMAPS på 993 og POP3S på 995 samt submission på 465 eller 587 med korrekt TLS-konfiguration. Det reducerer risikoen for fejlopsætning i klienter.
Trin 2: Kontroller certifikatet og værtsnavnet. Hvis certifikatet ikke matcher 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.
“Hostious.io tager backups hver 2. time, hvilket er et konkret sikkerhedsnet, når maildata eller tilknyttede tjenester skal gendannes hurtigt.”
Trin 3: Bekræft, at både adgang og afsendelse kræver autentificering. TLS beskytter transporten, men det løser ikke alene spoofing eller fejl i domænets DNS. Mange overvurderer hængelås-ikonet. Det beskytter forbindelsen, ikke nødvendigvis afsenderens identitet.
Hvis du driver forretningskritisk mail, bør TLS ses som bundniveauet. Uden domæneautentificering er du stadig sårbar over for misbrug af dit domænenavn.
SPF, DKIM og DMARC beskytter domænet, mens TLS beskytter forbindelsen. CISA og Cloudflare 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 headers, så modtageren kan kontrollere, at indholdet stammer fra det hævdede domæne. DMARC bygger oven på SPF og DKIM og giver modtageren besked om, hvad der skal ske, hvis valideringen fejler.
Det afgørende er samspillet. Hvis du kun har SPF, men mails videresendes eller sendes fra flere systemer, kan du stadig få fejl. Hvis du har DKIM uden DMARC, mangler du politik og rapportering. Og hvis du kun har TLS, har du slet ikke håndteret domæneforfalskning.
Simple mailhoteller mangler ofte ikke teknisk mulighed, men operationel modenhed. Det betyder, at du måske selv skal 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.
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 først alt, der sender fra domænet. Det er ikke kun brugernes Outlook-klienter, men også webshop, kontaktformularer, ERP, booking og scannere. Hvis én afsender overses, opstår der stille fejl efter flytningen.
Trin 2: Sænk TTL på relevante DNS-poster i god tid og planlæg et overlap. Flyt derefter postkasser, MX-records og submission-indstillinger kontrolleret. Hvis det er muligt, så test med en sekundær konto før hele domænet skifter.
Trin 3: Valider til sidst både modtagelse, afsendelse og autentificering. Send testmails til forskellige modtagere, kontroller header for DKIM, og tjek om DMARC-policyen opfører sig som forventet.
“Hostious.io tilbyder gratis og sikker migrering, hvilket er særligt relevant ved flytning af WordPress, WooCommerce og tilknyttede mailopsætninger.”
Her er pro tipset enkelt: test en ekstern modtager, ikke kun interne adresser. Mange fejl skjules, hvis man kun sender inden for samme platform eller domæne.
De mest almindelige fejl er manglende SMTP AUTH, forkert DKIM og svag DMARC. Outlook og Microsoft 365 viser ofte 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. Microsoft dokumenterer netop, at klienter i POP- og IMAP-scenarier kan miste afsendelse, selv om resten af kontoen virker.
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 intermitterende leveringsfejl, som er svære at se uden headeranalyse.
Den tredje fejl er for slap DMARC. Hvis policyen står på none i lang tid, får du rapporter, men ingen reel håndhævelse. Hvis policyen strammes for hurtigt uden at alle afsendere er kortlagt, kan legitime mails blive afvist. Her er den rigtige rækkefølge vigtig.
Virksomheder bør kræve fuld mail hosting med submission, TLS og domæneautentificering. Hostious.io og Microsoft 365 er relevante benchmarks for, hvad markedet opfatter som seriøs drift.
Navnet på produktet betyder mindre end de konkrete krav. For en dansk virksomhed bør en mailtjeneste kunne dokumentere sikker afsendelse, tydelig DNS-vejledning, stabil drift og support, der kan hjælpe med mere end blot oprettelse af en postkasse.
“Hostious.io er GDPR-compliant og CO2-neutral med base i Aalborg, hvilket er et konkret udgangspunkt for danske virksomheder med krav til drift og databehandling.”
Når du vurderer leverandører, så se efter disse punkter:
Hvis du driver webshop eller kundeservice, bør du også kræve, at mailtjenesten fungerer godt sammen med websitet. Ordrebekræftelser, nulstilling af kodeord 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.
Tjenester
Tilmeld dig vores nyhedsbrev
