Mailcow-sähköpostipalvelin: 13 Vaihetta, 3 h [2026]

Syyskuussa 2026 Suomen Kyberturvallisuuskeskus NCSC-FI raportoi ennätysmäärän Microsoft 365 -tilien murtoyrityksiä: pelkästään elokuussa 2025 ilmoituksia kertyi 70, ja koko vuoden kertymä nousi 330:een. Sähköposti on edelleen se järjestelmä, jonka kautta salasanat nollataan, laskut väärennetään ja identiteetit kaapataan. Yhä useampi pieni yritys ja tekniikasta kiinnostunut yksityishenkilö Pohjoismaissa kysyy siksi, kannattaisiko sähköposti hoitaa itse oman palvelimen kautta pilvipalvelun sijaan.

Tämä opas käy läpi, miten pystytät toimivan, salatun ja GDPR-tietoisen sähköpostipalvelimen Mailcow: dockerized -paketilla vuoden 2026 elokuussa julkaistulla Mooly-versiolla (Postfix 3.10.12, Rspamd 4.1.0, Nginx 1.30.3). Käymme läpi koko polun palvelimen valinnasta DNS-tietueisiin, roskapostisuodatukseen, varmuuskopiointiin ja toimitusvarmuuden testaukseen. Lopussa saat myös listan yleisimmistä virheistä ja valmiin vianmääritystaulukon, kun jokin ei toimi ensimmäisellä yrityksellä.

Kohderyhmänä on suomalainen tai pohjoismainen pieni yritys, yhdistys tai tekniikasta kiinnostunut ylläpitäjä, joka osaa jo käyttää komentoriviä ja hallita DNS-vyöhykettä. Et tarvitse aiempaa Postfix- tai Dovecot-kokemusta, koska Mailcow paketoi molemmat valmiiksi, mutta perustason Linux- ja Docker-tuntemus nopeuttaa asennusta huomattavasti. Koko prosessi kestää tottuneelta ylläpitäjältä noin kaksi tuntia, mutta varaa lisäaikaa DNS-tietueiden leviämiseen, joka voi kestää muutamasta minuutista muutamaan tuntiin riippuen verkkotunnuksen DNS-palvelusta.

Kannattaa olla rehellinen myös sille, mitä itsehostaus ei ratkaise. Oma palvelin ei automaattisesti tee viestiliikenteestä salattua vastaanottajan suuntaan, ellei vastaanottajakin tue TLS:ää, eikä se poista tietojenkalastelun tai tilikaappausten riskiä, jos käyttäjien salasanat ovat heikkoja tai monivaiheinen tunnistautuminen puuttuu webmailista. Se, mitä itsehostaus antaa, on suora hallinta datan sijaintiin, lokitukseen ja säilytysaikoihin, sekä riippumattomuus yhdestä ulkomaisesta pilvitoimittajasta. Näiden kahden asian erottaminen toisistaan kannattaa pitää mielessä koko oppaan ajan.

Mailcow vai jokin muu? Vertailu vaihtoehtoihin

Mailcow ei ole ainoa tapa hostata sähköpostia itse. Mail-in-a-Box, Modoboa ja Poste.io ratkaisevat saman ongelman eri painotuksilla. Mail-in-a-Box on suunnattu yhden ylläpitäjän ympäristöön: asennusskripti tekee lähes kaiken puolestasi, mutta säätövaraa on vähän. Modoboa on modulaarinen, joten kokoat kokonaisuuden itse palasista, mikä sopii, jos haluat tarkan hallinnan jokaiseen komponenttiin mutta jaksat myös ylläpitää sitä. Poste.io tarjoaa siistin selainhallinnan ja nopean käyttöönoton yhdellä kontilla, mutta lisenssi- ja yhteisötuki poikkeavat Mailcow’sta, joten ne kannattaa tarkistaa ennen tuotantokäyttöä.

Mailcow yhdistää Postfixin, Dovecotin, Rspamdin, SOGo-ryhmätyöohjelmiston ja selainpohjaisen hallintapaneelin yhdeksi Docker-kokonaisuudeksi. Se on raskaampi kuin Mail-in-a-Box, mutta antaa vastineeksi kalenterit, yhteystiedot, appien salasanat ja hienojakoisen roskapostisuodatuksen ilman erillisiä lisäosia. Juuri tästä syystä valitsimme sen tämän oppaan pohjaksi.

Ratkaisu	Vahvuus	Heikkous	Sopii parhaiten
Mailcow	Postfix, Dovecot, Rspamd, SOGo ja hallintapaneeli valmiiksi paketoituna	Vaatii vähintään 6 Gt RAMia, raskas pienelle VPS:lle	Pieni yritys tai tiimi, joka haluaa täyden ryhmätyöpaketin
Mail-in-a-Box	Yhden komennon asennus, valmiit oletusasetukset	Vähän muokattavuutta, ei yhtä laajaa hallintaa	Yksittäinen ylläpitäjä, yksinkertainen tarve
Modoboa	Modulaarinen, laajennettava, avoin lähdekoodi	Kokoonpano ja päivitykset vaativat enemmän työtä	Tekninen käyttäjä, joka haluaa räätälöidä kaiken
Poste.io	Yksi kontti, nopea käyttöönotto, selkeä webUI	Lisenssi- ja yhteisöehdot syytä tarkistaa erikseen	Nopea kokeilu tai pieni yhden domainin asennus

Vaihtoehdon valinta kannattaa tehdä sen mukaan, kuka palvelinta ylläpitää jatkossa. Jos vastuu on yhdellä henkilöllä eikä kalenteri- tai yhteystietosynkronointia tarvita, Mail-in-a-Box voi säästää huomattavasti ylläpitoaikaa yksinkertaisemmalla arkkitehtuurillaan. Mailcow taas kannattaa valita, kun organisaatio kasvaa useaan käyttäjään ja tarvitsee SOGon kaltaisen ryhmätyöpaketin, koska erillisen kalenteripalvelun liittäminen jälkikäteen on työläämpää kuin valmiiksi integroidun ratkaisun käyttöönotto heti alusta.

Mailcow’n kontit tutuksi ennen asennusta

Kannattaa ymmärtää etukäteen, mistä osista kokonaisuus koostuu, koska vianmääritys nojaa siihen tietoon. Postfix hoitaa sähköpostin lähetyksen ja vastaanoton SMTP-tasolla. Dovecot vastaa postilaatikoiden tallennuksesta ja IMAP/POP3-yhteyksistä. Rspamd tekee roskapostisuodatuksen ja DKIM-allekirjoituksen. SOGo tarjoaa selainpohjaisen webmailin sekä kalenteri- ja yhteystietosynkronoinnin. MySQL-yhteensopiva tietokanta säilöö käyttäjät ja asetukset, Redis toimii välimuistina ja viestijonona, Nginx toimii web-palvelimena ja käänteisenä proxyna, ja Ofelia hoitaa ajastetut sisäiset huoltotehtävät. ClamAV-kontti on valinnainen mutta oletuksena päällä, ja se skannaa liitetiedostot haittaohjelmien varalta.

Yksityisyys ja metatiedot: mitä oma palvelin ei poista

