Mailcow Opsætning: Krypteret Mailserver I 13 Trin [2026]

En selvhostet mailserver lyder som noget kun systemadministratorer med for meget fritid kaster sig over. Men med Mailcow, der pakker hele mailstakken ind i Docker-containere, er springet fra “umuligt” til “et par timers arbejde” blevet markant kortere. Mailcow har netop fået sit seneste stabile udgivelse, kaldet “Mootember 2026” og udgivet 21. september 2026, med opdateringer til Unbound 1.26.1, SOGo 5.12.11 og Redis 7.4.11. Denne guide tager dig gennem hele processen: fra tomt VPS til en fuldt krypteret, GDPR-bevidst mailserver med SPF, DKIM, DMARC, TLS og DANE på plads.

Du ender med en mailserver du selv kontrollerer, uden at en tredjepart kan læse eller sælge dine mails. Det koster dig tid og løbende vedligeholdelse, men til gengæld slipper du for at stole på en udbyders datapolitik. Artiklen er bygget som en komplet, trin-for-trin opskrift med kode, konfigurationsfiler og fejlfindingstips, så du kan følge med uanset om du kører en lille VPS i København eller en hjemmeserver i garagen.

Hvorfor hoste din egen krypterede mailserver i 2026

E-mail er stadig rygraden i digital kommunikation, men langt de fleste danskere sender deres post gennem Gmail, Outlook eller en anden stor udbyder. Det betyder i praksis at en amerikansk eller global aktør opbevarer kopier af dine beskeder, metadata og kontaktmønstre. For virksomheder, der arbejder med følsomme kundedata, rejser det et spørgsmål om databehandleraftaler og tredjelandsoverførsler. For privatpersoner handler det mere om principielt at eje sine egne data.

Selvhosting løser ikke automatisk privatlivsproblemet. En mailserver du selv driver er stadig underlagt GDPR, og du bliver selv dataansvarlig for de personoplysninger, der passerer gennem den. Men du bestemmer selv hvor serveren står, hvem der har adgang til disken, og hvor lang tid logfiler opbevares. Det er den kontrol, som driver interessen for projekter som Mailcow og Mail-in-a-Box videre, især blandt udviklere og små virksomheder der ønsker uafhængighed af store cloud-udbydere.

Du kunne naturligvis også vælge en hostet, privatlivsfokuseret udbyder som Proton Mail eller Tuta i stedet for at selvhoste. Den vej kræver langt mindre drift, men du overlader stadig driften, og dermed en del af tilliden, til en ekstern part, om end en part med en klar privatlivsprofil. Fordelen ved at selvhoste med Mailcow er, at du helt eliminerer den mellemmand. Ulempen er, at du selv bærer hele ansvaret for opdateringer, overvågning og sikkerhedshærdning, hvilket denne guide går i detaljer med senere.

Krypteringslaget er også blevet stærkere de seneste år. STARTTLS, SPF, DKIM og DMARC er i dag udbredt blandt omkring 87 til 98 procent af mailservere i EU, ifølge en rapport fra EU’s Publications Office om internetstandarder for tredje kvartal 2025. Men mere avancerede beskyttelser som DNSSEC og DANE halter langt bagefter, med en udbredelse på kun cirka 5 og 3 procent. Det betyder at de fleste mails i dag er beskyttet mod aflytning undervejs, men stadig sårbare for aktive man-in-the-middle-angreb, hvis man ikke selv lægger DANE og MTA-STS ind i konfigurationen. Det er netop her denne guide lægger ekstra vægt.

Mailcow i tal: hvad er nyt i 2026-udgivelserne

Mailcow har skiftet navngivningsstil for sine udgivelser, så hver release nu hedder noget i stil med en årstid eller en måned kombineret med et komisk ko-tema, i stedet for et traditionelt versionsnummer som 1.2.3. Det gør det sværere at sammenligne versioner på afstand, men releasenoterne fortæller præcis hvad der er ændret, hvilket er det, der faktisk betyder noget, når du planlægger en opdatering.

Udgivelsen fra marts 2026, internt kaldet “Moorch 2026”, var især interessant fra et sikkerhedsperspektiv. Den introducerede tvungen opsætning af to-faktor-godkendelse og tvungen adgangskodefornyelse for administratorkonti, samt support for DNS-01-udfordringer ved certifikatudstedelse. Samtidig blev SOGo opdateret til version 5.12.5 og Rspamd til 3.14.3-1. En efterfølgende patch, 2026-03b, rettede yderligere inputvalidering i både Dovecot og webgrænsefladen.

