Et professionelt e-mailsystem kan køre på en platform, der deles mellem kunder, på en instans reserveret til jeres organisation eller på en server i jeres egne lokaler. Maskinens placering ændrer mindre, end man tror: det afgørende er, hvem der driver den, hvem der kan åbne en postkasse, og hvordan I kommer ud igen. Selv at hoste giver fysisk kontrol; det løser hverken driften eller alene suveræniteten.
Opdateret i oktober 20268 min. læsningOfficielle kilder angivet
Man taler ofte om »cloud« mod »on-premise«, som om der var to lejre. I praksis findes der tre driftsformer side om side, og de adskiller sig ved to spørgsmål: hvor kører maskinen, og hvem får den til at køre.
At drive et e-mailsystem vil sige at installere opdateringer, overvåge køen og diskpladsen, forny certifikater, tage backup, gendanne, reagere på en hændelse kl. 7 om morgenen og bevare domænets afsenderomdømme. At hoste er kun at levere maskinen og netværket.
Leverandøren står for hele platformen. Den deles som regel mellem flere kunder med logisk adskillelse: hver organisation ser kun sine egne domæner og postkasser, men servere, lagring og driftsteams er fælles. Det er den enkleste driftsform at komme i gang med og den billigste at holde kørende.
En instans eller en server er reserveret til jeres organisation. Jeres data ligger ikke side om side med nogen anden kundes. Leverandøren står fortsat for driften: I køber isolation, ikke en arbejdsbyrde. Denne driftsform passer til regulerede brancher, store mængder, koncerner, der vil holde deres selskaber tydeligt adskilt, eller indstillinger, som en delt platform ikke kan give en enkelt kunde.
Maskinen står hos jer, i jeres serverrum eller datacenter. Nogen skal alligevel drive den. Enten gør jeres eget team det, eller også gør en leverandør det på afstand med en adgang, som I åbner for den. Begge valg er legitime; de koster ikke det samme og giver ikke de samme garantier for genopretning.
Fem punkter skiller de tre driftsformer ad. De øvrige, som webmail eller Outlook-kompatibilitet, afhænger især af softwaren, ikke af placeringen.
| Punkt | Driftet cloud | Dedikeret | I egne lokaler |
|---|---|---|---|
| Naboskab | Delt platform, logisk adskillelse | Ingen anden kunde på instansen | Jeres netværk, jeres øvrige servere |
| Opdateringer | Leverandøren efter sin egen kalender | Leverandøren, kalenderen kan undertiden forhandles | Jeres team eller den udpegede leverandør |
| Backup | Hos leverandøren efter dennes kontrakt | Hos leverandøren, undertiden dedikeret | Skal organiseres: hvor, af hvem, uden for lokationen? |
| Hvem kan åbne en postkasse | Jeres administratorer og driftsleverandøren | Jeres administratorer og driftsleverandøren | Jeres administratorer og driftsleverandøren, hvis der er en |
| Exit | Eksport og ændring af MX | Eksport og ændring af MX | Eksport, ændring af MX og maskinen, der skal overtages eller genbruges |
På en delt platform kan en spamkampagne sendt fra en anden kundes kompromitterede konto forringe omdømmet for den fælles afsender-IP-adresse. En dedikeret instans eller en dedikeret IP-adresse isolerer denne risiko. I egne lokaler er naboen jeres eget netværk: en inficeret computer kan nå serveren, hvis den ikke er segmenteret.
Det er den linje, man udfylder for hurtigt. Den, der kan gendanne en postkasse, kan læse den, uanset driftsform. Placeringen fjerner ikke denne adgang; den ændrer kun listen over dem, der har den. De nyttige spørgsmål er derfor: hvem har administratorkontiene, er adgangene personlige og logget, og forbyder kontrakten driftsleverandøren at åbne en postkasse uden kundens anmodning. Kun end-to-end-kryptering, hvor I selv beholder den private nøgle, for eksempel med S/MIME, gør indholdet af en e-mail ulæseligt for driftsleverandøren.
Domænenavnet skal stå i jeres navn: det er dets MX-post, der udpeger den server, som modtager jeres post, og I skal kunne ændre den uden at bede om lov. Resten forberedes: eksport af postkasser i et standardformat, inklusive kalendere og kontakter, eksportfrist og sletning efter kontraktens ophør.
At placere serveren i egne lokaler besvarer et præcist spørgsmål: hvor diskene fysisk står. Guiden hvad er en suveræn cloud? minder om, at der er mindst tre tilbage: hvilket selskab står for driften, hvilken lovgivning gælder for det, og hvordan kommer man ud.
En server inden for jeres egne mure kan således forblive afhængig af omverdenen, uden at det ses:
Omvendt kan en hostet tjeneste drives af et europæisk selskab, der alene har kontrol over data, med loggede adgange og en skriftlig exitplan. Placeringen er stadig et nyttigt element, ikke mindst for fortegnelsen over behandlingsaktiviteter. Siden hosting og suverænitet beskriver de driftsformer, Klytic tilbyder.
En mindre virksomhed kan ønske kontrol uden at ville have vagtordningen. Før I flytter et e-mailsystem hjem, så lav en opgørelse over, hvad driften reelt kræver.
Eksempel. En industrivirksomhed med 60 ansatte (et tænkt tilfælde) har et serverrum og vil ikke have, at dens tegninger forlader stedet. Den installerer e-mailsystemet i egne lokaler, men overlader fjerndriften til en leverandør: opdateringer, overvågning, gendannelser. Virksomhedens it-medarbejder bevarer kontrollen med hardware og netværk. Den får den placering, den ønskede, uden selv at bære hele vagtordningen. Tilbage er at skrive ned, hvor backupperne sendes hen, og hvem der kan logge ind.
Driftet cloud passer, når I vil i gang hurtigt uden et driftsteam, og den logiske adskillelse og driftsleverandørens skriftlige forpligtelser er nok for jer.
En dedikeret instans passer, når en ordregiver, en reguleret branche eller en koncern med flere selskaber kræver, at jeres data ikke ligger side om side med nogen anden kundes, uden at I dermed vil stå for driften.
Egne lokaler passer, når data ikke må forlade stedet, når netværket skal kunne isoleres, eller når brugerkatalog og infrastruktur allerede findes og vedligeholdes.
Egne lokaler er et dårligt valg, hvis de kun skal bruges til at »være suveræn«, uden at nogen har tid til at drive systemet eller tage backup uden for lokationen.
De funktioner, der skal kræves uanset driftsform, står i hvad et professionelt e-mailsystem skal kunne. Backup og genopretning efter nedbrud behandles i backup, sletning og kontinuitet for e-mail. For at sammenligne europæiske leverandører, se vælg et europæisk e-mailsystem til virksomheden.
Kun hvis I har en grund til at beholde maskinen lokalt og nogen til at drive den, eller en udpeget leverandør, der gør det. Når det alene gælder suverænitet, betyder driftsleverandøren og kontrakten mere end placeringen.
Den fjerner naboskabet med andre kunder. Den ændrer ikke i sig selv, hvem der kan åbne en postkasse, eller backuppens kvalitet. Sammenlign disse to punkter skriftligt.
Ja, forudsat at postkasserne kan eksporteres i et standardformat, og at domænet står i jeres navn. Metoden er den samme som ved en migrering uden afbrydelse.
Nej. En sikkerhedsgateway kan placeres foran e-mailsystemet, et andet sted end det. Guiden integreret filter eller gateway forklarer dette valg.
Klytic Mail tilbydes i alle tre driftsformer: i Klytics delte arkitektur med adskillelse pr. kunde, i en dedikeret instans eller hos kunden. Uanset form driver Klytic platformen: vedligeholdelse, opdateringer, sikkerhed, overvågning og løbende driftssikring. Den dedikerede server etableres efter tilbud. Det er muligt at skifte driftsform senere.
Hosting er mulig i enhver geografisk zone, der svarer til den gældende jurisdiktion, med forbehold for tjenesternes tilgængelighed, blandt andet i Europa eller på Mauritius, eller på kundens egne servere.
Klytic Mail er e-mailsystemet. Klytic MTA er gatewayen, der filtrerer posten foran det; en blandet løsning er mulig, for eksempel filtrering hos Klytic og e-mailsystemet hos jer. Detaljerne om filteret findes i integreret filter eller gateway.
Klytics medarbejdere har ikke adgang til kundernes e-mailkonti; den tekniske adgang er kontrolleret og revideret. E-mails er krypteret i hvile med nøgler, som Klytic administrerer, hvilket beskytter lagermedierne; for indhold, som Klytic ikke kan læse, krypterer kunden end-to-end med sin egen private nøgle, for eksempel med S/MIME.
Det dækker tilbuddet ikke: et e-mailsystem, som I selv skulle drive alene uden Klytic på jeres server. Klytic er ikke SecNumCloud-kvalificeret; kræver en ordregiver det, opfylder dette tilbud ikke kravet.
Denne side beskriver en generel ramme. Den erstatter ikke en analyse af jeres kontrakt eller jeres infrastruktur.
Gennemgået i oktober 2026.
Krav, eksisterende infrastruktur, ønsket zone: en rådgiver gennemgår jeres situation og anbefaler en hostingform.
Velkomsttilbud
Uforpligtende prøvetilbud. En rådgiver ringer dig op for at forstå dine behov og klargøre dit Klytic-miljø.