Oma sähköpostipalvelin ei tee viesteistä näkymättömiä muille verkon osapuolille. Jokainen SMTP-palvelin, myös Mailcow, lisää viestiin Received-otsikkorivin, joka paljastaa lähettäjän IP-osoitteen ja palvelimen sisäisen kulkureitin. Vastaanottaja, joka osaa katsoa viestin raakaotsikoita, näkee siis edelleen mistä IP-osoitteesta viesti on peräisin, vaikka itse sisältö kulkisi TLS-salattuna palvelinten välillä. Tämä ei ole Mailcow-kohtainen puute vaan SMTP-protokollan ominaisuus, joka koskee yhtä lailla suuria pilvipalveluita.

Jos lähettäjän IP-osoitteen piilottaminen vastaanottajalta on tärkeää, ainoa luotettava keino on reitittää lähtevä posti tunnetun kolmannen osapuolen SMTP-relayn kautta, jolloin Received-ketjussa näkyy relayn osoite eikä oma palvelin. Tämä ei kuitenkaan poista relaypalvelun omaa mahdollisuutta lukea viestien sisältöä, joten se on kompromissi, ei täydellinen ratkaisu. Käytännön yksityisyyshyöty omassa palvelimessa ei siis synny viestien piilottamisesta ulkopuolisilta, vaan siitä, ettei yksikään ulkopuolinen yritys säilytä, indeksoi tai analysoi viestien sisältöä omilla palvelimillaan.

Datan minimointi kannattaa suunnitella osaksi asennusta, ei jälkikäteen lisättäväksi ominaisuudeksi. Määritä hallintapaneelista, kuinka pitkään poistetut viestit säilyvät roskakorissa ennen lopullista poistoa, ja aseta lokitasolle vain se yksityiskohtaisuus, jota vianmääritys oikeasti vaatii. Yksityiskohtaiset SMTP-lokit ovat hyödyllisiä vianmäärityksessä, mutta niiden säilyttäminen loputtomiin kasvattaa turhaan sitä tietomäärää, joka pitäisi suojata ja johon rekisteröidyn oikeudet, kuten tarkastusoikeus, ulottuvat.

Esivaatimukset ennen asennusta

Mailcow’n virallinen dokumentaatio määrittää selkeät vähimmäisvaatimukset, mutta tuotantokäyttöön kannattaa varata enemmän marginaalia. Tuettuja käyttöjärjestelmiä ovat muun muassa Debian 11–13, Ubuntu 22.04 tai uudempi, AlmaLinux 8–9 ja Rocky Linux 9. OpenVZ, Virtuozzo ja LXC-pohjaiset ympäristöt eivät toimi, eikä asennusta suositella NAS-laitteille kuten Synologylle tai QNAPille.

Ubuntu 24.04 LTS tai Debian 12 ovat käytännössä turvallisimmat valinnat ensikertalaiselle, koska niillä on laajin yhteisödokumentaatio ja pisin tukisykli, mikä tarkoittaa harvempia pakotettuja käyttöjärjestelmäversiopäivityksiä palvelimen elinkaaren aikana. Vältä asentamasta muita web- tai sähköpostipalveluita samalle koneelle, sillä Mailcow olettaa hallitsevansa portit 80, 443, 25, 587 ja 993 yksin, ja rinnakkaiset palvelut johtavat lähes aina porttiristiriitoihin ensimmäisellä käynnistyskerralla.

Resurssi	Vähimmäisvaatimus	Suositus tuotannossa
CPU	1 GHz	2–4 vCPU
RAM	6 GiB + 1 GiB swap	8 GiB tai enemmän
Levytila	20 GiB ilman sähköposteja	40–80 GiB SSD käyttäjämäärästä riippuen
Docker	vähintään 24.0.0	uusin vakaa versio
Docker Compose	vähintään 2.0 (compose-plugin)	uusin vakaa versio
Verkko	staattinen julkinen IPv4	PTR-tietue kunnossa + toimiva IPv6

Tarvitset lisäksi oman verkkotunnuksen, pääsyn sen DNS-hallintaan sekä VPS- tai palvelinpalveluntarjoajan, joka sallii sähköpostiliikenteen ja pystyy asettamaan käänteisen DNS-tietueen (PTR) IP-osoitteellesi. Ilman tätä viimeistä kohtaa suurin osa vastaanottavista palvelimista hylkää tai roskapostittaa viestisi, vaikka kaikki muu olisi kunnossa.

RAM-vaatimus on korkeampi kuin useimmilla itsehostatuilla sovelluksilla, koska Mailcow käynnistää kymmeniä erillisiä kontteja: Postfix, Dovecot, Rspamd, ClamAV-virustorjunta, SOGo, MySQL-tietokanta, Redis, Nginx ja useampi apukontti hoitavat kukin oman tehtävänsä eristettynä toisistaan. ClamAV ja Rspamd ovat näistä raskaimpia muistinkäyttäjiä, joten jos palvelin jää tiukasti 6 gigatavun rajalle, ensimmäiset oireet näkyvät yleensä juuri roskapostisuodatuksen hidastumisena tai konttien satunnaisina uudelleenkäynnistyksinä kuormahuipuissa.

Palvelimen sijaintimaa kannattaa valita tietoisesti, jos GDPR-näkökulma on yksi itsehostauksen perusteista. Suomessa, Ruotsissa tai muualla EU/ETA-alueella sijaitseva konesali pitää datan, varmuuskopiot ja lokit selkeästi EU-lainsäädännön piirissä, mikä yksinkertaistaa tietosuojaselosteen ja käsittelysopimusten laatimista verrattuna siihen, että palvelin sijaitsisi EU:n ulkopuolella. Tämä ei poista tarvetta arvioida itse konesaliyhtiön sopimusehtoja ja alihankkijoita, mutta se karsii yhden merkittävän muuttujan pois yhtälöstä heti alkuun.

Vaihe 1: Valitse palveluntarjoaja ja avaa oikeat portit

Ennen kuin asennat mitään, tarkista kaksi asiaa palveluntarjoajaltasi. Ensinnäkin, saako lähtevä portti 25 olla auki? Monet pilvialustat sulkevat sen oletuksena roskapostin torjumiseksi, ja osa avaa sen vain erillisestä pyynnöstä. Toiseksi, pystyykö palveluntarjoaja asettamaan PTR-tietueen valitsemaasi hostnimeen? Jos vastaus jompaankumpaan on ei, vaihda palveluntarjoajaa ennen kuin etenet pidemmälle.

Palomuurissa tarvitset auki ainakin portit 25 (SMTP-palvelinten välinen liikenne), 587 (käyttäjien lähetys), 465 (vaihtoehtoinen SMTPS), 143 ja 993 (IMAP/IMAPS) sekä 80 ja 443 (webmail, hallinta ja Let’s Encrypt -varmenteet). Jos aiot tukea myös POP3:a, avaa lisäksi 110 ja 995. Rajaa hallintapaneelin pääsy VPN:n tai IP-suodatuksen taakse heti alusta lähtien, sillä avoimena se on houkutteleva kohde.

Näin tarkistat PTR-tietueen etukäteen