Den nyeste udgivelse, “Mootember 2026” fra 21. september 2026, bygger videre på dette med opdateringer til Unbound 1.26.1, SOGo 5.12.11 og Redis 7.4.11. Mønsteret er klart: Mailcow-holdet prioriterer løbende sikkerhedshærdning af adminpanelet frem for store funktionstilføjelser, hvilket er præcis den slags disciplin, du vil have fra et projekt der håndterer din virksomheds e-mail. Tjek altid releasenoterne på GitHub, før du opgraderer en produktionsserver, så du ved præcis hvilke containere der genstartes og hvilke databasemigrationer der kører automatisk.

Mailcow eller Mail-in-a-Box: hvilken løsning passer dig

Der findes flere selvhostede mailstakke, men to projekter dominerer samtalen i 2026: Mailcow og Mail-in-a-Box. Begge pakker Postfix, Dovecot, spamfiltrering og webmail ind i en samlet installation, men de adskiller sig markant i filosofi. Mailcow kører som et sæt Docker-containere og giver dig et fleksibelt administrationspanel, mens Mail-in-a-Box er bygget til at være så automatiseret som muligt, direkte på værtsmaskinen uden Docker.

Egenskab	Mailcow	Mail-in-a-Box
Seneste version	Mootember 2026 (21. sep. 2026)	v76 (24. maj 2026)
Arkitektur	Docker, ca. 15 containere	Native installation på værten
Webmail	SOGo (kalender, kontakter, mail)	Roundcube
DANE/DNSSEC	Kræver manuel opsætning	Indbygget DNSSEC med DANE TLSA
Administration	Webbaseret adminpanel, meget granulær	Minimalt panel, bevidst simpelt
Anbefalet RAM	6-8 GB med SOGo og ClamAV aktiv	2-4 GB til mindre opsætninger
Krav til Docker	Docker Engine 24.0.0+, Compose 2.0+	Ikke relevant, ingen Docker

Konklusionen er enkel: vælg Mail-in-a-Box hvis du vil have den mindst mulige vedligeholdelsesbyrde og er tilfreds med en fast, opinioneret opsætning. Vælg Mailcow hvis du vil have mere kontrol, et rigere adminpanel og mulighed for at skalere til flere domæner og brugere. Denne guide fokuserer på Mailcow, fordi det er den løsning flest danske udviklere og mindre virksomheder vælger, når de vokser ud af en enkelt postkasse.

Der er også en tredje vej, som er værd at nævne kort: at bygge sin egen stak manuelt fra individuelle komponenter som Postfix, Dovecot og Rspamd, uden en samlet pakke som Mailcow eller Mail-in-a-Box. Det giver maksimal kontrol og læring, men kræver markant mere tid, både til den indledende opsætning og til løbende vedligeholdelse, fordi du selv skal holde styr på hvordan komponenterne spiller sammen ved hver opdatering. For de fleste er den tid bedre brugt på at lære Mailcows adminpanel og containerstruktur at kende i dybden, hvilket er fokus for resten af denne guide.

Forudsætninger: hardware, software og versioner

Før du går i gang, skal følgende være på plads. Mangler bare ét punkt, ender du med en mailserver, der bliver afvist af andre udbydere eller markeret som spam.

• En VPS eller dedikeret server med mindst 6-8 GB RAM, 2-4 vCPU og 80 GB SSD-lagerplads, hvis du kører SOGo og ClamAV sammen
• En statisk, offentlig IPv4-adresse hvor port 25 ikke er blokeret af udbyderen (tjek dette eksplicit, mange forbrugerudbydere og nogle cloud-pakker blokerer udgående SMTP)
• Et domæne du kontrollerer fuldt ud, med adgang til at redigere DNS-poster
• Docker Engine version 24.0.0 eller nyere
• Docker Compose version 2.0 eller nyere
• Grundlæggende Linux-pakker: git, openssl, curl, jq (tilføjet som krav fra september 2025), awk, grep og cut
• En reverse DNS-post (PTR) der matcher dit mailhostname, sat op gennem din hostingudbyder
• Mindst 30-60 minutters uafbrudt tid til selve installationen, og et par dage til DNS-propagering og renommé-opbygning bagefter

Mailcow bruger dateret versionsnavngivning i stedet for et klassisk nummerskema. Det nyeste udgivelsesspor inkluderer Postfix 3.10.12, Rspamd 4.1.0 og Nginx 1.30.3 i den release, der kom før Mootember-udgaven. Tjek altid projektets GitHub-releaseside for den helt aktuelle version, før du installerer, da Mailcow udgiver opdateringer løbende hen over året.

Et sidste, ofte overset punkt: kontrollér at din hostingudbyder tillader mailservere i deres servicevilkår. Nogle budget-VPS-udbydere forbyder eksplicit afsendelse af mail fra deres standardprodukter for at begrænse spam fra platformen, og vil lukke din konto uden varsel, hvis du overtræder det. Et kort opslag i udbyderens vilkår, eller en mail til deres support før du går i gang, sparer dig for at skulle flytte hele opsætningen midtvejs i projektet.

Trin 1-2: Klargør server, domæne og DNS

