Jak krok po kroku zainstalować i zabezpieczyć serwer pocztowy Postfix i Dovecot na VPS

Założenia, wymagania i ograniczenia własnego serwera pocztowego

Po co w ogóle własny serwer pocztowy?

Własny serwer pocztowy Postfix i Dovecot na VPS daje przede wszystkim pełną kontrolę nad danymi. Treść wiadomości, logi, kopie zapasowe – wszystko zostaje na Twoim serwerze, bez pośredników i niewidocznych mechanizmów analitycznych dużych dostawców. Dla wielu firm i projektów ma to kluczowe znaczenie z punktu widzenia poufności, zgodności z regulacjami i wymagań klienta.

Drugi aspekt to elastyczność konfiguracji. Możesz dobrać dokładnie takie komponenty, jakie są potrzebne: dodatkowy filtr antyspamowy, archiwizację, szyfrowanie transportowe, mechanizmy greylistingu, integrację z własnymi aplikacjami. Na zewnętrznych platformach zwykle dostosowujesz się do tego, co jest dostępne, a tu budujesz środowisko pod siebie.

Trzecia zaleta to koszty i skalowanie. Przy kilku czy kilkunastu skrzynkach biznesowych abonamenty SaaS są wygodne. Gdy jednak masz kilkadziesiąt lub kilkaset kont (np. dla społeczności, stowarzyszenia, klientów), własny serwer na VPS może być tańszy, o ile dysponujesz kompetencjami admina lub gotowością, aby się ich nauczyć.

Własny serwer poczty dobrze sprawdza się także w środowiskach testowych i R&D. Można na nim bezpiecznie sprawdzać zachowanie aplikacji wysyłających e-maile, testować szablony transakcyjne, mechanizmy SPF/DKIM/DMARC, bez ryzyka zablokowania konta u dostawcy z powodu testów.

Wymagania techniczne i organizacyjne

Podstawą jest stabilny VPS z publicznym adresem IPv4. IPv6 jest mile widziane, ale wielu odbiorców wciąż opiera się głównie na IPv4. Minimalna konfiguracja to zwykle:

• RAM: 1 GB (na mały serwer testowy) lub 2 GB i więcej dla kilku–kilkunastu aktywnych użytkowników,
• CPU: 1 vCPU wystarczy na start, lepiej 2, jeśli planujesz skanowanie antyspamowe/antywirusowe,
• dysk: od 20 GB w górę, w zależności od wielkości skrzynek (poczta lubi rosnąć),
• system: stabilna dystrybucja Linuksa, np. Debian stable lub Ubuntu LTS.

Technicznie potrzebna jest domena, nad którą masz pełną kontrolę DNS (możliwość edycji rekordów A, AAAA, MX, TXT i PTR po stronie dostawcy IP). Bez działającej domeny z poprawnymi rekordami pocztowymi nie będzie mowy o wiarygodnej wysyłce i odbiorze maili.

Od strony organizacyjnej wypada uwzględnić:

• stałą administrację i monitoring – aktualizacje systemu, logi, reagowanie na problemy,
• procedury backupu – kopie skrzynek i konfiguracji, testy odtwarzania,
• zasady tworzenia kont – kto ma dostęp, jak generowane są hasła, jak długo żyją skrzynki,
• kontakt techniczny – adres abuse/hostmaster, pod który mogą pisać inne serwery w razie nadużyć.

Jeżeli serwer pocztowy ma obsługiwać klientów zewnętrznych (np. projekt hostingowy), trzeba także przygotować politykę korzystania z usług i zapis dotyczący spamowania oraz konsekwencji nadużyć, bo reputację IP niszczy czasem jeden nieuczciwy użytkownik.

Gdzie leży granica – kiedy zostać przy zewnętrznej usłudze

Własny serwer pocztowy nie będzie idealny dla wszystkich. Jeżeli:

• masz kilka kont pocztowych dla małej firmy i brak osoby technicznej,
• kluczowe jest wysokie SLA i wsparcie 24/7,
• komunikacja jest krytyczna biznesowo, a budżet mały,

to usługi typu Microsoft 365, Google Workspace lub dobre hostingowe skrzynki pocztowe będą bezpieczniejszym wyborem. Dostawca bierze na siebie reputację IP, redundantną infrastrukturę, filtry antyspamowe i reagowanie na incydenty.

Własny serwer sensownie wypada w scenariuszach:

• mała/średnia firma z techniczną osobą na pokładzie lub zaufanym administratorem,
• projekty hobbystyczne i edukacyjne – świetne pole do nauki,
• środowiska deweloperskie – integracja z aplikacjami, testy wysyłki,
• specjalne wymagania prawne – pełna kontrola danych, brak zewnętrznej chmury.

Prosty filtr: jeśli konfiguracja Postfixa i Dovecota wydaje się całkowicie „magiczna” i nie chcesz wchodzić w logi i dokumentację, lepiej zostać przy gotowych usługach. Jeśli natomiast akceptujesz, że konfiguracja poczty to proces, który wymaga nauki i regularnej opieki, własny serwer na VPS jest dobrym kierunkiem.

Przygotowanie środowiska VPS i domeny

Wybór systemu i dostawcy VPS

Do konfiguracji serwera pocztowego idealnie nadaje się Debian stable lub Ubuntu Server LTS. Obie dystrybucje oferują:

• długie wsparcie bezpieczeństwa,
• aktualne pakiety Postfix i Dovecot,
• dużo przykładów konfiguracji i poradników w sieci.

Przy wyborze dostawcy VPS sprawdź:

• czy port 25 (SMTP) jest odblokowany dla wychodzącej poczty (część dostawców go blokuje),
• czy możesz samodzielnie ustawić PTR (reverse DNS) dla adresu IP,
• czy IP jest „świeże”, tzn. nie znajduje się już na czarnych listach (RBL),
• czy serwer ma stabilne łącze i nie jest w segmencie „mass mailing/low reputation”.

W praktyce dobrze sprawdzają się dostawcy, którzy nie są najtańsi na rynku, ale oferują uczciwe wsparcie i własną infrastrukturę sieciową. Przy ekstremalnie tanich VPS-ach łatwiej trafić na adresy IP o słabej reputacji i większe ryzyko problemów z dostarczalnością.

Wstępna konfiguracja serwera: SSH, hostname, strefa czasowa

Po utworzeniu VPS zaloguj się przez SSH jako root lub użytkownik z uprawnieniami sudo. Pierwszym krokiem jest zabezpieczenie dostępu SSH:

1. Wygeneruj klucz na swoim komputerze:

   ssh-keygen -t ed25519 -C "twoj_klucz_do_vps"

2. Dodaj klucz do ~/.ssh/authorized_keys na serwerze.
3. Edytuj /etc/ssh/sshd_config i ustaw:

   PasswordAuthentication no
   PermitRootLogin prohibit-password

4. Opcjonalnie zmień port SSH, ale nie jest to obowiązkowe zabezpieczenie.

Następnie ustaw hostname serwera na pełną nazwę FQDN, np. mail.twojadomena.pl:

hostnamectl set-hostname mail.twojadomena.pl

Sprawdź, czy nazwa jest poprawnie widoczna:

hostname
hostname -f

Dobrą praktyką jest konfiguracja poprawnej strefy czasowej, aby logi poczty miały spójne czasy:

timedatectl set-timezone Europe/Warsaw
timedatectl status

Na koniec wykonaj aktualizację systemu:

apt update
apt upgrade

oraz zainstaluj kilka podstawowych narzędzi diagnostycznych, które przydadzą się później:

apt install vim nano htop net-tools dnsutils mailutils swaks

Przygotowanie domeny i podstawowych rekordów DNS

Domena musi kierować na serwer pocztowy i jednoznacznie wskazywać, który host obsługuje pocztę. Minimalnie potrzebne są:

• rekord A dla hosta pocztowego, np.:

  mail.twojadomena.pl.   A   203.0.113.10

• rekord MX dla domeny:

  twojadomena.pl.   MX 10 mail.twojadomena.pl.

Jeśli VPS ma także adres IPv6, dodaj rekord AAAA:

mail.twojadomena.pl.   AAAA 2001:db8::1234

Kluczowy jest również reverse DNS (PTR) – musi wskazywać na ten sam FQDN, który ustawisz w Postfix, np. mail.twojadomena.pl. Ten rekord zwykle ustawia się w panelu dostawcy VPS dla danego IP. Brak PTR lub PTR wskazujący na losową nazwę drastycznie obniża szanse na dostarczanie poczty do większych providerów.

Po zmianach w DNS sprawdź rekordy z innego hosta lub lokalnego komputera:

dig A mail.twojadomena.pl
dig MX twojadomena.pl
dig -x 203.0.113.10

Gdy A, MX i PTR są spójne (A i PTR wskazują ten sam host, a MX na ten host), można przejść dalej. Propagacja DNS z reguły trwa od kilku minut do godziny przy niskich wartościach TTL.

Instalacja i podstawowa konfiguracja Postfix

Instalacja pakietów Postfix i narzędzi pomocniczych

Na Debianie/Ubuntu Postfix jest dostępny bezpośrednio w repozytoriach. Zainstaluj go wraz z kilkoma dodatkowymi narzędziami:

apt install postfix postfix-doc libsasl2-modules ca-certificates

Podczas instalacji kreator zapyta o typ instalacji – dla klasycznego serwera wybierz Internet Site, a jako System mail name podaj główną domenę, np. twojadomena.pl. Tę wartość później doprecyzujesz w main.cf.

Po instalacji Postfix uruchamia proces master i podstawowe usługi (SMTP na porcie 25). Status sprawdzisz poleceniem:

systemctl status postfix

Dobrym nawykiem jest też instalacja pakietu swaks, który przyda się do testowania wysyłki SMTP (często już zainstalowany, jeśli wykonałeś wcześniejsze polecenie):

swaks --version

Główne pliki konfiguracyjne i podstawowe parametry Postfix

Konfiguracja Postfix opiera się głównie na dwóch plikach:

• /etc/postfix/main.cf – ustawienia globalne (parametry serwera),
• /etc/postfix/master.cf – definicje usług (jakie procesy i na jakich portach działają).

Warto znać polecenie postconf, które wyświetla aktualne parametry:

postconf | less
postconf myhostname
postconf -n   # tylko niestandardowe parametry

Minimalne kluczowe parametry, które trzeba dostosować, to:

• myhostname – FQDN serwera pocztowego:

  myhostname = mail.twojadomena.pl

• myorigin – domena, która będzie dodawana do lokalnych adresów:

  myorigin = /etc/mailname

  lub wprost:

  myorigin = twojadomena.pl

• mydestination – lista domen, dla których serwer przyjmuje pocztę jako lokalną:

  mydestination = $myhostname, localhost.$mydomain, localhost, twojadomena.pl

• mynetworks – sieci, które mogą wysyłać bez uwierzytelniania (w środowisku produkcyjnym powinno być bardzo restrykcyjne):

  mynetworks = 127.0.0.0/8 [::1]/128

• relayhost – jeśli chcesz wysyłać przez zewnętrzny serwer (opcjonalne, zwykle puste).

Fragment przykładowej, minimalistycznej konfiguracji main.cf dla startu może wyglądać tak:

myhostname = mail.twojadomena.pl
mydomain = twojadomena.pl
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mynetworks = 127.0.0.0/8 [::1]/128
inet_interfaces = all
inet_protocols = ipv4
home_mailbox = Maildir/

Parametr home_mailbox = Maildir/ wymusza tworzenie katalogu Maildir w katalogu domowym użytkownika, co będzie spójne z Dovecotem, jeśli wybierzesz ten format skrzynek. Po każdej edycji konfiguracji trzeba przeładować Postfix:

systemctl reload postfix

Obsługa domeny i lokalnych użytkowników

Na starcie najprościej oprzeć się o kontach systemowych. Każdy użytkownik w systemie Unix otrzyma swoją skrzynkę pocztową. Dodaj konto, np. dla użytkownika jan:

adduser jan

Po zalogowaniu na konto jan i pierwszym odbiorze/wysłaniu wiadomości w katalogu domowym pojawi się katalog Maildir. W lokalnym systemie możesz wysłać testowego maila:

echo "Test lokalnej poczty" | mail -s "Test" jan

Następnie zaloguj się jako jan i sprawdź, czy wiadomość pojawiła się w katalogu ~/Maildir/new. Jeśli używasz klasycznego formatu mbox (bez home_mailbox = Maildir/), poczta trafi do /var/mail/jan. Dla dalszej integracji z Dovecotem wygodniejszy będzie jednak Maildir – lepiej przełączyć się na niego od razu, zanim na serwerze pojawi się większa ilość poczty.