Ennen kuin allekirjoitat sopimusta tai maksat ensimmäistä laskua, testaa palveluntarjoajan lupaus käytännössä. Pyydä testi-IP tai kysy suoraan tukikanavasta, ja tarkista käänteinen tietue komennolla dig -x IP_OSOITE +short. Jos vastaus on tyhjä tai osoittaa palveluntarjoajan yleiseen oletusnimeen eikä omaan hostnimeesi, PTR ei ole vielä kunnossa eikä sähköposti toimi luotettavasti ennen kuin asia korjataan.

Kysy myös, onko IP-osoite jaettu vai oma. Jaetulla IP-osoitteella joku muu asiakas samalla palveluntarjoajalla voi pilata maineen omasta toiminnastasi riippumatta, jos hän lähettää roskapostia samasta osoitteesta. Oma, käyttämätön IPv4-osoite on hitaampi rakentaa hyvämaineiseksi alkuun, mutta pitkällä aikavälillä ennustettavampi, koska mainehistoria riippuu vain omasta lähetyskäyttäytymisestäsi.

Vaihe 2: Asenna Linux, päivitä järjestelmä ja Docker

Kun palvelin on valmis, päivitä ensin koko järjestelmä ja asenna komentorivityökalut, joita Mailcow tarvitsee asennusvaiheessa: git, openssl, curl ja jq. Sen jälkeen asennetaan Docker Engine ja Docker Compose -plugin virallisesta Docker-repositoriosta, koska jakelun oma paketti on usein liian vanha.

sudo apt update && sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg git jq openssl

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
echo "deb [signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

docker compose version

Komennon pitäisi palauttaa versio 2.0 tai uudempi. Jos saat virheen “command not found”, tarkista, että käytät docker compose -muotoa ilman väliviivaa. Vanha, erillinen docker-compose-komento ei ole enää suositeltu tapa Mailcow’n kanssa.

Docker-pohjaisuus ei ole pelkkä asennuksen kätevyystekijä, vaan myös tietoturvavalinta. Jokainen palvelu, kuten Postfix, Dovecot ja Rspamd, pyörii omassa eristetyssä kontissaan, eikä yhden komponentin haavoittuvuus automaattisesti anna pääsyä muihin osiin järjestelmää. Tämä rajaa vahingon laajuutta, jos esimerkiksi webmail-käyttöliittymästä löytyisi joskus haavoittuvuus. Isäntäkoneen käyttöjärjestelmä silti kannattaa päivittää yhtä säännöllisesti kuin Mailcow itsekin, koska Docker ei suojaa isäntäjärjestelmän omilta puutteilta.

Vaihe 3: Lataa Mailcow ja luo peruskonfiguraatio

Kloonaa virallinen mailcow-dockerized-repositorio ja aja generate_config.sh, joka kysyy hostnimen, aikavyöhykkeen ja muutaman perusasetuksen. Anna hostnimeksi täysi domain, esimerkiksi mail.example.fi, älä pelkkää palvelimen nimeä.

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

Skripti kysyy tietoja tähän tapaan:

Please enter the desired hostname for this installation (e.g. mail.example.fi): mail.example.fi
Please enter the timezone for this installation (e.g. Europe/Helsinki): Europe/Helsinki
Do you want to set default locations for your DNS records? [y/N] y

Tulos tallentuu mailcow.conf-tiedostoon. Avaa se ja tarkista erityisesti HTTP_PORT-, HTTPS_PORT- ja TZ-arvot ennen kuin jatkat. Jos palvelimella on jo joku muu palvelu portissa 80 tai 443, muuta portteja tässä vaiheessa, ei jälkikäteen.

Samassa tiedostossa kannattaa käydä läpi myös muutama muu asetus ennen ensimmäistä käynnistystä. SKIP_CLAMD=y poistaa ClamAV-virustorjunnan käytöstä, mikä säästää muistia pienellä palvelimella mutta heikentää haittaohjelmien suodatusta liitetiedostoissa. SKIP_SOGO=y jättää kalenteri- ja yhteystietopalvelun asentamatta, jos tarvitset vain sähköpostin. DBROOT- ja DBPASS-salasanat generoituvat automaattisesti, mutta tallenna ne heti turvalliseen salasananhallintaan, sillä niitä tarvitaan mahdollisessa palautuksessa.

generate_config.sh on turvallista ajaa uudelleen, jos huomaat virheen heti alussa, mutta se ylikirjoittaa olemassa olevan mailcow.conf-tiedoston kokonaan ilman varmuuskopiota. Jos olet jo ehtinyt muokata tiedostoa käsin esimerkiksi SKIP-asetusten osalta, ota siitä kopio ennen skriptin uudelleenajoa, ettet joudu tekemään samoja muutoksia kahdesti.

Vaihe 4: Käynnistä kontit ja kirjaudu ensimmäistä kertaa

Vedä ensin kaikki tarvittavat konttikuvat ja käynnistä ne taustalle. Ensimmäinen käynnistys kestää muutaman minuutin, koska tietokanta ja Rspamd alustavat itsensä.

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

Onnistuneen käynnistyksen jälkeen komento näyttää suunnilleen tältä:

NAME                                    STATUS
mailcow-dockerized-nginx-mailcow-1      Up 2 minutes (healthy)
mailcow-dockerized-postfix-mailcow-1    Up 2 minutes (healthy)
mailcow-dockerized-dovecot-mailcow-1    Up 2 minutes (healthy)
mailcow-dockerized-rspamd-mailcow-1     Up 2 minutes (healthy)
mailcow-dockerized-sogo-mailcow-1       Up 2 minutes (healthy)

Jos jokin kontti jää tilaan “restarting”, älä jatka DNS-tietueiden julkaisuun ennen kuin syy on selvitetty lokeista komennolla docker compose logs [palvelun nimi]. Kun kaikki on vihreää, avaa selaimessa https://mail.example.fi ja kirjaudu sisään oletustunnuksilla, jotka näytetään asennuksen lopussa, ja vaihda salasana heti.

Älä ota käyttöön yleisiä automaattisia konttien päivitystyökaluja, kuten Watchtoweria, Mailcow’n konttien kanssa. Mailcow’lla on oma, testattu update.sh-prosessi, joka päivittää tietokantaskeeman, konfiguraatiot ja kontit yhdessä oikeassa järjestyksessä. Ulkopuolinen automaattipäivitys voi päivittää yksittäisen kontin muista irrallaan ja rikkoa yhteensopivuuden esimerkiksi tietokannan ja Postfixin välillä.

Ensimmäisten vuorokausien aikana kannattaa seurata resurssien käyttöä tarkemmin kuin normaalisti, koska juuri silloin näkyy nopeimmin, onko palvelin alimitoitettu. Komento docker stats näyttää reaaliaikaisesti jokaisen kontin muistin- ja suorittimenkäytön, ja se on nopein tapa havaita, jos esimerkiksi Rspamd tai ClamAV kuluttaa odotettua enemmän resursseja heti alkuvaiheessa.

Vaihe 5: Julkaise A-, MX- ja SPF-tietueet

Sähköposti ei toimi ilman oikeita DNS-tietueita, eikä Mailcow voi julkaista niitä puolestasi, koska verkkotunnuksesi DNS on todennäköisesti eri palvelussa. Aloita A-tietueesta, joka osoittaa hostnimen palvelimen julkiseen IP-osoitteeseen, MX-tietueesta, joka kertoo muille palvelimille minne posti toimitetaan, ja SPF-tietueesta, joka kertoo mitkä palvelimet saavat lähettää verkkotunnuksesi nimissä.