Start med at opdatere serveren og sætte hostnavnet korrekt. Mailcow er meget følsom over for forkert hostname, så sørg for at `hostname -f` returnerer det fulde domænenavn du vil bruge til mail, for eksempel mail.ditfirma.dk, ikke bare ditfirma.dk.

sudo apt update && sudo apt upgrade -y
sudo hostnamectl set-hostname mail.ditfirma.dk
echo "127.0.1.1 mail.ditfirma.dk mail" | sudo tee -a /etc/hosts
sudo apt install -y git openssl curl jq apt-transport-https ca-certificates

Derefter skal DNS-posterne på plads hos din domæneudbyder. De vigtigste poster, du skal oprette inden du installerer Mailcow, er A, MX og en indledende SPF-post. DKIM og DMARC følger, når Mailcow har genereret sin DKIM-nøgle i et senere trin.

Type	Navn	Værdi	Formål
A	mail.ditfirma.dk	Din servers IPv4	Peger mailhostnavnet mod serveren
MX	ditfirma.dk	mail.ditfirma.dk (prioritet 10)	Fortæller andre servere hvor mail skal afleveres
TXT (SPF)	ditfirma.dk	v=spf1 mx -all	Godkender hvilke servere der må sende for domænet
PTR	Din IP (reverse)	mail.ditfirma.dk	Omvendt opslag, kritisk for leveringsdygtighed
TXT (DMARC)	_dmarc.ditfirma.dk	v=DMARC1; p=quarantine; rua=mailto:[email protected]	Beder modtagere rapportere og karantænesætte svigtende mails

PTR-posten sætter du typisk gennem din hostingudbyders kontrolpanel, ikke gennem din almindelige DNS-udbyder. Spring ikke dette trin over. Uden korrekt reverse DNS bliver en stor del af dine udgående mails afvist eller lagt i spammappen hos Gmail og Outlook, uanset hvor korrekt resten af opsætningen er.

Trin 3-4: Installer Docker og hent Mailcow

Installer den nyeste Docker Engine fra Dockers officielle repository, ikke distributionens pakkeversion, som ofte er for gammel til Mailcows krav om 24.0.0 eller nyere.

curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker
docker --version
docker compose version

Når Docker kører, kloner du Mailcow fra den officielle GitHub-repo og placerer den et fast sted, for eksempel under /opt.

cd /opt
sudo git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
sudo ./generate_config.sh

Scriptet spørger efter dit fulde mailhostname (mail.ditfirma.dk), din foretrukne tidszone og om du vil bruge Rspamd eller det ældre SpamAssassin-filter (vælg Rspamd, det er standard og aktivt udviklet). Output bliver en fil kaldet mailcow.conf, der indeholder alle miljøvariabler for opsætningen.

Trin 5-6: Generér config, start containere og log ind

Åbn mailcow.conf og gennemgå nøgleværdierne, før du starter containerne. De vigtigste linjer du bør kontrollere eller justere er disse.

MAILCOW_HOSTNAME=mail.ditfirma.dk
TZ=Europe/Copenhagen
HTTP_PORT=80
HTTPS_PORT=443
SKIP_CLAMD=n
SKIP_SOGO=n
DBNAME=mailcow
DBUSER=mailcow

Lad DBPASS og øvrige hemmeligheder stå som de autogenererede værdier, med mindre du har en specifik grund til at ændre dem. Når konfigurationen ser rigtig ud, henter og starter du containerne.

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

Output fra `docker compose ps` skal vise omkring 15 containere i status “running” eller “healthy”, blandt andet postfix-mailcow, dovecot-mailcow, sogo-mailcow, rspamd-mailcow, redis-mailcow og nginx-mailcow. Hvis en container er i et genstartsloop, er det typisk fordi mailcow.conf har et skrivefejl eller fordi port 25, 80 eller 443 allerede er i brug af en anden tjeneste på serveren.

Åbn derefter https://mail.ditfirma.dk i en browser. Du bliver mødt af et selvsigneret certifikat i første omgang, det retter vi i TLS-trinnet nedenfor. Standard-login ved første opstart er brugernavn admin og kodeord moohoo, som du skal ændre øjeblikkeligt efter første login under Konfiguration, Adgang og rettigheder, Administratorkonti.

Trin 7: SPF, DKIM og DMARC trin for trin

Du har allerede lagt en grundlæggende SPF-post ind. Nu skal DKIM genereres inde fra Mailcow-panelet. Gå til Konfiguration, ARC/DKIM-nøgler, vælg dit domæne, og klik Generér nøgle. Mailcow foreslår normalt en 2048-bit RSA-nøgle, hvilket er et godt kompromis mellem sikkerhed og DNS-pakkestørrelse.

Panelet viser dig den TXT-post, du skal indsætte hos din DNS-udbyder. Den ser typisk ud som nedenfor, forkortet for læsbarhed.

