ULTIMATE GUIDE: Konfiguracja serwera dla prawidłowej dostawy poczty. CZĘŚĆ 1: Firewall

informacja

Firewall (zapora sieciowa) - to sprzęt z oprogramowaniem lub samo oprogramowanie, które kontroluje, jakie połączenia z serwerem są dozwolone, a jakie powinny zostać zablokowane. W zdecydowanej większości współczesnych dystrybucji serwerowych Linux firewall jest dostępny od razu po instalacji systemu, choć może wymagać dodatkowej konfiguracji.

Prawidłowe dostarczanie poczty do adresata zależy nie tylko od działania serwera pocztowego, ale także od prawidłowej konfiguracji rekordów DNS i firewall. Jeśli coś jest z nimi nie tak, wiadomości mogą trafiać do folderu SPAM albo w ogóle nie zostać doręczone.

W tym artykule omawiamy kluczowe kroki, które pozwolą zwiększyć skuteczność dostarczania poczty praktycznie do 100%. W pierwszej części skupimy się na problemach związanych z konfiguracją zapory sieciowej, a w drugiej podamy instrukcje dotyczące konfiguracji rekordów DNS. 

Informacje zawarte w poradniku dotyczą serwerów pocztowych działających na systemach z rodziny Linux. W przykładach wykorzystano Debian 12 oraz Rocky Linux 8.10 z panelem sterowania FASTPANEL.

Etap wstępny

Krok 1. Instalacja oprogramowania potrzebnego do diagnostyki

Do sprawdzenia wpisów i portów będą potrzebne następujące narzędzia:

• dig - do analizy rekordów DNS.

• lsof - do sprawdzania stanu serwera pocztowego.

• netcat - do testowania dostępności portów.

• whois - do sprawdzania aktualnego operatora DNS.

Instalacja w Debian/Ubuntu:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd lsof whois

W CentOS/AlmaLinux/Rocky Linux:

sudo yum install -y bind-utils nmap-ncat lsof whois

Dostępność portów pocztowych

informacja

Port to numeryczny identyfikator używany do adresowania usług działających na serwerze. Każdy serwis lub aplikacja „nasłuchuje” na określonym porcie, aby móc odbierać i wysyłać dane przez sieć (np. HTTP działa na porcie 80, a SMTP na porcie 25).

Aby wykonać dalsze kroki, połącz się z serwerem przez SSH jako użytkownik root, albo korzystaj z sudo tak jak w przedstawionych poleceniach. Jeśli potrzebujesz pomocy z połączeniem przez SSH, odsyłamy do naszego poradnika.

Krok 2. Sprawdzenie stanu serwerów pocztowych.

Zanim przejdziemy do testowania dostępności portów z sieci, trzeba upewnić się, że serwery pocztowe działają poprawnie. Za pocztę wychodzącą odpowiada zwykle Exim albo Postfix, natomiast za odbiór wiadomości - Dovecot.

Sprawdzisz to poleceniami:

sudo lsof -i:25
sudo lsof -i:143

Jeśli serwery działają, zobaczysz mniej więcej taki wynik:

Port 25:

COMMAND PID USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
exim    839 exim    4u  IPv6 778199358      0t0  TCP *:smtp (LISTEN)
exim    839 exim    5u  IPv4 778199359      0t0  TCP *:smtp (LISTEN)

Jeśli na twoim serwerze używany jest inny serwer SMTP, na przykład Postfix, w wynikach w pierwszej kolumnie zostanie podana jego dokładna nazwa zamiast exim. W razie potrzeby użyj jej w kolejnych poleceniach.

Port 143:

dovecot 859 root   39u  IPv4 778204692      0t0  TCP *:imap (LISTEN)
dovecot 859 root   40u  IPv6 778204693      0t0  TCP *:imap (LISTEN)

Taki wynik oznacza, że wszystko jest w porządku i możesz przejść dalej.

Jeśli serwery pocztowe nie są uruchomione, zobaczysz pusty wynik:

~ sudo lsof -i:25
~
~ sudo lsof -i:143
~

W takim przypadku wystąpił jakiś problem z serwerami pocztowymi i nie są one dostępne. Możesz spróbować uruchomić je ręcznie, a następnie sprawdzić status:

Debian/Ubuntu:

systemctl restart exim4 dovecot
systemctl status exim4
systemctl status dovecot

CentOS/AlmaLinux/Rocky Linux:

systemctl restart exim dovecot
systemctl status exim
systemctl status dovecot

Po uruchomieniu status usług będzie wyglądał następująco:

Exim:

● exim.service - Exim Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/exim.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2025-11-02 16:38:57 UTC; 57min ago
 Main PID: 839 (exim)
    Tasks: 1
   Memory: 11.0M
   CGroup: /system.slice/exim.service
           └─839 /usr/sbin/exim -bd -q1h

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Dovecot:

● dovecot.service - Dovecot IMAP/POP3 email server
   Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2025-11-02 16:38:58 UTC; 58min ago
     Docs: man:dovecot(1)
           https://doc.dovecot.org/
 Main PID: 859 (dovecot)
    Tasks: 5
   Memory: 9.5M
   CGroup: /system.slice/dovecot.service
           ├─ 859 /usr/sbin/dovecot -F
           ├─ 880 dovecot/anvil
           ├─ 881 dovecot/log
           ├─ 882 dovecot/config
           └─1729 dovecot/stats

W takiej sytuacji wszystko jest w porządku i możesz przejść do kolejnych kroków.

Jeśli jednak coś jest nie tak, zobaczysz to:

Exim:

● exim.service - Exim Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/exim.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2025-11-02 17:38:44 UTC; 3s ago
  Process: 839 ExecStart=/usr/sbin/exim -bd -q${QUEUE} (code=exited, status=0/SUCCESS)
 Main PID: 839 (code=exited, status=0/SUCCESS)

Dovecot:

● dovecot.service - Dovecot IMAP/POP3 email server
   Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2025-11-02 17:39:32 UTC; 3s ago
     Docs: man:dovecot(1)
           https://doc.dovecot.org/
  Process: 2278 ExecStop=/usr/bin/doveadm stop (code=exited, status=0/SUCCESS)
  Process: 859 ExecStart=/usr/sbin/dovecot -F (code=exited, status=0/SUCCESS)
 Main PID: 859 (code=exited, status=0/SUCCESS)

Przyczyny mogą być bardzo różne - błędna konfiguracja, uszkodzone logi, brak miejsca na dysku itd. W tym artykule nie będziemy zagłębiać się w diagnozowanie takich problemów.

Jeśli chcesz spróbować rozwiązać je samodzielnie, polecamy nasz poradnik o pracy z dziennikiem systemowym. Możesz też skontaktować się z pomocą techniczną swojego dostawcy hostingu. W kodu.cloud pracujemy 24/7 i odpowiadamy na zgłoszenia w ciągu kilku minut.

Krok 3. Sprawdzenie dostępności portów pocztowych z sieci publicznej

Aby poczta działała prawidłowo, następujące porty TCP muszą być dostępne z globalnej sieci:

• 25, 465, 587 - wysyłanie poczty (SMTP)

• 143, 993 - odbieranie poczty (IMAP)

Dostępność portów możesz sprawdzić za pomocą netcat:

nc -vz 1.2.3.4 25

Zamiast 1.2.3.4 wstaw prawdziwy adres IP swojego serwera.

Jeśli port jest otwarty, zobaczysz:

Debian/Ubuntu:

Connection to 1.2.3.4 25 port [tcp/smtp] succeeded!

CentOS/AlmaLinux/Rocky Linux:

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 1.2.3.4:25.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

Jeśli port jest zamknięty:

Debian/Ubuntu:

nc: connect to 1.2.3.4 port 25 (tcp) failed: Connection refused

CentOS/AlmaLinux/Rocky Linux:

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connection refused.

Wykonaj to polecenie dla wszystkich portów wymienionych na początku tej sekcji. Jeśli wszystkie są dostępne, przejdź do drugiej części tego artykułu. Jeśli nie, przejdź do kroku 4, aby to naprawić.

Krok 4. Otwarcie dostępu (opcjonalnie).

Na serwerach najczęściej stosuje się iptables lub UFW jako firewall blokujący niepożądane połączenia. Uruchom polecenie:

sudo ufw status

Jeśli zobaczysz:

-bash: ufw: command not found

Oznacza to, że używany jest iptables. Jeśli natomiast wynik zaczyna się od:

Status: active

Używany jest UFW.

Przejdź do odpowiedniego podrozdziału tego kroku zgodnie z wykorzystywanym firewallem.

warning

W systemach Linux istnieją również inne narzędzia do zarządzania firewallem, takie jak nftables czy firewalld, jednak w tym artykule nie będą one omawiane, aby uniknąć nadmiernego rozbudowania treści.

Iptables

warning