mail.example.fi.   IN A    203.0.113.10
example.fi.         IN MX 10  mail.example.fi.
example.fi.         IN TXT  "v=spf1 mx -all"

MX-tietueen kohteen täytyy olla nimi, jolla on oma A-tietue, ei suoraan IP-osoite eikä CNAME. Jos verkkotunnuksella lähettää muitakin palveluita, esimerkiksi uutiskirjejärjestelmä tai laskutusohjelma, lisää nekin samaan SPF-riviin, muuten niiden viestit voivat päätyä roskapostiin.

DNS-tietueiden leviäminen (propagointi) kestää verkkotunnuksesi rekisterinpitäjästä riippuen muutamasta minuutista muutamaan tuntiin. Varmista tietueet ennen kuin jatkat seuraavaan vaiheeseen komennoilla dig A mail.example.fi, dig MX example.fi ja dig TXT example.fi. Jos vastaus on tyhjä pitkään sen jälkeen kun tallensit muutoksen, tarkista, ettei DNS-hallintapaneeliin ole jäänyt vanhaa, ristiriitaista tietuetta samalle nimelle.

Vaihe 6: Ota käyttöön DKIM ja DMARC

Mailcow’n hallintapaneelista löytyy kohta DKIM-avaimet, jossa luot avainparin verkkotunnukselle. Kopioi paneelin antama TXT-tietue tarkalleen sellaisenaan, koska pitkän avaimen katkeaminen väärään kohtaan rikkoo koko allekirjoituksen.

dkim._domainkey.example.fi.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
_dmarc.example.fi.           IN TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s"

Aloita DMARC aina valvontatilassa p=none. Kun raportit osoittavat viikon tai kahden jälkeen, että kaikki lailliset lähetysreitit läpäisevät SPF:n ja DKIM:in, siirry p=quarantine-tilaan ja lopulta p=reject-tilaan. Älä hyppää suoraan reject-tilaan, koska se voi hylätä myös omat, laillisiksi tarkoitetut viestisi, jos jokin lähetysreitti on jäänyt huomaamatta.

Mailcow luo DKIM-avaimet oletuksena 2048-bittisinä RSA-avaimina, mikä on tätä kirjoitettaessa yleisesti hyväksytty vähimmäistaso. Kierrätä avain kerran vuodessa tai heti, jos epäilet sen vuotaneen, luomalla uusi selector-nimi (esimerkiksi dkim2026._domainkey) vanhan rinnalle ennen kuin poistat vanhan käytöstä. DMARC-raportit (rua) kannattaa ohjata osoitteeseen, jota joku oikeasti lukee, tai käyttää ilmaista raporttien jäsennyspalvelua, koska raakamuotoiset XML-raportit ovat vaikealukuisia ilman työkalua.

DMARC-raportit saapuvat gzip-pakattuina XML-tiedostoina, yksi jokaiselta suuremmalta vastaanottavalta palvelulta vuorokaudessa. Raaka XML kertoo, mistä IP-osoitteista viestejä on lähetetty verkkotunnuksesi nimissä ja läpäisivätkö ne SPF:n ja DKIM:in. Ensimmäisillä viikoilla kannattaa lukea raportit käsin tai avata ne yksinkertaisella komentorivi-XML-katselimella, jotta näet heti, jos joku tuntematon lähde yrittää lähettää postia verkkotunnuksesi nimissä ilman lupaa.

Vaihe 7: Varmista TLS-varmenteet ja reititys porttiin 443

Mailcow hakee ja uusii Let’s Encrypt -varmenteet automaattisesti sisäänrakennetulla ACME-kontilla, kunhan portit 80 ja 443 osoittavat suoraan palvelimelle eikä niiden edessä ole toista reverse proxya, joka nappaa liikenteen ensin. Jos palvelimella pyörii jo esimerkiksi Nginx tai Apache muille sivustoille, sinun täytyy joko vapauttaa portit Mailcow’lle tai määrittää oma reverse proxy -asetus, joka ohjaa mail.example.fi-liikenteen Mailcow’n konteille.

Tarkista varmenteen tila hallintapaneelin Configuration – SSL -osiosta. Jos varmenne ei uusiudu, yleisin syy on se, että portti 80 ei ole tavoitettavissa ulkoverkosta ACME-haasteen aikana, esimerkiksi palomuurin tai toisen palvelun takia.

Jos organisaatiolla on jo oma yrityksen sisäinen varmenneviranomainen tai ostettu wildcard-varmenne, Mailcow tukee myös oman varmenteen tuontia automaattisen Let’s Encrypt -haun sijaan hallintapaneelin kautta. Tämä on hyödyllistä ympäristöissä, joissa ulospäin avoin portti 80 ei ole sallittu turvallisuuspolitiikan takia, mutta se lisää ylläpitäjän vastuulle varmenteen manuaalisen uusimisen ennen sen vanhenemista.

Vaihe 8: Lisää verkkotunnus, postilaatikot ja sähköpostiohjelmat

Kun DNS ja TLS ovat kunnossa, lisää verkkotunnus hallintapaneelin Domains-välilehdellä ja luo ensimmäinen postilaatikko. Mailcow tukee tavallisia asetuksia IMAP:lle (993), SMTP:lle (587) ja CalDAV/CardDAV-synkronoinnille kalentereille ja yhteystiedoille, joten useimmat sähköpostiohjelmat, mukaan lukien Thunderbird, Outlook ja mobiilien natiivisovellukset, löytävät asetukset automaattisesti autodiscover- ja autoconfig-tietueiden ansiosta.

Jos automaattinen tunnistus ei toimi, syötä asetukset käsin: saapuvan postin palvelin mail.example.fi portissa 993 STARTTLS/SSL, lähtevän postin palvelin sama osoite portissa 587 STARTTLS. Käyttäjätunnus on aina koko sähköpostiosoite, ei pelkkä käyttäjänimi.

Thunderbird tukee CalDAV- ja CardDAV-synkronointia natiivisti uudemmissa versioissa, mutta jos käytössä on vanhempi versio, kalenterin ja yhteystietojen liittäminen SOGoon voi vaatia erillisen lisäosan asentamisen. Apple Mail, Kalenteri ja Yhteystiedot löytävät SOGon CalDAV/CardDAV-osoitteet yleensä automaattisesti, kun tili lisätään iCloud-tilin sijaan tavallisena CalDAV-tilinä käyttäen samaa mail.example.fi-osoitetta.

Mobiililaitteilla kannattaa käyttää valmiita natiivisovelluksia (iOS Mail, Android Gmail-sovellus IMAP-tilillä tai K-9 Mail), koska ne tukevat push-ilmoituksia IMAP IDLE -toiminnon kautta ilman erillistä lisäosaa. Jos organisaatio tarvitsee myös yritystason hallinnan, kuten laitteen etätyhjennyksen, se pitää toteuttaa erillisellä mobiililaitehallinnan (MDM) ratkaisulla, koska Mailcow itsessään ei sisällä sellaista.

Vaihe 9: Viritä Rspamd-roskapostisuodatus ja tarkista IP:n maine