dkim._domainkey.ditfirma.dk  TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Når DKIM-posten er propageret, hvilket typisk tager mellem 10 minutter og nogle timer afhængigt af din DNS-udbyders TTL, kan du stramme DMARC fra det indledende “p=quarantine” til “p=reject”, når du har bekræftet gennem DMARC-rapporter, at legitim mail passerer korrekt. Spring ikke direkte til reject fra dag ét. Du risikerer at blokere din egen legitime mail, hvis SPF eller DKIM er fejlkonfigureret, og du ikke har haft rapporterne til at fange det.

Test hele kæden med et gratis værktøj som mail-tester.com eller MXToolbox. En korrekt opsætning giver typisk en score tæt på topscore, og rapporten viser specifikt om SPF, DKIM og DMARC alle bliver valideret korrekt af modtagerens perspektiv.

Trin 8: TLS-certifikater med Let’s Encrypt

Mailcow har en indbygget ACME-klient, der automatisk henter og fornyer certifikater fra Let’s Encrypt. Fra udgivelsen i marts 2026 understøtter Mailcow også DNS-01-udfordringer, hvilket betyder du kan udstede certifikater selv for domæner, hvor port 80 ikke er tilgængelig udefra, ved at bekræfte ejerskab gennem en DNS TXT-post i stedet for en HTTP-fil.

Gå til Konfiguration, Certifikater, og kontrollér at status viser “Issued by Let’s Encrypt” i stedet for “self-signed”. Hvis det stadig viser selvsigneret efter nogle minutter, er den mest almindelige årsag at port 80 blokeres af en firewall eller en anden webserver, der allerede lytter på samme port.

# Tjek om certifikatfornyelsen kører korrekt i logs
sudo docker compose logs acme-mailcow --tail=50

# Tjek hvilket certifikat serveren faktisk serverer
openssl s_client -connect mail.ditfirma.dk:443 -servername mail.ditfirma.dk < /dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

Certifikatet fornyes automatisk hver 60-90 dage, uden at du behøver gøre noget manuelt, så længe port 80 eller din DNS-01-opsætning forbliver tilgængelig for acme-containeren.

Trin 9: MTA-STS og DANE for ekstra kryptering

SPF, DKIM, DMARC og almindelig TLS beskytter dig mod spoofing og passiv aflytning, men som nævnt tidligere beskytter almindelig opportunistisk TLS ikke mod et aktivt man-in-the-middle-angreb. Her kommer MTA-STS og DANE ind som det næste lag. MTA-STS lader dit domæne offentliggøre en politik, der kræver at afsendere validerer dit certifikat før de leverer mail, mens DANE binder dit TLS-certifikat direkte til en DNSSEC-signeret DNS-post.

Opsæt først MTA-STS ved at lægge en policy-fil på en separat subdomæne.

# Fil placeret på https://mta-sts.ditfirma.dk/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.ditfirma.dk
max_age: 604800

DANE kræver at din DNS-udbyder understøtter DNSSEC, og at du selv signerer din zone. Det er her Mail-in-a-Box har en fordel, fordi DNSSEC og DANE TLSA er indbygget og automatiseret. I Mailcow skal du selv generere TLSA-posten baseret på dit certifikat og tilføje den manuelt hos din DNS-udbyder, hvilket kræver at udbyderen understøtter DNSSEC-signering i første omgang. Givet at kun omkring 3 procent af mailservere i EU bruger DANE i dag, er dette stadig et avanceret, men voksende, differentieringspunkt for en server, der vil gå videre end gennemsnittet.

Trin 10: Opret mailbokse, brugere og tving 2FA igennem

Med infrastrukturen på plads er det tid til at oprette de faktiske postkasser. Gå til Mailboxes i Mailcow-panelet og tilføj hver bruger med navn, kvote og adgangskodepolitik. Fra 2026-opdateringen kan administratorer tvinge to-faktor-godkendelse igennem for alle brugere ved første login, hvilket lukker en af de mest almindelige svagheder i selvhostede opsætninger: svage eller genbrugte kodeord på webmail-kontoen.

• Gå til Konfiguration, Adgang og rettigheder, og aktiver “Forced password change” for nye brugere
• Aktiver TOTP-baseret 2FA under hver brugers egen kontoindstilling, eller tving det igennem centralt fra adminpanelet
• Opsæt app-specifikke kodeord til klienter som Thunderbird eller mobilens indbyggede mailapp, hvis 2FA er aktiveret på hovedkontoen
• Sæt en rimelig kvote per postkasse, så en kompromitteret konto ikke kan fylde hele disken med spam

SOGo giver brugerne kalender og kontakter sammen med webmail, så de færreste behøver en separat tjeneste til det. Hvis du ikke har brug for kalenderfunktionen, kan du spare ressourcer ved at sætte SKIP_SOGO=y i mailcow.conf, men de fleste produktionsopsætninger beholder den, fordi RAM-besparelsen er beskeden i forhold til funktionen man mister.