Prosty scenariusz z kontami systemowymi ma dwie podstawowe zalety: łatwo go debugować (każdy użytkownik ma normalne konto SSH) i nie wymaga dodatkowej bazy danych ani panelu. Minusem jest to, że liczba skrzynek praktycznie pokrywa się z liczbą użytkowników systemu, więc przy kilkudziesięciu domenach i setkach kont robi się to niewygodne w utrzymaniu. Jeśli celem jest mały serwer dla jednej–dwóch domen i kilku skrzynek, ten model w zupełności wystarczy.

Przy kilku domenach i większej liczbie użytkowników lepszym rozwiązaniem są skrzynki wirtualne (virtual mailboxes) w oparciu o bazę SQL lub pliki map. Postfix obsługuje taki tryb bardzo elastycznie, ale konfiguracja jest bardziej złożona: dochodzi warstwa mapowania adresów e-mail na katalogi pocztowe, integracja z Dovecotem jako LDA/LMTP i osobne hasła w bazie. Jeżeli w przyszłości przewidywany jest wzrost liczby kont, dobrze już na etapie planowania zdecydować, czy pozostać przy kontach systemowych, czy od razu zaprojektować układ pod wirtualne domeny.

Niezależnie od wybranego modelu obsługi użytkowników, fundament pozostaje ten sam: spójne DNS (A/MX/PTR), poprawnie ustawiony myhostname, sensownie ograniczone mynetworks oraz prosty, przejrzysty main.cf. Na takim szkielecie da się bez większych komplikacji dobudować Dovecota, uwierzytelnianie SASL i późniejsze mechanizmy ochronne (TLS, SPF, DKIM, DMARC), a serwer pocztowy pozostanie zrozumiały w utrzymaniu, także po kilku miesiącach przerwy od administracji.

Włączanie TLS w Postfix (podstawowe szyfrowanie SMTP)

Po uruchomieniu gołego Postfixa ruch SMTP między serwerami oraz klientami a serwerem leci jawnym tekstem. Pierwszy krok zabezpieczania to włączenie TLS, najlepiej od razu z użyciem certyfikatu z Let’s Encrypt.

Pozyskanie certyfikatu Let’s Encrypt

Najprostsza droga na Debianie/Ubuntu to certbot w trybie standalone lub z integracją z nginx/apache, jeśli już działają. W przykładzie założenie jest takie, że serwer pocztowy słucha na porcie 25/587/465, a HTTP (80) można na chwilę przejąć na potrzeby walidacji:

apt install certbot
systemctl stop nginx apache2 2>/dev/null || true

certbot certonly --standalone -d mail.twojadomena.pl

systemctl start nginx apache2 2>/dev/null || true

Po poprawnej walidacji certyfikaty trafią zwykle do:

/etc/letsencrypt/live/mail.twojadomena.pl/fullchain.pem
/etc/letsencrypt/live/mail.twojadomena.pl/privkey.pem

Ścieżki będą używane wspólnie przez Postfix i Dovecot. Należy zapewnić im odpowiednie uprawnienia odczytu (dla użytkowników postfix i dovecot), ale nie pełny dostęp dla wszystkich:

chmod 750 /etc/letsencrypt/live/mail.twojadomena.pl
chgrp postfix /etc/letsencrypt/live/mail.twojadomena.pl
chgrp dovecot /etc/letsencrypt/live/mail.twojadomena.pl

Przy automatycznym odnowieniu certyfikatu (cron/timer certbot) przyda się hak do przeładowania usług poczty. Przykład w /etc/letsencrypt/renewal-hooks/post/haproxy-postfix-dovecot.sh:

#!/bin/sh
systemctl reload postfix
systemctl reload dovecot

Plik trzeba oznaczyć jako wykonywalny:

chmod +x /etc/letsencrypt/renewal-hooks/post/haproxy-postfix-dovecot.sh

Podstawowa konfiguracja TLS w Postfix

Teraz konfiguracja TLS po stronie MTA. W /etc/postfix/main.cf trzeba dopisać (lub nadpisać) sekcję:

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.twojadomena.pl/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.twojadomena.pl/privkey.pem
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtp_tls_loglevel = 1
tls_preempt_cipherlist = yes

smtpd_tls_security_level = may oznacza, że serwer oferuje STARTTLS, ale akceptuje również połączenia bez szyfrowania (z historycznymi serwerami). smtpd_tls_auth_only = yes pilnuje, żeby uwierzytelnianie użytkownika (SASL) odbywało się wyłącznie w sesjach szyfrowanych.

Po edycji konfiguracji:

postfix check
systemctl reload postfix

Działanie można szybko zweryfikować:

swaks --server mail.twojadomena.pl --port 25 --ehlo mailtest --tls

Jeśli negocjacja TLS przebiegnie poprawnie, w logu (/var/log/mail.log lub /var/log/syslog) pojawią się wpisy o ustanowionym połączeniu TLS, w tym nazwa użytego certyfikatu i zestaw szyfrów.

Przygotowanie portów submission i SMTPS (587/465)

Przy pracy z klientami pocztowymi (Thunderbird, Outlook, aplikacje mobilne) ruch wychodzący nie powinien iść bezpośrednio na port 25 – wiele sieci blokuje ten port. Klasyczna konfiguracja obejmuje port 587 (submission z STARTTLS) i opcjonalnie 465 (SMTPS – TLS od razu po połączeniu).

Definicje usług w master.cf

Otwórz /etc/postfix/master.cf i odkomentuj lub dodaj wpisy:

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

Najważniejsze elementy:

• smtpd_tls_security_level=encrypt – wymusza TLS, brak zgody na połączenia nieszyfrowane,
• smtpd_sasl_auth_enable=yes – włącza uwierzytelnianie SASL na tych portach,
• permit_sasl_authenticated,reject – tylko uwierzytelnieni klienci mogą wysyłać pocztę przez te porty.

Po zapisie pliku:

systemctl reload postfix

Sprawdź nasłuchujące porty:

ss -tnlp | grep master

Wynik powinien pokazywać porty 25, 587 oraz 465. Jeśli firewall jest aktywny (np. ufw), trzeba je otworzyć:

ufw allow 25/tcp
ufw allow 587/tcp
ufw allow 465/tcp

Instalacja i konfiguracja Dovecot (IMAP/POP3)

Instalacja pakietów Dovecot

Dovecot w wersji z repozytoriów Debian/Ubuntu jest wystarczający w większości scenariuszy. Podstawowy zestaw to IMAP, POP3 i moduły związane z auth:

apt install dovecot-imapd dovecot-pop3d dovecot-core dovecot-lmtpd dovecot-sieve dovecot-managesieved

Status usługi po instalacji:

systemctl status dovecot

Aktywne porty można obejrzeć poleceniem:

ss -tnlp | grep dovecot

Struktura konfiguracji Dovecot

Główna konfiguracja znajduje się w /etc/dovecot/dovecot.conf, ale na Debianie jest ona rozbita na katalog /etc/dovecot/conf.d/. Kluczowe pliki:

• 10-mail.conf – lokalizacja skrzynek, format poczty (Maildir/mbox),
• 10-auth.conf – metody uwierzytelniania, backend (systemowy, SQL itp.),
• 10-master.conf – gniazda i usługi (IMAP, POP3, auth),
• 10-ssl.conf – TLS dla IMAP/POP3,
• 15-mailboxes.conf – standardowe skrzynki (Sent, Trash, Junk itd.).

Po każdej zmianie konfiguracji warto ją sprawdzić:

dovecot -n
dovecot -n | less

dovecot -n wypisuje tylko parametry, które różnią się od domyślnych, co ułatwia przegląd produkcyjnej konfiguracji.

Ustawienie formatu i lokalizacji skrzynek (Maildir)

Wcześniej Postfix został skonfigurowany na home_mailbox = Maildir/, więc Dovecot musi szukać poczty dokładnie w tym samym miejscu. W pliku /etc/dovecot/conf.d/10-mail.conf ustaw:

mail_location = maildir:~/Maildir

Przy kontach systemowych Dovecot domyślnie używa użytkowników z /etc/passwd, więc nie są potrzebne dodatkowe definicje userdb/passdb (poza doprecyzowaniem metod auth).

W tym samym pliku można opcjonalnie włączyć wsparcie dla UIDL/UID zgodne z większością klientów, ale w typowej konfiguracji wartości domyślne są wystarczające.

Aktywacja IMAP i POP3

W pliku /etc/dovecot/conf.d/10-master.conf warto sprawdzić sekcję service imap-login i service pop3-login. Zazwyczaj wystarczy pozostawić standardową konfigurację, upewniając się, że usługi są włączone:

service imap-login {
  inet_listener imap {
    port = 143
  }
  inet_listener imaps {
    port = 993
    ssl = yes
  }
}

service pop3-login {
  inet_listener pop3 {
    port = 110
  }
  inet_listener pop3s {
    port = 995
    ssl = yes
  }
}

Jeżeli POP3 nie jest potrzebny, można wyłączyć usługę ustawiając pusty inet_listener pop3 i pop3s lub usuwając sekcję service pop3-login. W większości małych środowisk wystarczy wyłącznie IMAP (143/993).

Otwarcie portów w firewallu (jeśli aktywny):

ufw allow 143/tcp
ufw allow 993/tcp
# opcjonalnie:
ufw allow 110/tcp
ufw allow 995/tcp

Konfiguracja SSL/TLS w Dovecot

W /etc/dovecot/conf.d/10-ssl.conf trzeba wskazać te same certyfikaty Let’s Encrypt co w Postfixie:

ssl = required
ssl_cert = </etc/letsencrypt/live/mail.twojadomena.pl/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.twojadomena.pl/privkey.pem
ssl_dh = </usr/share/dovecot/dh.pem

Jeśli dh.pem nie istnieje, można go wygenerować:

openssl dhparam -out /usr/share/dovecot/dh.pem 2048
chmod 600 /usr/share/dovecot/dh.pem
chown root:dovecot /usr/share/dovecot/dh.pem

ssl = required wymusza szyfrowanie – klienci muszą korzystać z IMAPS (993) lub STARTTLS na 143. Przy migracjach ze starych klientów można tymczasowo ustawić ssl = yes, ale docelowo lepiej pozostać przy required.

Po modyfikacjach:

systemctl reload dovecot
dovecot -n

Metody uwierzytelniania w Dovecot

Przy kontach systemowych uwierzytelnianie odbywa się z użyciem haseł Unix (PAM). W pliku /etc/dovecot/conf.d/10-auth.conf ustawienia powinny wyglądać następująco:

disable_plaintext_auth = yes
auth_mechanisms = plain login

!include auth-system.conf.ext
#!include auth-sql.conf.ext
#!include auth-ldap.conf.ext

disable_plaintext_auth = yes blokuje nieszyfrowane logowanie – Dovecot będzie przyjmował loginy tylko w sesjach TLS. auth_mechanisms = plain login zapewnia kompatybilność z większością klientów pocztowych.

Po zmianach test logowania można przeprowadzić z linii komend, np. przy użyciu openssl s_client:

openssl s_client -connect mail.twojadomena.pl:993 -quiet
a login jan haslo_jana
a logout

Poprawna autoryzacja powinna skutkować odpowiedzią serwera z oznaczeniem a OK.

Test odbioru poczty przez Dovecot

Zakładając użytkownika systemowego jan z katalogiem ~/Maildir:

1. Wyślij wiadomość lokalnie:

   echo "Test IMAP" | mail -s "Test IMAP" jan

2. Sprawdź, czy wiadomość trafiła do /home/jan/Maildir/new/.
3. Skonfiguruj w kliencie pocztowym konto:
   • serwer przychodzący (IMAP): mail.twojadomena.pl, port 993, SSL/TLS,
   • login: jan, hasło: hasło systemowe użytkownika,
   • serwer wychodzący (SMTP): mail.twojadomena.pl, port 587, STARTTLS, autoryzacja login/hasło.

Po zapisaniu ustawień klient powinien bez problemu pobrać testowy mail i wysłać wiadomość na zewnętrzny adres (np. prywatny e-mail u dużego operatora). W razie problemów pierwsze spojrzenie kieruje się w logi:

tail -f /var/log/mail.log /var/log/dovecot.log 2>&1 | sed -e 's/^/LOG: /'

Uwierzytelnianie użytkowników i integracja Postfix z Dovecot (SASL)

Włączenie SASL w Postfix z backendem Dovecot

Postfix sam nie obsługuje uwierzytelniania użytkowników – deleguje je do zewnętrznego mechanizmu SASL. Najprościej wykorzystać do tego Dovecota, który już uwierzytelnia użytkowników dla IMAP/POP3.

W pliku /etc/postfix/main.cf trzeba dodać lub uzupełnić parametry:

# włączenie SASL po stronie serwera SMTP
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

# polityka relaya - tylko po uwierzytelnieniu lub z mynetworks
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination

Parametr smtpd_sasl_path = private/auth wskazuje na gniazdo, które musi udostępniać Dovecot. Definiuje się je po stronie Dovecota.

Po każdej modyfikacji konfiguracji Postfixa:

systemctl reload postfix
postfix check

postfix check zgłasza typowe błędy składniowe – jeśli coś jest źle, lepiej poprawić to od razu niż szukać problemów przy pierwszych próbach logowania SMTP.

Definicja gniazda Dovecot auth dla Postfixa

Po stronie Dovecota trzeba wystawić gniazdo, z którego skorzysta Postfix. W pliku /etc/dovecot/conf.d/10-master.conf odszukaj blok service auth {} i zmodyfikuj go tak, aby zawierał sekcję unix_listener /var/spool/postfix/private/auth:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }

  unix_listener auth-userdb {
    mode = 0600
    user = dovecot
    group = dovecot
  }

  user = dovecot
}

Ścieżka /var/spool/postfix/private/auth musi być zgodna z smtpd_sasl_path = private/auth z main.cf, a prawa dostępu muszą pozwalać demonowi Postfixa na komunikację z Dovecotem. Jeśli katalog chroot Postfixa jest inny (parametr queue_directory), ścieżka do gniazda musi się do niego odnosić.

Po zapisaniu zmian przeładuj Dovecota i upewnij się, że gniazdo powstało:

systemctl reload dovecot
ls -l /var/spool/postfix/private/auth
ss -xlp | grep auth

Wymuszenie TLS i uwierzytelniania na portach submission/SMTPS

Dla ruchu po porcie 587 (submission) i 465 (smtps) sensownie jest wymusić TLS i zablokować logowanie w czystym tekście. W /etc/postfix/master.cf doprecyzuj definicje usług:

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination

smtps     inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject_unauth_destination

Port 25 może pozostać mniej restrykcyjny pod kątem obowiązkowego TLS (zależnie od polityki), ale nie powinien nigdy akceptować relaya bez permit_mynetworks lub permit_sasl_authenticated, inaczej serwer szybko stanie się otwartym przekaźnikiem.

Testowanie SASL i ścieżka diagnostyczna

Podstawowy test polega na próbie uwierzytelnienia do SMTP z linii komend. Najłatwiej zrobić to na porcie 587 przy użyciu STARTTLS:

openssl s_client -connect mail.twojadomena.pl:587 -starttls smtp -quiet

Po ustanowieniu sesji TLS można spróbować logowania SASL. Dane logowania (login:hasło) trzeba zakodować w base64:

printf 'janhaslo_jana' | base64
# wynik, np.: AGphbgBoYXNsb19qYW5h

W sesji SMTP wpisz kolejno:

EHLO laptop.twojadomena.pl
AUTH PLAIN AGphbgBoYXNsb19qYW5h

Poprawna autoryzacja zakończy się komunikatem w stylu:

235 2.7.0 Authentication successful

Jeśli pojawi się błąd typu 535 5.7.8 Error: authentication failed albo 454 4.7.0 Temporary authentication failure, trzeba zajrzeć do logów obu usług jednocześnie:

tail -f /var/log/mail.log /var/log/dovecot.log 2>&1 | sed -e 's/^/LOG: /'

Jeżeli Dovecot poprawnie uwierzytelnia użytkownika, a Postfix nadal odrzuca logowanie, problem zwykle dotyczy gniazda private/auth (złe prawa, zła ścieżka) albo różnicy w użytkownikach/chroot. Przy błędach typu connect() to /var/spool/postfix/private/auth: Permission denied trzeba sprawdzić własność i uprawnienia:

ls -ld /var/spool/postfix /var/spool/postfix/private
ls -l /var/spool/postfix/private/auth
ps aux | egrep 'postfix|dovecot'

Jeśli w logach Postfixa brakuje jakichkolwiek linii o SASL, a w Dovecocie nie pojawia się nic z auth, problem leży zwykle po stronie konfiguracji master.cf lub main.cf (np. brak smtpd_sasl_auth_enable = yes na danym porcie, literówka w smtpd_sasl_path). Z kolei komunikaty Dovecota w rodzaju unknown user albo password mismatch oznaczają, że same dane logowania są błędne lub Dovecot patrzy w inną bazę użytkowników niż się zakłada (np. nadal korzysta z PAM, a konta istnieją tylko w SQL).

Przy pierwszych testach warto też porównać, czy logowanie do IMAP (993) dla danego użytkownika działa poprawnie. Jeśli IMAP się loguje, a SMTP nie, oznacza to kłopot z integracją SASL. Jeżeli IMAP również odrzuca hasło, przyczyna leży wyżej – w samym Dovecocie lub w systemowym mechanizmie uwierzytelniania. Takie podejście „od dołu do góry” pozwala zawęzić obszar poszukiwań i nie gubić czasu na błądzenie po całej konfiguracji naraz.

Po dopracowaniu konfiguracji Postfixa i Dovecota, skonfigurowaniu TLS, DKIM, SPF i poprawnym działaniu SASL, serwer pocztowy staje się pełnoprawnym elementem infrastruktury – potrafi przyjmować, przechowywać i wysyłać pocztę w sposób akceptowany przez duże serwisy. Dalszy rozwój to zwykle rozbudowa o filtry antyspamowe (Rspamd, SpamAssassin), systemy kwarantanny oraz centralne logowanie, ale solidna baza w postaci poprawnie ustawionego Postfixa i Dovecota na VPS-ie jest pierwszym krokiem, bez którego kolejne warstwy zabezpieczeń nie mają sensu.

Bezpieczna obsługa wielu domen i aliasów pocztowych

Domeny wirtualne a konta systemowe

Prosty serwer pocztowy może opierać się wyłącznie na użytkownikach systemowych (/etc/passwd) i jednej domenie. W praktyce szybko pojawia się potrzeba obsługi wielu domen oraz skrzynek, które nie mają odpowiedników w systemie (tzw. domeny i użytkownicy wirtualni).

Najczęstsze podejścia:

• Użytkownicy systemowi + aliasy – łatwe w konfiguracji, ale mało elastyczne; dobre na początek i dla małej liczby kont.
• Domeny i użytkownicy wirtualni (vmail) – konta i aliasy trzymane w plikach, SQL lub LDAP; jedna techniczna tożsamość systemowa (np. vmail) dla wszystkich skrzynek.