Rspamd tulee mukana valmiiksi järkevillä oletusasetuksilla, mutta tuore VPS:n IP-osoite voi silti olla ennestään huonomaineinen, jos joku aiempi vuokralainen on käyttänyt sitä roskapostiin. Tarkista IP:n maine ennen kuin lähetät ensimmäistäkään tuotantosähköpostia, esimerkiksi MXToolboxin estolistatyökalulla.

Rspamdin oma hallintanäkymä löytyy osoitteesta https://mail.example.fi/rspamd ja näyttää pisteytyksen jokaiselle käsitellylle viestille. Jos legitiimejä viestejä leimataan roskapostiksi, säädä kynnysarvoja hallintapaneelin kautta pikkuhiljaa, älä sammuta suodatusta kokonaan.

Rspamd sisältää myös harmaalistauksen (greylisting), joka viivyttää tuntemattomista lähteistä tulevia viestejä hetkeksi ja hylkää samalla suuren osan kertakäyttöisistä roskapostibottiverkoista, koska ne eivät yritä lähetystä uudelleen. ClamAV taas skannaa liitetiedostot tunnetuilta haittaohjelmasignatuureilta ennen kuin viesti päätyy postilaatikkoon. Molemmat toiminnot ovat päällä oletuksena, mutta kannattaa opettaa Rspamdia aktiivisesti merkitsemällä väärin luokitellut viestit roskapostiksi tai ei-roskapostiksi hallintanäkymän painikkeilla, koska järjestelmä oppii näistä merkinnöistä ajan myötä.

Rspamdin sisäinen Bayes-luokitin muuttuu tarkemmaksi mitä enemmän sille annetaan opetusdataa, joten alkuvaiheessa kannattaa käydä läpi ainakin muutama kymmenen esimerkkiä molempiin suuntiin uuden verkkotunnuksen sähköpostiliikenteestä. Ilman opetusta luokitin nojaa lähinnä yleisiin sääntöihin ja DNS-pohjaisiin estolistoihin, mikä toimii kohtuullisesti mutta ei yhtä tarkasti kuin organisaation omaan liikenteeseen sovitettu malli.

Vaihe 10: Automatisoi varmuuskopiot ja päivitykset

Mailcow’n mukana tulee helper-scripts/backup_and_restore.sh, joka varmuuskopioi postilaatikot, tietokannan, konfiguraation ja salaisuudet. Aja se ensin käsin testiksi ja lisää sen jälkeen ajastukseksi cronjobiin.

sudo /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 7 -d /mnt/mailcow-backup

# crontab -e
0 3 * * * /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 7 -d /mnt/mailcow-backup

Kopioi varmuuskopiot eri palvelimelle tai objektisäilöön, ei samalle levylle kuin tuotantopalvelin. RAID tai levykuva ei ole varmuuskopio, jos koko palvelin katoaa tai kiristyshaittaohjelma osuu samaan koneeseen. Päivitä itse Mailcow säännöllisesti update.sh-skriptillä, mieluiten kuukausittain tai heti tietoturvatiedotteiden jälkeen.

Varmuuskopio, jota ei ole koskaan palautettu testiksi, ei ole luotettava varmuuskopio. Aja backup_and_restore.sh restore -komento erilliselle testipalvelimelle vähintään pari kertaa vuodessa ja tarkista, että postilaatikot, kalenterit ja asetukset todella palautuvat käyttökelpoisina. Salaa varmuuskopiot aina, jos ne siirtyvät ulkoiselle objektisäilölle, koska ne sisältävät koko postihistorian ja mahdollisesti henkilötietoja, jolloin vuotanut varmuuskopio olisi yhtä vakava tietoturvaloukkaus kuin murto itse tuotantopalvelimelle.

cd /opt/mailcow-dockerized
sudo ./update.sh

Vaihe 11: Testaa toimitusvarmuus ennen tuotantokäyttöä

Ennen kuin siirrät oikeaa liikennettä uudelle palvelimelle, aja kolme testiä. Lähetä viesti osoitteeseen, jonka mail-tester.com antaa, ja tarkista pisteytys, joka kertoo suoraan SPF-, DKIM- ja DMARC-tulokset sekä mahdolliset estolistaosumat. Tarkista PTR- ja MX-ketju MXToolboxilla, ja jos otit DANE/TLSA-tietueen käyttöön, varmista sen oikeellisuus Verisignin DNSSEC-analysaattorilla.

Hyvä lähtökohta on pisteytys 9 tai 10 kymmenestä mail-testerissä ennen kuin lähetät ensimmäistäkään oikeaa asiakasviestiä. Jos pisteytys jää alle seitsemään, käy järjestyksessä läpi SPF, DKIM, DMARC, PTR ja IP:n maine, sillä yksikin puuttuva tai virheellinen tietue voi pudottaa pisteet romahtamispisteeseen.

Mail-testerin raportti jakautuu omiin osioihinsa SPF:lle, DKIM:lle, DMARC:lle, palvelimen mustien listojen tilanteelle ja viestin sisällön roskapostipisteytykselle. Jos yksittäinen osio näyttää punaista mutta kokonaispistemäärä on silti kohtuullinen, älä jätä sitä korjaamatta: esimerkiksi puuttuva PTR voi näyttää pieneltä miinukselta testissä mutta aiheuttaa silti suuria toimitusongelmia tiettyjen suurten sähköpostipalveluiden kanssa, jotka arvottavat käänteisen DNS:n muita tiukemmin.

IPv6, DNSSEC ja verkkotunnuksen rekisterinpitäjä

Suomalaiset .fi-verkkotunnukset ovat Traficomin ylläpitämän rekisterin alla, ja useimmat rekisterinpitäjät tukevat nykyään DNSSEC:iä suoraan hallintapaneelista. DNSSEC allekirjoittaa DNS-vastaukset kryptografisesti, mikä estää DNS-vastausten väärentämisen matkalla ja on samalla edellytys aiemmin mainitulle DANE/TLSA-suojaukselle. Jos rekisterinpitäjäsi tukee DNSSEC:iä, kannattaa ottaa se käyttöön koko domainille ennen kuin lähdet lisäämään TLSA-tietueita, koska ilman DNSSEC:iä TLSA ei tarjoa luotettavaa suojaa.

IPv6 ansaitsee oman varoituksensa. Moni VPS-palveluntarjoaja tarjoaa IPv6-osoitteen oletuksena, mutta jos AAAA-tietue julkaistaan ilman että palomuuri, PTR ja lähtevä reititys toimivat yhtä hyvin kuin IPv4:llä, osa vastaanottavista palvelimista yrittää toimittaa postin ensisijaisesti IPv6:n yli ja epäonnistuu. Turvallisin lähtökohta on testata IPv6-yhteys erikseen mail-testerillä ja MXToolboxilla ennen AAAA-tietueen julkaisua, tai jättää AAAA kokonaan pois, jos IPv6-reititystä ei ole täysin varmistettu.

Toimitusvarmuuden pitkäaikainen seuranta