Trin 11-12: Test leveringsdygtighed, spamfilter og backup

Leveringsdygtighed, altså om dine mails rent faktisk lander i indbakken hos modtageren og ikke i spammappen, er typisk den sværeste del af selvhosting, langt sværere end selve installationen. Store udbydere som Gmail og Microsoft lægger ekstra mistro til nye, ukendte afsenderdomæner og IP-adresser uden historik.

Byg renommé gradvist. Send først test-mails til dig selv og kolleger, tjek resultatet med mail-tester.com, og undgå at sende store mængder mail fra en helt ny IP de første uger. Tjek om din IP allerede er opført på en blokliste, før du går i produktion.

Mange VPS-udbydere genbruger IP-blokke fra tidligere kunder, og det betyder at din “nye” IP-adresse kan have en negativ historik, allerede før du har sendt din første mail. Tjek derfor IP’en mod flere blokkelister, ikke kun en enkelt, og kontakt udbyderen om at få tildelt en anden adresse, hvis den viser sig at være belastet. Et par minutters tjek her kan spare dig dage med frustration over mails der forsvinder i spammapper uden forklaring.

# Tjek om din servers IP er på en kendt blokliste
dig +short $(curl -s ifconfig.me | awk -F. '{print $4"."$3"."$2"."$1}').zen.spamhaus.org

# Se Rspamd's statistik over klassificeret mail
sudo docker compose exec rspamd-mailcow rspamc stat

Backup er ikke optionelt for en mailserver, det er en forudsætning for at kunne kalde driften ansvarlig. Mailcow leverer et officielt backup-script, der eksporterer databaser, vhost-data og konfiguration til en ekstern mappe eller fjernserver.

cd /opt/mailcow-dockerized
sudo ./helper-scripts/backup_and_restore.sh backup all --delete-days 30 \
  /mnt/backup/mailcow

# Planlæg daglig backup via cron
echo "0 3 * * * root /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 30 /mnt/backup/mailcow" | sudo tee /etc/cron.d/mailcow-backup

Krypter backup-mappen, eller send den til en destination, der i sig selv er krypteret på disk. En ukrypteret backup af en krypteret mailserver er stadig et åbent datalæk i vente, hvis backup-disken bliver stjålet eller lækket.

Trin 13: GDPR og dansk lovgivning — dit ansvar som databehandler

At selvhoste gør dig ikke automatisk GDPR-compliant, det gør dig derimod eksplicit dataansvarlig for alt der passerer gennem serveren, inklusive navne, e-mailadresser, beskedindhold, vedhæftninger, IP-adresser og loginlogs. Du skal selv vurdere og dokumentere, hvordan du opfylder de grundlæggende principper.

• Dataminimering: gem kun de logs og mailbokse, du faktisk har brug for til drift og sikkerhed, og sæt en klar opbevaringsperiode
• Adgangskontrol: brug stærke kodeord, tving 2FA igennem for administratorer, og giv kun adgang på et need-to-know-princip
• Kryptering i transit: TLS, MTA-STS og DANE hvor det er muligt, som beskrevet i trinene ovenfor
• Krypterede backups: backup-filer skal behandles med samme sikkerhedsniveau som produktionsdataene
• Overførsler til tredjelande: tjek hvor din VPS-udbyder, antivirus-tjeneste og eventuelle supportleverandører faktisk behandler data
• Hændelsesberedskab: have en nedskrevet procedure for hvordan du opdager, dokumenterer og anmelder et databrud til Datatilsynet inden for 72 timer

Bemærk at TLS, uanset hvor godt konfigureret det er, ikke giver ende-til-ende-kryptering. Driftsoperatøren, altså dig eller den, der har root-adgang til serveren, kan stadig læse mailindholdet på disken. Hvis du har brug for reel fortrolighed i selve indholdet, ikke kun i transit, skal du lægge OpenPGP eller S/MIME oven på opsætningen, hvilket kræver at både afsender og modtager har kompatible nøgler eller certifikater.

Hvis din VPS-udbyder, antivirus-leverandør eller backup-destination behandler personoplysninger på dine vegne, skal du indgå en databehandleraftale med dem, som fastlægger formål, varighed og sikkerhedskrav for behandlingen. Det gælder, selv om udbyderen “kun” leverer infrastruktur, fordi de teknisk set stadig har mulighed for at tilgå disken, hvor dine mails ligger. Vælg om muligt en udbyder med servere placeret inden for EU eller EØS, så du undgår de juridiske komplikationer, der følger af at overføre personoplysninger til et tredjeland uden et tilstrækkelighedsniveau.

Almindelige faldgruber ved selvhostet e-mail