Jeśli serwer ma obsługiwać więcej niż kilka skrzynek lub kilka domen, sensownie jest od razu przejść na model z użytkownikiem wirtualnym i katalogami Maildir w jednym drzewie katalogów.

Aliasowanie adresów w Postfixie

Dla prostych przypadków (jedna domena, kilka kont) wystarczy mechanizm aliasów Postfixa. Plik /etc/aliases definiuje przekierowania adresów lokalnych:

postmaster: root
abuse:     root
kontakt:   jan
support:   jan,ania

Po każdej zmianie trzeba przebudować bazę aliasów i przeładować Postfixa:

newaliases
systemctl reload postfix

Alias kontakt z powyższego przykładu dostarczy pocztę do użytkownika jan, natomiast support rozdzieli każdą wiadomość na dwóch odbiorców. Klient pocztowy nadal loguje się na konto systemowe (jan lub ania), aliasy są tylko dodatkową „skórką” adresową.

Obsługa dodatkowych domen (mydestination, virtual_alias_domains)

Jeśli serwer ma przyjmować pocztę dla wielu domen, trzeba zdecydować, które z nich traktowane są jako lokalne (skrzynki trzymane lokalnie), a które będą jedynie przekierowywane. W /etc/postfix/main.cf:

mydestination = $myhostname, localhost.$mydomain, localhost
virtual_alias_domains = twojadomena.pl inna-domena.pl
virtual_alias_maps = hash:/etc/postfix/virtual

Plik /etc/postfix/virtual może wyglądać następująco:

jan@twojadomena.pl      jan
ania@twojadomena.pl     ania
kontakt@inna-domena.pl  jan
@inna-domena.pl         ania

• adresy pełne mapowane są na konkretne konta lokalne,
• wpis z @inna-domena.pl przekazuje całą domenę na jedno konto (catch-all).

Po edycji pliku map:

postmap /etc/postfix/virtual
systemctl reload postfix

Taki układ wystarcza dla kilku domen i kilku użytkowników. Jeśli liczba rośnie, wygodniej jest przejść na model wirtualnych skrzynek w Dovecocie, z wyraźnym rozdzieleniem loginu od konta systemowego.

Migracja na użytkownika vmail i skrzynki wirtualne

Tworzenie użytkownika technicznego vmail

Użytkownik wirtualny (np. vmail) nie loguje się do systemu, służy wyłącznie do posiadania plików z pocztą. Tworzenie konta i katalogu głównego Maildir:

groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /var/mail/vhosts -m -r -s /usr/sbin/nologin
chmod 750 /var/mail/vhosts
chown -R vmail:vmail /var/mail/vhosts

UIDs/GIDs można dobrać inne, ważne aby były spójne w konfiguracji Dovecota i Postfixa.

Konfiguracja Dovecota dla użytkownika vmail

W pliku /etc/dovecot/conf.d/10-mail.conf trzeba ustawić katalog bazowy i format skrzynek:

mail_location = maildir:/var/mail/vhosts/%d/%n/Maildir

mail_uid = vmail
mail_gid = vmail
first_valid_uid = 5000
last_valid_uid = 5000

• %d – domena (np. twojadomena.pl),
• %n – nazwa użytkownika (część przed @),
• katalog /var/mail/vhosts będzie zawierał strukturę domena/użytkownik/Maildir.

W pliku /etc/dovecot/conf.d/10-auth.conf można wyłączyć uwierzytelnianie systemowe (auth-system.conf.ext) i włączyć np. uwierzytelnianie na podstawie pliku haseł (dla prostych instalacji):

disable_plaintext_auth = yes
auth_mechanisms = plain login

!include auth-passwdfile.conf.ext
#!include auth-system.conf.ext

Plik /etc/dovecot/conf.d/auth-passwdfile.conf.ext:

passdb {
  driver = passwd-file
  args = scheme=SHA512-CRYPT username_format=%u /etc/dovecot/users
}

userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n
}

Plik /etc/dovecot/users będzie przechowywał pary użytkownik:hasło w formie:

jan@twojadomena.pl:{SHA512-CRYPT}$6$.......
ania@inna-domena.pl:{SHA512-CRYPT}$6$.......

Hasła można wygenerować poleceniem:

doveadm pw -s SHA512-CRYPT
Enter new password:
Retype new password:
{SHA512-CRYPT}$6$.....

Po każdej edycji pliku z użytkownikami dobrze jest wymusić restrykcyjne prawa:

chown root:dovecot /etc/dovecot/users
chmod 640 /etc/dovecot/users

Po zmianach:

systemctl reload dovecot
tail -n 50 /var/log/dovecot.log

Integracja Postfixa z użytkownikami wirtualnymi

Postfix musi wiedzieć, które adresy są lokalne i gdzie dostarczyć pocztę. Jedna z prostszych opcji to zdefiniowanie domen i skrzynek w mapie virtual_mailbox_domains oraz virtual_mailbox_maps.

Fragment /etc/postfix/main.cf:

virtual_mailbox_domains = twojadomena.pl, inna-domena.pl
virtual_mailbox_base = /var/mail/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 5000
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

virtual_transport = lmtp:unix:private/dovecot-lmtp

Plik /etc/postfix/vmailbox może wyglądać następująco:

jan@twojadomena.pl      twojadomena.pl/jan/Maildir/
kontakt@twojadomena.pl  twojadomena.pl/jan/Maildir/
ania@inna-domena.pl     inna-domena.pl/ania/Maildir/

Aby przekazać pocztę do Dovecota przez LMTP, trzeba włączyć usługę LMTP po stronie Dovecota. W pliku /etc/dovecot/conf.d/20-lmtp.conf:

protocol lmtp {
  postmaster_address = postmaster@twojadomena.pl
}

W /etc/dovecot/conf.d/10-master.conf dodaj sekcję:

service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}

Po zmianach:

systemctl reload dovecot
postmap /etc/postfix/vmailbox
systemctl reload postfix

Test polega na wysłaniu maila z zewnątrz do skrzynki wirtualnej i sprawdzeniu, czy pojawi się w /var/mail/vhosts/domena/użytkownik/Maildir/new/ oraz czy klient IMAP go widzi.

Ochrona reputacji: SPF, DKIM i DMARC

Rekord SPF dla domeny

SPF (Sender Policy Framework) ogranicza listę serwerów IP, z których wolno wysyłać pocztę w imieniu domeny. Rekord dodaje się w strefie DNS jako TXT, np. dla domeny twojadomena.pl:

twojadomena.pl.  3600 IN TXT "v=spf1 mx a ip4:203.0.113.10 -all"