Mail-tester ja MXToolbox antavat hetkellisen tilannekuvan, mutta domainin ja IP-osoitteen mainetta kannattaa seurata jatkuvasti, koska se voi muuttua ajan myötä lähetysmäärien tai yksittäisten väärinkäyttöraporttien takia. Google Postmaster Tools näyttää ilmaiseksi, miten Gmail näkee verkkotunnuksesi lähettämän postin: roskapostiksi merkitsemisen määrän, IP-maineen ja todennustulokset ajan yli, kunhan lähetysvolyymi ylittää Googlen asettaman kynnyksen. Microsoftin vastaava palvelu, Smart Network Data Services (SNDS), tarjoaa saman tyyppistä tietoa Outlook.com- ja Microsoft 365 -vastaanottajista.

Kumpikin työkalu vaatii rekisteröitymisen ja IP-osoitteen tai verkkotunnuksen omistuksen vahvistamisen DNS-tietueella. Rekisteröinti kannattaa tehdä heti ensimmäisten tuotantoviestien lähettämisen jälkeen, ei vasta ongelmien ilmetessä, koska historiadata alkaa kertyä vasta rekisteröinnin jälkeen eikä sitä voi hakea takautuvasti.

Merkitse kalenteriin muistutus tarkistaa molemmat työkalut kerran kuukaudessa, ei vain silloin kun jokin näyttää olevan vialla. Hidas, vähittäinen maineen heikkeneminen näkyy usein ensin näissä työkaluissa viikkoja ennen kuin viestit alkavat konkreettisesti kadota roskapostikansioihin, joten säännöllinen tarkistus antaa aikaa korjata syyn ennen kuin vaikutus näkyy käyttäjille asti.

Postilaatikoiden siirto vanhasta palvelusta Mailcow’hun

Jos siirryt Gmailista, Outlookista tai toiselta hostausalustalta, kannattaa käyttää imapsync-työkalua, joka kopioi viestit, kansiot ja liput IMAP-protokollan yli ilman että alkuperäinen postilaatikko poistuu käytöstä siirron ajaksi. Luo ensin kohdepostilaatikko Mailcow’hun, ja aja sen jälkeen synkronointi jokaiselle käyttäjälle erikseen.

sudo apt install -y imapsync

imapsync --host1 imap.gmail.com --ssl1 --user1 [email protected] --password1 'VANHA_SALASANA' \
  --host2 mail.example.fi --ssl2 --user2 [email protected] --password2 'UUSI_SALASANA' \
  --automap --skipcrossduplicates

Aja komento ensin ilman –dry parametria pienelle testikäyttäjälle ja tarkista, että kansiorakenne ja viestimäärät täsmäävät. Isommilla postilaatikoilla synkronointi kannattaa ajaa yön aikana, koska satojen tuhansien viestien siirto voi kestää useita tunteja riippuen molempien palvelinten nopeusrajoituksista. Jätä vanha palvelu päälle vielä pari viikkoa siirron jälkeen ja aja synkronointi uudelleen juuri ennen MX-tietueen vaihtoa, jotta siirron aikana saapuneet uudet viestit eivät jää vanhaan järjestelmään.

Gmail-tileiltä siirrettäessä tavallinen tilin salasana ei useimmiten toimi, jos tilillä on käytössä kaksivaiheinen tunnistautuminen, mikä on nykyään oletusarvoista suurimmalla osalla tileistä. Luo sen sijaan Googlen tilinhallinnasta erillinen sovelluskohtainen salasana (app password) imapsync-komentoa varten, äläkä koskaan käytä henkilökohtaista pääsalasanaa suoraan komentorivillä olevassa skriptissä. Sama koskee Microsoft 365 -tilejä, joissa moderni tunnistautuminen vaatii usein OAuth2-pohjaisen kirjautumisen perinteisen käyttäjätunnus-salasana-parin sijaan.

Valvonta, lokit ja hälytykset

Sähköpostipalvelin, jota ei valvota, ilmoittaa ongelmistaan yleensä vasta kun käyttäjät alkavat kysellä kadonneista viesteistä. Mailcow’n hallintapaneelin Logs-välilehti näyttää Postfixin, Dovecotin ja Rspamdin tapahtumat yhdessä paikassa, mutta tuotantoympäristössä kannattaa lisäksi ohjata lokit ulkoiseen valvontajärjestelmään, jotta hälytykset tulevat automaattisesti sähköpostin ulkopuolelle, esimerkiksi tekstiviestillä tai Slackiin.

Vähimmäistasona kannattaa valvoa neljää asiaa: levytilan täyttymistä (postitietokanta ja postilaatikot kasvavat jatkuvasti), TLS-varmenteen voimassaoloa, konttien terveystilaa docker compose ps -komennolla ajastettuna, sekä sitä, että portti 25 vastaa edelleen ulkopuolelta. Yksinkertaisimmillaan tämän voi toteuttaa cron-ajastetulla skriptillä, joka lähettää hälytyksen toiseen, erilliseen sähköpostiosoitteeseen tai Slack-webhookiin, jos jokin näistä tarkistuksista epäonnistuu.

Usean verkkotunnuksen ja alias-osoitteiden hallinta

Moni pieni yritys tarvitsee useamman verkkotunnuksen alle sähköpostia, esimerkiksi pääbrändin lisäksi tuotesivustolle tai kampanjasivulle. Mailcow’n hallintapaneelissa jokainen lisädomain vaatii oman DKIM-avaimensa ja omat DNS-tietueensa täsmälleen samalla tavalla kuin päädomain, mutta ne voivat jakaa saman Postfix- ja Dovecot-instanssin, joten resurssikulutus ei kasva lineaarisesti domainien määrän mukaan.

Alias-domainit (alias domains) ovat kevyempi vaihtoehto: ne osoittavat suoraan olemassa olevan domainin postilaatikoihin ilman erillisiä käyttäjätilejä, mikä sopii esimerkiksi vanhan verkkotunnuksen pitämiseen toiminnassa yrityksen nimenvaihdon jälkeen. Catch-all-osoite puolestaan kerää kaiken domainille saapuvan postin, jolle ei ole erikseen määriteltyä postilaatikkoa, yhteen paikkaan. Catch-all on kätevä lyhytaikaisessa käytössä, mutta pysyvänä ratkaisuna se houkuttelee roskapostia, koska botit kokeilevat satunnaisia osoitteita domainin alla ja jokainen niistä päätyy silti perille.

Jokaiselle lisädomainille pitää muistaa toistaa koko DNS-ketju: oma SPF-rivi (tai olemassa olevan laajennus), oma DKIM-avain omalla selector-nimellään ja oma DMARC-tietue, vaikka postilaatikot fyysisesti sijaitsisivatkin samalla palvelimella ensimmäisen domainin kanssa. Unohdettu DKIM-avain toiselle domainille on yksi yleisimmistä syistä, miksi vain osa yrityksen verkkotunnuksista toimittaa postia luotettavasti muiden toimiessa moitteettomasti.

Kuusi yleisintä sudenkuoppaa