De fleste mislykkede selvhostingsprojekter falder på et lille antal gentagne fejl. Her er de mest udbredte, og hvordan du undgår dem.

• Blokeret port 25: Flere forbruger-VPS’er og enkelte cloud-udbydere blokerer udgående port 25 som standard mod spam. Tjek dette med din udbyder, inden du bruger timer på DNS-opsætning, ellers kan du slet ikke sende mail ud.
• Manglende eller forkert reverse DNS: En PTR-post der ikke matcher dit mailhostname sender dig direkte i spammappen hos de store udbydere, uanset hvor korrekt resten af stakken er.
• For lavt RAM-budget: Mailcow med SOGo og ClamAV aktiveret kræver realistisk 6-8 GB RAM. Forsøger du at presse det ned på 2 GB, oplever du containere der konstant genstarter eller crasher under spamfiltrering.
• DMARC sat til “reject” for tidligt: Uden at have gennemgået rapporter fra en periode med “quarantine” risikerer du at blokere din egen legitime mail, hvis SPF eller DKIM fejler i et edge case du ikke havde forudset.
• Glemt firewall-åbning for ACME: Hvis port 80 er lukket for Let’s Encrypt’s valideringstrafik, falder certifikatfornyelsen tilbage til selvsigneret, og brugere møder browseradvarsler.
• Ingen overvågning af disk og køer: En mailserver uden opsyn kan stille og roligt fylde disken med logfiler eller en ophobet sendekø, uden at nogen bemærker det før postkasserne stopper med at virke.

Fejlfinding: 8 problemer og løsninger

Når noget går i stykker, sparer en struktureret fejlfindingsproces dig for timer af gætværk. Nedenstående tabel samler de mest almindelige symptomer, deres sandsynlige årsag, og hvordan du løser dem.

Symptom	Sandsynlig årsag	Løsning
Containere genstarter i loop	Portkonflikt eller fejl i mailcow.conf	Kør `docker compose logs` på den fejlende container og tjek om port 25/80/443 allerede er i brug
Mails ender i spam hos Gmail	Manglende eller forkert PTR, ny IP uden renommé	Verificér PTR-posten, byg afsenderrenommé gradvist, tjek score på mail-tester.com
DKIM-signatur fejler valideringen	DNS-posten ikke propageret, eller forkert selector navngivet	Vent på TTL-udløb, tjek selector med `dig dkim._domainkey.ditfirma.dk TXT`
Certifikatet er stadig selvsigneret	Port 80 blokeret, eller ACME-containeren kan ikke nå Let’s Encrypt	Åbn port 80 i firewallen, tjek logs for acme-mailcow-containeren
Webmail (SOGo) svarer ikke	SOGo-containeren crashede pga. for lidt RAM	Tjek `docker stats`, overvej at skalere serveren op eller deaktivere ClamAV temporært
Udgående mail sidder fast i kø	Modtagerserveren greylister eller blokerer din IP	Tjek Postfix-køen med `postqueue -p` inde i containeren, undersøg blokeringer via MXToolbox
Kan ikke logge ind efter installation	Standard admin-kodeord ikke ændret, eller caps lock aktiv	Nulstil admin-password via `docker compose exec` og det medfølgende reset-script
DMARC-rapporter viser høj fejlrate	En legitim afsendertjeneste (f.eks. nyhedsbrev) er ikke inkluderet i SPF	Tilføj den pågældende tjenestes afsender-IP eller include-post til din SPF-record

Et fælles træk ved de fleste af disse problemer er, at de sjældent opstår i Mailcow-koden selv. De handler typisk om DNS-propagering, netværkskonfiguration hos hostingudbyderen, eller forventninger der ikke matcher hvordan andre mailservere bedømmer afsenderrenommé. Når du fejlfinder, bør du derfor altid starte med at bekræfte DNS-posterne med et eksternt værktøj, før du begynder at rode i containernes interne konfiguration. Ni ud af ti gange ligger problemet uden for selve Mailcow-installationen.

Migrering af eksisterende postkasser til din nye server

De færreste starter helt fra bar bund. De fleste flytter fra Google Workspace, Microsoft 365 eller en anden hostet udbyder, og skal have historisk mail med over i den nye postkasse uden at tabe en eneste besked. Det klassiske værktøj til den opgave er imapsync, et open source-program der kopierer mails mellem to IMAP-servere uden at flytte dem lokalt gennem en mailklient først.

imapsync \
  --host1 imap.gmail.com --ssl1 --user1 "[email protected]" --password1 "app-adgangskode" \
  --host2 mail.ditfirma.dk --ssl2 --user2 "[email protected]" --password2 "nyt-kodeord" \
  --automap --syncinternaldates --no-modulecase