• mx – zezwala serwerom zdefiniowanym jako MX,
• a – zezwala na adres IP z rekordu A domeny,
• ip4:203.0.113.10 – dopuszcza dodatkowy adres IP (np. drugi VPS),
• -all – wszystko inne ma zostać odrzucone.

Dla prostego VPS-a często wystarcza: "v=spf1 mx -all", jeśli serwer MX jest jednocześnie serwerem wysyłającym.

Instalacja i konfiguracja OpenDKIM

DKIM podpisuje wychodzące wiadomości kryptograficznie, co pozwala odbiorcom zweryfikować, że nie zostały zmodyfikowane po drodze i faktycznie zostały wysłane przez uprawnioną infrastrukturę.

Instalacja OpenDKIM (Debian/Ubuntu):

apt install opendkim opendkim-tools

Podstawowy plik konfiguracyjny /etc/opendkim.conf może zawierać m.in.:

Syslog                  yes
UMask                   002
Mode                    sv
Canonicalization        relaxed/relaxed
SubDomains              no
AutoRestart             yes
AutoRestartRate         10/1h
SignatureAlgorithm      rsa-sha256

KeyTable                /etc/opendkim/keytable
SigningTable            /etc/opendkim/signingtable
ExternalIgnoreList      /etc/opendkim/trusted
InternalHosts           /etc/opendkim/trusted

Socket                  inet:8891@localhost

Plik /etc/opendkim/trusted może zawierać lokalne adresy i domeny:

127.0.0.1
::1
localhost
twojadomena.pl
inna-domena.pl

Generowanie kluczy DKIM dla domen

Dla każdej domeny generuje się parę kluczy. Przykład dla twojadomena.pl z selektorem mail:

mkdir -p /etc/opendkim/keys/twojadomena.pl
cd /etc/opendkim/keys/twojadomena.pl
opendkim-genkey -s mail -d twojadomena.pl
chown opendkim:opendkim mail.private
chmod 600 mail.private

Plik mail.private to klucz prywatny używany przez OpenDKIM, a mail.txt zawiera propozycję rekordu DNS. Następnie trzeba uzupełnić pliki map OpenDKIM-a:

echo "mail._domainkey.twojadomena.pl twojadomena.pl:mail:/etc/opendkim/keys/twojadomena.pl/mail.private" 
  >> /etc/opendkim/keytable

echo "*@twojadomena.pl mail._domainkey.twojadomena.pl" 
  >> /etc/opendkim/signingtable

Rekord DNS DKIM (wyciągnięty z mail.txt) dodaje się jako TXT np.:

mail._domainkey.twojadomena.pl. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...."

Jeśli obsługiwanych jest kilka domen, powtarza się procedurę generowania kluczy i dopisywania do keytable i signingtable – jeden OpenDKIM może obsługiwać wiele domen.

Integracja OpenDKIM z Postfixem

Postfix musi wysyłać pocztę przez filtr OpenDKIM jako milter. W pliku /etc/postfix/main.cf dodaje się (lub uzupełnia istniejące) parametry:

milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Po zmianach:

systemctl enable opendkim
systemctl restart opendkim
systemctl reload postfix
tail -n 50 /var/log/mail.log /var/log/syslog | grep -i dkim

Test polega na wysłaniu maila z VPS-a na zewnętrzny serwis (np. dużego operatora) i sprawdzeniu nagłówków – powinien pojawić się nagłówek DKIM-Signature, a w szczegółach wiadomości status „DKIM: pass”.

DMARC – polityka spójności SPF/DKIM

DMARC pozwala zdefiniować, co odbiorcy powinni zrobić z wiadomościami, które nie przechodzą SPF i DKIM oraz gdzie wysyłać raporty z ich weryfikacji. Przykładowy rekord dla twojadomena.pl:

_dmarc.twojadomena.pl. 3600 IN TXT 
"v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@twojadomena.pl; ruf=mailto:dmarc-ruf@twojadomena.pl; pct=100; adkim=s; aspf=s"

• p=quarantine – sugeruje kwarantannę dla wiadomości niespełniających wymogów,
• rua/ruf – adresy zbiorczych i szczegółowych raportów,
• aspf=s i adkim=s – tryb „strict”, wymagający ścisłej zgodności domen.

Konsekwencją zaostrzenia polityki DMARC jest to, że wszystkie legalne ścieżki wysyłki poczty muszą być zgodne ze SPF/DKIM. Jeśli w firmie używany jest jeszcze jakiś inny serwer lub usługa SaaS wysyłająca maile z domeny, trzeba je także uwzględnić.

Zanim politykę zaostrzy się do p=quarantine lub p=reject, rozsądnie jest przez kilka tygodni zbierać wyłącznie raporty z ustawieniem p=none. Na bazie tych raportów widać, które systemy naprawdę wysyłają pocztę z danej domeny, jakie IP się pojawiają i gdzie SPF/DKIM zawodzą. Jeśli pojawiają się legalne źródła wysyłki (np. system fakturowy, helpdesk, narzędzie marketingowe), trzeba je dopisać do SPF lub włączyć podpisy DKIM po ich stronie.

Raporty DMARC (szczególnie rua) są zwykle w formacie XML, trudno je więc analizować ręcznie. Przydają się proste narzędzia: albo samodzielnie postawiony parser (np. skrypt importujący do bazy i wizualizujący wyniki), albo zewnętrzny serwis, który odbiera raporty i pokazuje je w czytelnej formie. Dzięki temu da się dość szybko wyłapać próby podszywania się pod domenę i błędną konfigurację serwerów pośrednich.

Przy wdrażaniu DMARC opłaca się iść krokami: najpierw p=none i zbieranie raportów, później np. p=quarantine; pct=25, następnie zwiększenie odsetka wiadomości objętych polityką, a dopiero na końcu pełne p=reject; pct=100. Taki etapowy model ogranicza ryzyko, że nagle legalna poczta z ważnego systemu zacznie wpadać do spamu lub będzie odrzucana tylko dlatego, że nie została ujęta w SPF albo nie jest podpisana DKIM.

Połączenie poprawnie skonfigurowanego Postfixa i Dovecota z kompletem mechanizmów SPF, DKIM i DMARC daje serwer, który nie tylko dostarcza i odbiera pocztę, ale też utrzymuje rozsądną reputację w oczach dużych operatorów. Jeśli konfiguracja jest udokumentowana, a logi i raporty są regularnie przeglądane, taki własny serwer pocztowy może przez lata działać stabilnie i przewidywalnie, bez niespodzianek w postaci masowego lądowania wiadomości w folderach spam.