1. Portti 25 on kiinni. Moni pilvipalvelu sulkee sen roskapostin torjumiseksi, eikä sitä aina pysty avaamaan pyynnöstä. Tarkista tämä ennen kuin valitset palveluntarjoajaa, ei sen jälkeen.
2. PTR-tietue puuttuu tai on väärä. Ilman käänteistä DNS-tietuetta suuri osa vastaanottajista hylkää tai hidastaa viestisi, vaikka SPF ja DKIM olisivat kunnossa.
3. DMARC otetaan käyttöön liian tiukkana liian aikaisin. Suora hyppy p=reject-tilaan ennen kuin kaikki laillinen lähetysliikenne on kartoitettu voi estää omat viestisi.
4. Reverse proxy -ristiriita porteissa 80 ja 443. Jos palvelimella pyörii jo toinen web-palvelu näissä porteissa, Let’s Encrypt -uusinta epäonnistuu hiljaisesti kunnes varmenne vanhenee.
5. Varmuuskopiot samalla levyllä kuin tuotanto. Jos varmuuskopio on samassa koneessa tai samassa tilissä kuin alkuperäinen data, kiristyshaittaohjelma tai laitteistovika vie molemmat kerralla.
6. Raskaan webmailin valinta pienelle palvelimelle. SOGo tarjoaa kalenterit ja yhteystiedot mutta vaatii enemmän muistia kuin kevyempi Roundcube. Jos et tarvitse ryhmätyöominaisuuksia, kevyempi vaihtoehto säästää resursseja pienellä VPS:llä.

Vianmääritys: 8 yleisintä ongelmaa

Suurin osa Mailcow-asennuksen ongelmista jakautuu kolmeen luokkaan: verkko- ja DNS-asetukset, konttien väliset ristiriidat porttien tai versioiden takia, ja toimitusvarmuuteen liittyvät maine- ja todennusongelmat. Alla oleva taulukko listaa kahdeksan yleisintä tapausta, joita tässä oppaassa on jo sivuttu, koottuna yhteen paikkaan nopeaa tarkistusta varten.

Ongelma	Todennäköinen syy	Korjaus
Viestit eivät lähde ulos	Portti 25 suljettu palveluntarjoajan toimesta	Pyydä portin avaamista tai käytä ulkoista SMTP-relayta
Viestit menevät roskapostiin	Puuttuva tai virheellinen SPF/DKIM/PTR	Tarkista kaikki kolme mail-testerillä ja korjaa yksi kerrallaan
Kontti jää tilaan restarting	Ristiriitainen portti tai virheellinen mailcow.conf-arvo	docker compose logs [palvelu] ja korjaa asetus
Let’s Encrypt -varmenne ei uusiudu	Portti 80 ei ole tavoitettavissa ACME-haasteen aikana	Vapauta portti 80 tai korjaa reverse proxy -ohjaus
Autodiscover ei löydä asetuksia sähköpostiohjelmassa	Puuttuva autoconfig/autodiscover-DNS-tietue	Lisää tietueet tai syötä IMAP/SMTP-asetukset käsin
DKIM-allekirjoitus ei täsmää	TXT-tietue katkennut kopioinnissa	Kopioi avain uudelleen kokonaisena hallintapaneelista
Sähköposti hylätään DANE-tuella varustetuilla palvelimilla	Virheellinen TLSA-tietue tai vanhentunut hash	Päivitä TLSA vastaamaan nykyistä TLS-varmennetta
Webmail tai hallintapaneeli ei avaudu päivityksen jälkeen	Kesken jäänyt update.sh tai versioristiriita konteissa	Aja update.sh loppuun asti ja käynnistä kontit uudelleen

Jos oma vianmääritys ei tuota tulosta, Mailcow-projektin GitHub-issueissa ja yhteisön keskustelupalstalla on käyty läpi suuri osa tunnetuista ongelmista, ja hakusana yhdistettynä virheilmoituksen tarkkaan tekstiin löytää usein ratkaisun nopeammin kuin oma yritys ja erehdys -kierros. Liitä vianmääritystiketin mukaan aina docker compose logs -tuloste kyseisestä palvelusta ja mailcow.conf ilman salasanoja, koska nämä kaksi tietoa riittävät useimmiten juurisyyn tunnistamiseen.

Edistyneet vinkit kokeneille ylläpitäjille

• Ota käyttöön DANE/TLSA lisäsuojaksi TLS:n päälle, mutta testaa se aina erillisellä alidomainilla ennen tuotantoa, koska virheellinen tietue estää toimituksen DANEa tukeville vastaanottajille.
• Rajoita hallintapaneelin ja SOGo-webmailin pääsy VPN:n tai sallittujen IP-osoitteiden listaan, äläkä koskaan jätä sitä avoimeksi koko internetiin ilman monivaiheista tunnistautumista.
• Käytä Sieve-suodatussääntöjä automaattiseen viestien lajitteluun ja poissaoloviesteihin ilman ulkoisia lisäosia, koska Dovecot tukee niitä suoraan.
• Jos hallinnoit useita verkkotunnuksia, hyödynnä Mailcow’n alias-domainit ja catch-all-osoitteet keskitetysti yhdestä hallintapaneelista useiden erillisten asennusten sijaan.
• Seuraa levytilaa ja muistin käyttöä erillisellä valvontatyökalulla, sillä Rspamdin ja ClamAV:n yhteiskäyttö voi yllättäen kasvattaa muistinkulutusta postimäärän kasvaessa.
• Aseta postilaatikoille kiintiöt (quota) hallintapaneelista heti alusta lähtien, jotta yksi käyttäjä ei voi täyttää koko palvelimen levytilaa isolla liitetiedostomäärällä ja kaataa muiden käyttäjien palvelua.
• Jos tarvitset korkean käytettävyyden, harkitse Dovecotin replikointia kahden palvelimen välillä tai vähintäänkin erillistä, ajantasaista tuntikohtaista varmuuskopiota nopean palautuksen mahdollistamiseksi vakavan laitteistovian sattuessa.

GDPR ja datan sijainti: milloin itsehostaus kannattaa

Oman Mailcow-palvelimen pystyttäminen ei automaattisesti tee sähköpostista GDPR-yhteensopivaa. Yhdysvaltalaisen pilvipalvelun käyttö ei sekään ole itsessään lain vastaista, mutta siihen voi liittyä kansainvälisiä tiedonsiirtoja ja alikäsittelijöitä, joita organisaation on arvioitava tapauskohtaisesti. Se, mitä oma EU- tai Pohjoismaissa sijaitseva palvelin antaa, on suorempi hallinta siitä missä data, lokit ja varmuuskopiot fyysisesti sijaitsevat, sekä riippumattomuus yhdestä ulkomaisesta toimittajasta.

Vastuu siirtyy samalla kokonaan omaksi: päivitykset, haavoittuvuudet, roskapostisuodatus, saatavuus ja tietoturvaloukkauksista ilmoittaminen jäävät ylläpitäjän vastuulle, eikä niitä voi enää sysätä pilvipalveluntarjoajan sopimusliitteeseen. Ennen päätöstä kannattaa dokumentoida, missä palvelin, backup ja lokit sijaitsevat, kuka niitä ylläpitää, ja miten rekisteröidyn oikeudet, kuten tietojen poisto-oikeus, toteutetaan käytännössä. Tämä sama kysymys nousi esiin, kun GDPR-valvonta Suomessa kirjasi ennätysmäärän tapauksia vuonna 2026: valvojat kiinnittävät yhä enemmän huomiota juuri siihen, kuka dataa oikeasti käsittelee ja missä.