Kør altid en tør-prøve med flaget –dry på en enkelt testkonto, før du migrerer samtlige medarbejdere. Planlæg migreringen i to bølger, hvis det er muligt. Først synkroniseres hele historikken, mens den gamle postkasse stadig er aktiv, og MX-posten fortsat peger på den gamle udbyder. Derefter, når synkroniseringen er bekræftet komplet, skifter du MX-posten til din nye Mailcow-server og kører en sidste, kort synkronisering for at fange de beskeder, der er kommet ind i mellemtiden.

Husk at eksportere og genimportere kalender- og kontaktdata separat, da imapsync kun håndterer selve mailprotokollen. SOGo understøtter CardDAV og CalDAV, så de fleste moderne klienter, herunder Thunderbird og mobilens indbyggede apps, kan synkronisere kontakter og kalender direkte mod den nye server, når du har opdateret serverindstillingerne i klienten.

Sikkerhedshærdning: firewall, fail2ban og adgangsbegrænsning

En mailserver, der er nået frem til produktion, er samtidig et attraktivt mål. Den har en kendt IP, kendte porte og, hvis den er dårligt konfigureret, en vej ind til resten af dit netværk. Start med at begrænse adgangen til administrationspanelet, så det kun kan nås fra kendte IP-adresser eller gennem en VPN, i stedet for at eksponere det åbent mod hele internettet.

# Eksempel: begræns adgang til Mailcow UI med ufw, kun fra kontorets IP
sudo ufw allow from 203.0.113.10 to any port 443 proto tcp
sudo ufw deny 443
sudo ufw allow 25,465,587,993/tcp

Mailcows indbyggede Fail2ban-integration overvåger login-forsøg mod SMTP, IMAP og webgrænsefladen, og blokerer automatisk IP-adresser efter et konfigurerbart antal mislykkede forsøg. Standardtærsklen er ofte fornuftig til at starte med, men i et miljø med mange legitime brugere på dynamiske IP-adresser, for eksempel medarbejdere der arbejder hjemmefra, bør du gennemgå logs efter de første uger og justere tærsklen, så den ikke unødigt låser legitime brugere ude.

Overvej også at deaktivere adgangskodebaseret login fuldstændigt for administratorkontoen, og i stedet kun tillade adgang via en klientcertifikat-beskyttet reverse proxy eller en VPN-tunnel. Det er et ekstra trin, men det fjerner en hel klasse af brute-force-angreb mod netop den konto, der har mest magt over systemet.

Avancerede tips til drift i produktion

Når grundinstallationen kører stabilt, er der en række forbedringer der adskiller en hobbyopsætning fra en der kan bære reel produktion. Først og fremmest bør du isolere mailserveren på sin egen VPS eller virtuelle maskine, i stedet for at dele værten med andre tjenester. Mailstakken rummer mange services, og et kompromitteret websted på samme vært kan i værste fald sprede sig til mailserveren.

Overvåg sendekøen og containernes ressourceforbrug automatisk, i stedet for manuelt. Et simpelt værktøj som Uptime Kuma eller Prometheus med en Docker-exporter kan give dig besked, hvis en container falder, eller hvis disken nærmer sig fuld. Sæt desuden en alarmgrænse for sendekøens størrelse, da en voksende kø typisk betyder at modtagerservere er begyndt at afvise eller forsinke din trafik.

Begræns antallet af samtidige logins per konto, og overvåg mislykkede login-forsøg gennem Mailcows indbyggede Fail2ban-integration, som automatisk blokerer IP-adresser der gentagne gange fejler autentificering. Opdater desuden Mailcow regelmæssigt, ikke kun når noget går i stykker. Projektet udgiver sikkerhedsrettelser løbende, og det seneste udgivelsesspor har specifikt skærpet krav til 2FA og adgangskodefornyelse som direkte svar på observerede angrebsmønstre mod administrationspaneler.

Endelig bør du dokumentere din egen opsætning. Skriv ned hvilke DNS-poster du har oprettet, hvorfor, og hvornår certifikater og nøgler skal fornyes eller roteres. Et selvhostingsprojekt, der kun lever i en enkelt persons hukommelse, er en risiko i sig selv, hvis den person er på ferie, når noget går i stykker.

Overvej også en sekundær MX-post hos en ekstern udbyder som et sikkerhedsnet. En sekundær MX kan modtage og køre mail midlertidigt, hvis din primære server er nede for opdatering eller går ned uventet, og derefter videresende den, når din server er tilbage online. Det er ikke strengt nødvendigt for en lille opsætning med lav risikotolerance for få minutters nedetid, men det bliver relevant i takt med at flere forretningskritiske beskeder passerer gennem serveren.

Komplet eksempelprojekt: mailcow.conf og docker-compose i praksis

For at samle det hele, her er et realistisk uddrag af en fungerende mailcow.conf til en lille virksomhed med omkring 10 postkasser, efterfulgt af de kommandoer der sætter hele stakken op fra bunden af en frisk server.