Najczęściej zadawane pytania (FAQ)

Czy własny serwer pocztowy na VPS ma sens przy małej firmie?

Jeśli masz 2–5 kont i brak osoby technicznej, zwykle lepszym wyborem są usługi typu Microsoft 365, Google Workspace lub solidny hosting z pocztą. Dostawca bierze na siebie reputację IP, filtry antyspamowe, wysoką dostępność i obsługę awarii.

Własny serwer zaczyna się opłacać, gdy rośnie liczba skrzynek (np. kilkanaście–kilkadziesiąt) lub pojawiają się specyficzne wymagania: pełna kontrola danych, integracja z aplikacjami, testy deweloperskie. Warunek jest jeden – ktoś musi świadomie zajmować się administracją i bezpieczeństwem.

Jakie minimalne parametry VPS są potrzebne pod Postfix + Dovecot?

Do prostego, testowego serwera wystarczy zwykle:

• 1 GB RAM, 1 vCPU, ok. 20 GB dysku,
• stabilna dystrybucja Linux, np. Debian stable lub Ubuntu LTS,
• publiczny adres IPv4 (IPv6 jako dodatek, nie zamiennik).

Dla kilku–kilkunastu aktywnych użytkowników lepiej zacząć od 2 GB RAM i 2 vCPU, szczególnie jeśli planujesz filtr antyspamowy/antywirusowy. Poczta rośnie latami, więc przestrzeń dyskową dobiera się z zapasem i z myślą o backupach.

Jakie rekordy DNS muszę ustawić dla własnego serwera pocztowego?

Do podstawowego działania poczty potrzebne są co najmniej trzy typy rekordów:

• A – wskazuje adres IP serwera, np. mail.twojadomena.pl. A 203.0.113.10,
• MX – definiuje host obsługujący pocztę dla domeny, np. twojadomena.pl. MX 10 mail.twojadomena.pl.,
• PTR (reverse DNS) – dla adresu IP serwera, wskazujący na ten sam FQDN, np. mail.twojadomena.pl..

Jeśli serwer ma IPv6, dodaj także rekord AAAA. Brak spójności między A, MX i PTR albo losowy PTR to częsty powód problemów z dostarczalnością do dużych providerów (np. Gmail, Outlook.com).

Czy muszę mieć własną domenę, żeby postawić Postfix i Dovecot?

Tak, jeśli chcesz normalnie wysyłać i odbierać pocztę z Internetu. Potrzebna jest domena, do której panelu DNS masz pełny dostęp (edycja rekordów A, AAAA, MX, TXT) oraz możliwość ustawienia PTR po stronie dostawcy VPS. Bez tego nie zbudujesz poprawnej tożsamości serwera i większość odbiorców będzie odrzucać lub oznaczać wiadomości jako spam.

Serwer bez domeny ma sens tylko w środowisku czysto testowym, odizolowanym od Internetu (np. wewnętrzne laby deweloperskie). Do realnej komunikacji zewnętrznej domena jest obowiązkowa.

Jak sprawdzić, czy mój VPS nadaje się do wysyłki poczty (port 25, reputacja IP)?

Najpierw upewnij się, że dostawca nie blokuje portu 25 dla ruchu wychodzącego. Można to zweryfikować w dokumentacji, panelu klienta albo prostym testem z VPS, np. próbą połączenia telnet gmail-smtp-in.l.google.com 25. Brak odpowiedzi lub „connection timed out” często oznacza filtr.

Reputację IP sprawdzisz w popularnych RBL (Realtime Blackhole Lists), np. MXToolbox. Jeśli adres jest na kilku listach, mogą pojawić się problemy z dostarczeniem poczty. W takiej sytuacji lepiej poprosić dostawcę o inne IP albo wybrać innego providera VPS.

Jak zabezpieczyć serwer pocztowy na poziomie systemu przed instalacją Postfixa?

Na starcie zabezpiecza się głównie dostęp do serwera i podstawową konfigurację systemu:

• logowanie po SSH wyłącznie kluczem (wyłączenie PasswordAuthentication i bezpośredniego logowania roota hasłem),
• ustawienie poprawnego hostname z FQDN, np. mail.twojadomena.pl,
• aktualizacja systemu (apt update && apt upgrade) oraz instalacja narzędzi diagnostycznych (np. htop, dnsutils, swaks),
• skonfigurowanie strefy czasowej, aby logi pocztowe miały spójne znaczniki czasu.

Dopiero na takim przygotowanym, aktualnym systemie ma sens instalacja i dalsze utwardzanie Postfixa, Dovecota oraz warstwy antyspamowej.

Kluczowe Wnioski

• Własny serwer pocztowy Postfix + Dovecot na VPS daje pełną kontrolę nad danymi (treść maili, logi, backupy), co ułatwia spełnienie wymogów prawnych, kontraktowych i bezpieczeństwa.
• Taka konfiguracja zapewnia dużą elastyczność: można dobrać własne filtry antyspamowe, szyfrowanie, archiwizację czy integracje z aplikacjami zamiast dopasowywać się do sztywnych funkcji usług SaaS.
• Przy większej liczbie kont (kilkadziesiąt i więcej) własny VPS często wychodzi taniej niż abonamenty chmurowe, pod warunkiem posiadania kompetencji administracyjnych lub czasu na ich zdobycie.
• Serwer pocztowy wymaga stabilnego VPS z publicznym IPv4, kontrolą nad DNS (A, AAAA, MX, TXT, PTR), a także ciągłej opieki: aktualizacji, monitoringu logów, procedur backupu i jasnych zasad tworzenia kont.
• Nie każdy powinien stawiać własny serwer: przy braku zaplecza technicznego, małej skali i krytycznym znaczeniu poczty bezpieczniejszy jest sprawdzony dostawca (Microsoft 365, Google Workspace, hosting poczty).
• Własny serwer szczególnie ma sens w środowiskach z techniczną osobą na pokładzie, w projektach hobbystycznych i deweloperskich oraz tam, gdzie wymagane jest pełne unikanie zewnętrznej chmury.
• Przygotowanie VPS obejmuje nie tylko wybór dystrybucji (Debian/Ubuntu LTS), lecz także kwestie reputacji IP (odblokowany port 25, własny PTR, brak wpisów na RBL) oraz podstawowe utwardzenie SSH i poprawne ustawienie hostname (FQDN).