GDPR:n 72 tunnin ilmoitusvelvollisuus tietoturvaloukkauksesta koskee omaa Mailcow-palvelinta yhtä lailla kuin pilvipalvelua, mutta itsehostatussa ympäristössä havaitsemisvastuu on kokonaan organisaatiolla itsellään. Pilvipalvelu saattaa huomata poikkeaman automaattisesti laajan asiakaskuntansa ansiosta, kun taas yhden yrityksen oma palvelin nojaa siihen, että joku todella lukee lokit ja hälytykset. Tämä on yksi konkreettinen syy, miksi edellisessä kappaleessa kuvattu valvonta ja lokitus ei ole valinnainen lisä vaan käytännössä osa lakisääteistä velvollisuutta reagoida ajoissa.

Jos VPS tai konesali hankitaan ulkopuoliselta toimittajalta, tarvitset myös tietojenkäsittelysopimuksen (data processing agreement) sen kanssa, koska palveluntarjoaja käsittelee henkilötietoja sisältäviä levykuvia ja varmuuskopioita puolestasi, vaikkei se pääsisikään käsiksi itse postien sisältöön. Moni pieni VPS-toimittaja tarjoaa valmiin sopimuspohjan pyynnöstä, mutta sitä ei aina löydy automaattisesti tilauksen yhteydestä, joten se kannattaa pyytää erikseen ennen palvelimen käyttöönottoa.

Valmis projekti: mitä sinulla pitäisi olla käytössä tämän oppaan jälkeen

Kun kaikki 11 vaihetta on käyty läpi, sinulla pyörii Docker-pohjainen Mailcow-asennus omalla domainilla, jossa A-, MX-, SPF-, DKIM- ja DMARC-tietueet on julkaistu ja vahvistettu, TLS-varmenne uusiutuu automaattisesti, vähintään yksi postilaatikko on liitetty sähköpostiohjelmaan IMAP/SMTP:n kautta, mail-tester-pisteytys on vähintään 9/10, ja varmuuskopiot ajetaan öisin cronilla eri sijaintiin kuin tuotantopalvelin. Tämä on realistinen, tuotantokelpoinen lähtötaso, jonka päälle on helppo lisätä lisää domaineja, käyttäjiä ja Sieve-sääntöjä sitä mukaa kuin tarve kasvaa.

Seuraa kuukausittain sekä Mailcow-projektin GitHub-julkaisusivua että virallista dokumentaatiota, jotta et jää jälkeen tietoturvapäivityksistä. Sähköpostipalvelin on jatkuva vastuu, ei kertaluontoinen asennusprojekti.

Pidä kirjaa myös siitä, mitä olet dokumentoinut muualle: mailcow.conf-tiedoston varmuuskopio, DKIM-avaimet, DNS-tietueiden lähdekopio ja varmuuskopioinnin salausavain kannattaa säilyttää salasananhallinnassa tai muualla kuin itse palvelimella. Jos palvelin tuhoutuu kokonaan, näiden tietojen avulla koko asennuksen voi rakentaa uudelleen tunneissa, kun taas ilman niitä joudutaan aloittamaan DNS-vaihe kokonaan alusta ja odottamaan uusien tietueiden leviämistä.

1. Valitse palveluntarjoaja, joka sallii portin 25 ja lupaa PTR-tietueen.
2. Asenna Linux, päivitä järjestelmä ja asenna Docker sekä Compose-plugin.
3. Lataa Mailcow ja luo peruskonfiguraatio generate_config.sh-skriptillä.
4. Käynnistä kontit ja kirjaudu hallintapaneeliin ensimmäistä kertaa.
5. Julkaise A-, MX- ja SPF-tietueet verkkotunnuksen DNS-hallinnassa.
6. Ota käyttöön DKIM ja aloita DMARC valvontatilassa p=none.
7. Varmista, että Let’s Encrypt -varmenne uusiutuu portin 443 kautta.
8. Lisää verkkotunnus, postilaatikot ja liitä sähköpostiohjelmat.
9. Viritä Rspamd-roskapostisuodatus ja tarkista IP:n maine.
10. Automatisoi varmuuskopiot cronilla ja aja update.sh säännöllisesti.
11. Testaa toimitusvarmuus mail-testerillä ennen tuotantoliikennettä.

Usein kysytyt kysymykset

Onko Mailcow ilmainen?
Kyllä, Mailcow: dockerized on avoimen lähdekoodin projekti, ja voit ajaa sen omalla palvelimella ilman lisenssimaksuja. Kulut syntyvät palvelimesta, verkkotunnuksesta ja ylläpitoajasta.

Kuinka paljon oman sähköpostipalvelimen pyörittäminen vie aikaa kuukaudessa?
Perusasennuksen jälkeen ylläpito on pääosin päivitysten ajamista ja roskapostisuodatuksen tarkkailua. Varaa silti muutama tunti kuukaudessa lokien ja varmuuskopioiden tarkistukseen sekä hieman enemmän aikaa isompien versiopäivitysten yhteydessä.

Voiko Mailcow’ta ajaa kotipalvelimella VPS:n sijaan?
Teknisesti kyllä, mutta useimmat kotiverkkoliittymät estävät portin 25 tai eivät tarjoa staattista IP-osoitetta ja PTR-tietuetta, mikä tekee toimitusvarmuudesta epäluotettavan. VPS tai konesalipalvelu on käytännössä ainoa realistinen vaihtoehto tuotantokäyttöön.

Mitä eroa on SPF:llä, DKIM:llä ja DMARC:lla?
SPF kertoo, mitkä palvelimet saavat lähettää verkkotunnuksesi nimissä. DKIM allekirjoittaa viestin kryptografisesti, jotta vastaanottaja voi todeta sen olevan muuttumaton matkalla. DMARC määrittää, mitä tehdään, jos SPF tai DKIM epäonnistuu, ja kerää raportteja näistä tapauksista.

Tekeekö oma sähköpostipalvelin yrityksestä automaattisesti GDPR-yhteensopivan?
Ei. Itsehostaus antaa enemmän suoraa hallintaa datan sijaintiin, mutta vastuu käsittelyperusteista, säilytysajoista, tietoturvaloukkausten ilmoittamisesta ja rekisteröidyn oikeuksista säilyy silti kokonaan organisaatiolla.

Mitä teen, jos mail-tester-pisteytys jää alle seitsemän?
Käy järjestyksessä läpi SPF, DKIM, DMARC, PTR-tietue ja IP:n maine. Useimmiten yksi näistä puuttuu tai on kirjoitettu väärin, ja korjaus nostaa pisteet kerralla merkittävästi.

Onko Mailcow parempi kuin Proton Mail tai Tuta yksityishenkilölle?
Ei välttämättä. Valmiit salatun sähköpostin palvelut kuten Proton Mail sopivat paremmin, jos et halua ylläpitää palvelinta itse. Mailcow kannattaa valita silloin, kun haluat oman domainin, täyden hallinnan ja olet valmis vastaamaan ylläpidosta itse tai tiiminä.

Kuinka siirrän vanhat sähköpostit Gmailista tai Outlookista Mailcow’hun?
Käytä imapsync-työkalua, joka kopioi viestit, kansiot ja liput suoraan vanhasta IMAP-tilistä uuteen ilman katkoa. Testaa siirto ensin yhdellä pienellä postilaatikolla ja aja synkronointi uudelleen juuri ennen MX-tietueen vaihtoa, jotta mitään ei jää siirron aikana kahden järjestelmän väliin.