# mailcow.conf (uddrag, hemmeligheder forkortet)
MAILCOW_HOSTNAME=mail.ditfirma.dk
TZ=Europe/Copenhagen
DBNAME=mailcow
DBUSER=mailcow
DBPASS=************
DBROOT=************
HTTP_PORT=80
HTTPS_PORT=443
HTTP_BIND=0.0.0.0
HTTPS_BIND=0.0.0.0
SKIP_LETS_ENCRYPT=n
SKIP_CLAMD=n
SKIP_SOGO=n
ADDITIONAL_SAN=
[email protected]
MAILCOW_PASS_SCHEME=BLF-CRYPT

Den fulde opsætningssekvens, fra tom server til kørende mailserver, ser samlet set sådan ud.

# 1. Systemforberedelse
sudo apt update && sudo apt upgrade -y
sudo hostnamectl set-hostname mail.ditfirma.dk

# 2. Docker
curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker

# 3. Hent Mailcow
cd /opt && sudo git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized && sudo ./generate_config.sh

# 4. Start stakken
sudo docker compose pull
sudo docker compose up -d

# 5. Verificér at alt kører
sudo docker compose ps --format "table {{.Name}}\t{{.Status}}"

Et typisk output fra det sidste verifikationstrin viser hver container som “healthy”, med navne som mailcowdockerized-postfix-mailcow-1, mailcowdockerized-dovecot-mailcow-1 og mailcowdockerized-sogo-mailcow-1. Hvis du ser “unhealthy” eller “restarting” ved flere af dem samtidig, er det næsten altid et tegn på utilstrækkelig RAM eller en portkonflikt, som beskrevet i fejlfindingstabellen ovenfor. Fra her tilføjer du dine mailbokse, dine DNS-poster til SPF, DKIM og DMARC, og du har et komplet, fungerende og krypteret mailsystem, som du selv ejer fuldt ud.

Ofte stillede spørgsmål

Er det lovligt at selvhoste en mailserver for en dansk virksomhed?
Ja, der er ingen lov der forbyder det. Men du bliver selv dataansvarlig efter GDPR for alle personoplysninger, der passerer gennem serveren, og skal kunne dokumentere dine tekniske og organisatoriske sikkerhedsforanstaltninger.

Hvor meget tid tager det at sætte Mailcow op fra bunden?
Selve installationen tager typisk 60 til 90 minutter, inklusive DNS-opsætning. Byg dog med mindst et par dage til uge, før serveren har opbygget nok afsenderrenommé til at mail konsekvent lander i indbakken hos store udbydere.

Kan jeg køre Mailcow på en billig VPS med 2 GB RAM?
Det er muligt, men ikke anbefalet, hvis du kører SOGo og ClamAV samtidig. Realistisk bør du budgettere med 6 til 8 GB RAM for en stabil drift med fuld funktionalitet.

Giver TLS og DKIM ende-til-ende-kryptering af mit mailindhold?
Nej. TLS beskytter mail under transport mellem servere, og DKIM beskytter afsenderens autenticitet. Ingen af de to forhindrer en serveroperatør i at læse indholdet på disken. For reel fortrolighed af selve indholdet skal du tilføje OpenPGP eller S/MIME.

Hvorfor lander mine mails i spam selv efter korrekt SPF og DKIM?
Den mest almindelige årsag er en ny IP-adresse uden afsenderrenommé, eller en manglende reverse DNS-post (PTR). Begge opbygges og rettes over tid og gennem verifikation, ikke øjeblikkeligt.

Skal jeg vælge Mailcow eller Mail-in-a-Box som nybegynder?
Mail-in-a-Box er typisk nemmere for en komplet nybegynder, fordi DNSSEC og DANE er indbygget og kræver mindre manuel konfiguration. Mailcow giver mere kontrol og skalerbarhed, men kræver at du selv forstår Docker og DNS i dybden.

Hvor ofte skal jeg opdatere Mailcow?
Tjek for nye udgivelser på GitHub mindst hver måned, og opdatér hurtigt når en udgivelse indeholder sikkerhedsrettelser, som den seneste der indførte tvunget 2FA og adgangskodefornyelse.

Hvad sker der med mine mails, hvis serveren går ned?
Afsenderens server forsøger normalt at levere igen i op til flere dage, så kortvarig nedetid giver typisk ikke dataforlis. Men uden en krypteret backup-rutine, som beskrevet i guiden, risikerer du permanent at tabe postkasseindhold ved et diskhavari.

Kan jeg køre flere domæner på samme Mailcow-installation?
Ja. Mailcow er bygget til multi-domæne fra start, så du kan tilføje så mange domæner du ønsker under samme installation, hver med sine egne mailbokse, DKIM-nøgler og SPF/DMARC-poster. Det gør det oplagt for bureauer og konsulenter, der administrerer mail for flere kunder fra en enkelt server.