Wszystkie przykłady w tym rozdziale dotyczą tylko IPv4. Jeżeli twój serwer ma adres IPv6 i potrzebujesz udostępnić porty pocztowe w tej przestrzeni, powtórz polecenia używając ip6tables zamiast iptables.

Aby wyświetlić aktualne reguły, wpisz polecenie:

sudo iptables -L -v -n --line-numbers

Wynik będzie zależał od tego, jakie reguły zostały dodane wcześniej. Domyślnie firewall może być pusty, jednak wiele paneli hostingowych lub dystrybucji systemowych wprowadza własne ustawienia. Najczęściej spotkasz jeden z dwóch scenariuszy konfiguracji.

1. Polityka „dozwolone wszystko, co nie jest zabronione” (policy ACCEPT).

W takim trybie firewall przepuszcza cały ruch, dopóki nie pojawi się reguła blokująca. Jest to częsta konfiguracja domyślna.

Przykład zestawu reguł, gdzie zablokowane są porty SSH i porty pocztowe:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       51  5637 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 22
2        0     0 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 25,143,993,587,465

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 25,143,993,587,465

W tym przykładzie:

• Policy ACCEPT oznacza, że cały ruch jest akceptowany domyślnie,

• Chain INPUT (połączenia przychodzące): blokowane są nowe połączenia na port 22 (SSH) oraz wszystkie porty pocztowe (SMTP: 25, 465, 587; IMAP: 143; IMAPS: 993).

• Chain OUTPUT (połączenia wychodzące): blokowane są pakiety wychodzące do tych samych portów.

Numer porządkowy reguły jest podany na początku wiersza (num). Jeśli chcesz usunąć, na przykład, regułę blokującą porty pocztowe w łańcuchu przychodzącym INPUT (numer 2), polecenie będzie wyglądało następująco:

sudo iptables -D INPUT 2

Gdzie:

• -D — to polecenie służące do usunięcia reguły.

• INPUT — ciąg, z którego usuwamy regułę (w tym przypadku ruch przychodzący).

• 2 — numer wiersza, w którym znajduje się reguła, którą należy usunąć.

Analogicznie, aby usunąć blokadę portów wychodzących z tego przykładu, należy wykonać:

sudo iptables -D OUTPUT 1  

warning

Numery wierszy w wynikach iptables -L -v -n --line-numbers mogą się zmieniać, jeśli usuwasz lub dodajesz inne. Dlatego jeśli dodałeś nowe reguły, numery wierszy mogą się przesunąć. Aby uniknąć błędów, przed usunięciem zawsze sprawdzaj aktualne numery wierszy.

Następnie, aby upewnić się, że wszystko jest w porządku, ponownie wykonaj polecenie:

iptables -L -v -n --line-numbers

W wynikach nie powinno być reguł blokujących działanie portów pocztowych:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       51  5637 DROP       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Jeśli reguły nadal są obecne, sprawdź poprawność wprowadzonych poleceń oraz numery linii.

Po każdej modyfikacji reguł firewalla koniecznie zapisz zmiany, w przeciwnym razie zostaną utracone po restarcie systemu. Aby zapisać aktualny zestaw reguł w iptables, wykonaj polecenie:

Debian/Ubuntu:

iptables-save > /etc/iptables/rules.v4

CentOS/AlmaLinux/Rocky Linux:

iptables-save > /etc/sysconfig/iptables

Po zapisaniu sprawdź ponownie dostępność portów, tak jak w kroku 3. Jeśli dalej są zablokowane, przejdź do kroku 5. Jeśli są otwarte, przejdź do drugiej części tego artykułu.

2. Polityka „blokowanie wszystkiego, co nie jest dozwolone” (policy DROP).

Ten typ konfiguracji jest znacznie bardziej rygorystyczny. Wszystkie porty i protokoły są domyślnie blokowane, a ruch może przejść wyłącznie wtedy, gdy konkretny port został jawnie dopuszczony. To bezpieczniejsze i często zalecane podejście, szczególnie, jeśli zależy ci na maksymalnym ograniczeniu ryzyka.

Przykład reguł dla takiej konfiguracji:

Chain INPUT (policy DROP 306 packets, 17962 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       92 12474 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2      466 32947 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 197 packets, 29192 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1       44 10332 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

W tym przykładzie:

• Chain INPUT (połączenia przychodzące): obowiązuje polityka DROP, czyli wszystkie pakiety są domyślnie blokowane, z wyjątkiem tych, które mają dodane reguły zezwalające.

Reguła 1: ACCEPT state RELATED,ESTABLISHED - zezwala na pakiety przychodzące powiązane z już istniejącymi połączeniami. To ważne, bo umożliwia serwerowi prawidłowe odbieranie odpowiedzi na nawiązane wcześniej połączenia (np. SSH, poczta, zapytania DNS). Reguła 2: ACCEPT tcp dpt:22 - zezwala na nowe połączenia przychodzące na port 22 (SSH).

• Chain OUTPUT (połączenia wychodzące): polityka DROP, czyli blokada całego ruchu wychodzącego.

Reguła 1: ACCEPT state RELATED,ESTABLISHED — zezwala na pakiety wychodzące związane z już istniejącymi połączeniami. Dzięki temu serwer może odpowiadać klientom (np. SSH, połączenia pocztowe) i utrzymywać stabilny ruch sieciowy.

Naturalnie więc, w tej konfiguracji nie ma żadnych reguł zezwalających na ruch dotyczący portów pocztowych. Aby je dodać, wykonaj następujące polecenia:

sudo iptables -A INPUT -p tcp -m multiport --dports 25,465,587,143,993 -m state --state NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp -m multiport --dports 25,465,587,143,993 -m state --state NEW,ESTABLISHED -j ACCEPT

Następnie zapisz konfigurację:

Debian/Ubuntu:

iptables-save > /etc/iptables/rules.v4

CentOS/AlmaLinux/Rocky Linux:

iptables-save > /etc/sysconfig/iptables

Po zapisaniu sprawdź ponownie dostępność portów, tak jak w kroku 3. Jeśli dalej są zablokowane, przejdź do kroku 5. Jeśli są otwarte, przejdź do drugiej części tego artykułu.

UFW (Uncomplicated Firewall)

Na niektórych serwerach zamiast iptables używany jest UFW - uproszczony interfejs do konfiguracji firewalla. Świetnie nadaje się do podstawowej konfiguracji serwera pocztowego i często spotyka się go na Ubuntu oraz Debianie.

Aby sprawdzić, czy UFW jest włączony i jakie reguły są aktywne, wykonaj:

sudo ufw status verbose

Przykładowy wynik:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip

Gdzie:

• Default: deny (incoming) - domyślnie wszystkie połączenia przychodzące są blokowane.

• Default: allow (outgoing) - domyślnie wszystkie połączenia wychodzące są dozwolone.

Aby serwer pocztowy działał prawidłowo, musisz otworzyć standardowe porty. Wykonaj kolejno:

sudo ufw allow 25/tcp
sudo ufw allow 465/tcp
sudo ufw allow 587/tcp
sudo ufw allow 143/tcp
sudo ufw allow 993/tcp

Jeśli masz również ograniczenia dla ruchu wychodzącego, to dla poczty wychodzącej trzeba zezwolić na porty SMTP:

sudo ufw allow out 25/tcp
sudo ufw allow out 465/tcp
sudo ufw allow out 587/tcp

Po dodaniu reguł możesz ponownie je zweryfikować:

sudo ufw status numbered

Zobaczysz listę reguł ponumerowanych kolejno. Jeśli potrzebujesz jakąś usunąć, użyj numeru z listy:

sudo ufw delete 3

W UFW reguły są zapisywane automatycznie, więc po restarcie serwera nadal będą aktywne.

Po zapisaniu sprawdź ponownie dostępność portów, tak jak w kroku 3. Jeśli dalej są zablokowane, przejdź do kroku 5. Jeśli są otwarte, przejdź do drugiej części tego artykułu.

Krok 5. W firewall wszystko działa, ale porty pocztowe nadal są zablokowane (opcjonalnie)

Jeśli porty wciąż są niedostępne mimo prawidłowych reguł na serwerze, oznacza to, że blokada jest zastosowana na poziomie infrastruktury hostingodawcy. W takiej sytuacji utwórz zgłoszenie do pomocy technicznej z prośbą o odblokowanie portów pocztowych. Jeśli nie ma takiej możliwości, jedynym rozwiązaniem jest zmiana dostawcy.

W kodu.cloud nie blokujemy portów pocztowych. Zakazane są jedynie masowe wysyłki, natomiast zwykła poczta działa bez ograniczeń. Nie musisz nawet konfigurować serwera pocztowego, ponieważ wszyscy nasi klienci mają bezpłatny dostęp do panelu sterowania FASTPANEL z rozszerzoną licencją. Zamów serwer i już po kilku minutach zacznij korzystać z poczty na własnej domenie.

Następne kroki dotyczące konfiguracji rekordów DNS znajdziesz w drugiej części tego artykułu.