Od zera do bezpiecznego serwera pocztowego: konfiguracja, SPF, DKIM i DMARC dla domeny firmowej

Fundamenty bezpiecznej poczty firmowej – o co tu naprawdę chodzi

Dlaczego firmowa domena i własna poczta to nie fanaberia

Adres e‑mail w stylu imie@nazwa-firmy.pl to dziś element podstawowej wiarygodności. Klient, który dostaje ofertę z adresu typu biuro.firma@gmail.com, podświadomie zadaje sobie pytanie: czy to na pewno poważny podmiot, czy może ktoś, kto działa „z doskoku”. W branżach B2B, finansach, prawie czy medycynie brak poczty pod domeną firmową zaczyna wyglądać wręcz podejrzanie.

Własna domena i odpowiednio skonfigurowany serwer pocztowy dają także konkretne korzyści techniczne. Można kontrolować reputację domeny, wdrożyć SPF, DKIM i DMARC, stosować własne reguły bezpieczeństwa i polityki archiwizacji. Przy adresach na darmowych serwisach publicznych praktycznie nie da się tego zrobić – jesteśmy w pełni zależni od decyzji dostawcy.

Mit, który często krąży: „skoro korzystamy z Gmaila, to mamy z automatu maksymalne bezpieczeństwo”. Rzeczywistość jest taka, że bezpieczeństwo poczty firmowej to kombinacja: konfiguracji DNS (SPF, DKIM, DMARC), wewnętrznej polityki haseł, zabezpieczeń urządzeń użytkowników i świadomości użytkowników. Nawet najlepszy dostawca SaaS nie ochroni przed kliknięciem w złośliwy załącznik z prywatnego laptopa albo przed hasłem „Firma123”.

Główne zagrożenia dla poczty firmowej

Najczęstsze ataki na firmową pocztę nie polegają na „łamaniu serwera”, lecz na nadużywaniu zaufania do domeny i skrzynek. W praktyce oznacza to głównie:

• Phishing – podszywanie się pod pracowników firmy lub kluczowych partnerów, by wyłudzić hasła, dane lub przelewy.
• Spoofing domeny – wysyłka wiadomości z fałszywym nagłówkiem „From:”, które sugerują, że mail wyszedł z Twojej domeny, choć nigdy nie przeszedł przez Twój serwer.
• Przejęcie kont – atakujący loguje się na prawdziwą skrzynkę (np. po skutecznym phishingu) i wysyła z niej wiarygodne wiadomości wewnątrz organizacji i do klientów.
• Utrata reputacji domeny – jeżeli z Twojej domeny (lub z przypisanego do niej IP) zacznie płynąć spam, duże serwisy (Gmail, Outlook.com) zaczną obniżać score Twoich wiadomości lub wręcz je blokować.

Reputacja w kontekście poczty zachowuje się podobnie jak w świecie offline: kilka poważnych incydentów sprawia, że partnerzy zaczynają patrzeć podejrzliwie na każdą kolejną wiadomość. Wyciągnięcie domeny z czarnych list jest czasochłonne i często wymaga zmian technicznych, edukacji pracowników oraz cierpliwości.

Jak naprawdę przebiega droga e‑maila i gdzie w tym wszystkim SPF/DKIM/DMARC

Każda wiadomość e‑mail przechodzi podobną drogę, niezależnie od tego, czy wysyła ją klient webmail, Outlook, Thunderbird czy system ERP. W dużym uproszczeniu wygląda to tak:

1. Klient poczty łączy się z serwerem SMTP nadawcy (Twoim MTA) i przekazuje mu wiadomość.
2. Serwer nadawcy sprawdza uprawnienia użytkownika, podpisuje e‑mail DKIM (jeżeli jest skonfigurowany) i wysyła wiadomość do serwera odbiorcy, który znajduje na podstawie rekordu MX w DNS domeny adresata.
3. Serwer odbiorcy odbiera wiadomość i wykonuje zestaw testów: antyspam, antywirus, SPF (czy IP serwera nadawcy jest autoryzowane dla tej domeny), DKIM (czy podpis cyfrowy się zgadza) i DMARC (jak traktować wiadomości niezgodne z polityką).
4. Na podstawie wyniku testów wiadomość ląduje w skrzynce odbiorczej, folderze spam, jest oznaczona ostrzeżeniem, albo od razu odrzucana.

SPF, DKIM i DMARC są zdefiniowane jako rekordy TXT w DNS domeny. Filtry antyspamowe serwerów odbiorczych czytają te rekordy przy każdym przychodzącym mailu i dopasowują to, co „mówi DNS”, do realnych parametrów połączenia (IP, podpis). To dlatego porządek prac wygląda sensownie dopiero wtedy, kiedy najpierw poprawnie działa DNS i wysyłka/odbiór poczty, a później domena jest uszczelniana politykami.

Mit: „skoro mail dochodzi, to jest wszystko dobrze”

Częstym scenariuszem jest sytuacja, w której firma wysyła wiadomości z nowej domeny lub nowego serwera i: część klientów widzi maile normalnie, część ma je w spamie, u części maile znikają „bez śladu”. Łatwo wtedy wysnuć wniosek: „skoro ktoś to dostał, to konfiguracja SPF/DKIM/DMARC nie jest taka ważna”.

Rzeczywistość wygląda inaczej. Większość dużych dostawców poczty nie blokuje od razu wszystkich niespełniających standardów maili. Część przepuszcza, ale z niższym scoringiem. Część odkłada je do spamu, część odrzuca, jeżeli domena ma już złą reputację. Brak SPF, DKIM i DMARC nie zawsze zablokuje pocztę, ale systematycznie pogarsza reputację i zwiększa ryzyko, że ważna wiadomość biznesowa nie dotrze do adresata.

Mit: „jak dodam bardzo restrykcyjny DMARC od razu na reject, to będę superbezpieczny”. W praktyce zbyt agresywna polityka DMARC na źle przygotowanej infrastrukturze powoduje, że legalne maile z systemów CRM, newsletterów lub faktur elektronicznych zaczynają być odrzucane, bo nie przechodzą kontroli. Bez etapu „monitorowania” i zbierania raportów można samemu sobie wyłączyć istotną część komunikacji.

Samodzielny serwer vs zewnętrzny dostawca poczty

Konieczność podjęcia decyzji „budujemy swój serwer czy kupujemy usługę” wraca w praktycznie każdej firmie rosnącej powyżej kilku osób. Teoretycznie własny serwer daje pełną kontrolę, możliwość dowolnego tuningu i brak abonamentu per skrzynka. W praktyce chmura rozwiązuje większość problemów z reputacją IP, zapewnia wysoką dostępność i odciąża z utrzymywania infrastruktury 24/7.

Własny serwer (VPS lub dedyk) wymaga zadbania o:

• konfigurację MTA (Postfix/Exim) i IMAP (Dovecot etc.),
• certyfikaty TLS i ich aktualizację,
• brak otwartego relay’a i ochronę przed nadużyciami,
• monitorowanie logów, blacklist i reputacji IP,
• backupy skrzynek pocztowych.

Przy korzystaniu z Google Workspace, Microsoft 365 czy podobnych systemów dostajemy gotową, dość dobrze zabezpieczoną platformę. Rola administratora sprowadza się wtedy głównie do konfiguracji DNS (SPF, DKIM, DMARC, MX, często też CNAME do weryfikacji), wdrożenia 2FA dla użytkowników, ustalenia polityk haseł oraz reagowania na incydenty bezpieczeństwa na poziomie kont użytkowników.

Wybór modelu: własny serwer czy usługa w chmurze

Opcja 1: własny serwer na VPS/dedyku – maksymalna kontrola i maksymalna odpowiedzialność

Postawienie serwera poczty na własnym VPS lub serwerze dedykowanym jest kuszące: jednorazowa (lub stosunkowo stała) opłata za serwer, dowolna liczba skrzynek i brak zależności od jednego, konkretnego SaaS. To rozwiązanie szczególnie lubiane w firmach technologicznych i u administratorów, którzy chcą mieć „wszystko u siebie”.

Zalety:

• Pełna kontrola nad konfiguracją MTA i politykami bezpieczeństwa.
• Możliwość integracji z własnymi systemami (CRM, ERP, helpdesk) bez ograniczeń narzucanych przez dostawcę.
• Brak dodatkowych opłat za „kolejną skrzynkę” – liczy się wydajność serwera.

Wyzwania:

• Odpowiedzialność za aktualizacje systemu, patchowanie i konfigurację.
• Konsekwencje błędów bezpieczeństwa – jeden źle zabezpieczony formularz lub brute-force na konto może zamienić serwer w źródło spamu.
• Reputacja IP: jeżeli adres, który dostajesz od dostawcy VPS, ma złą historię, część serwisów będzie z definicji bardziej podejrzliwa wobec Twojej poczty.

Mit: „jak mam własny serwer, to jestem niezależny i bezpieczny”. To prawda tylko pod warunkiem, że ktoś realnie dba o ten serwer: obserwuje logi, reaguje na incydenty, rozumie konsekwencje zmian w konfiguracji i potrafi negocjować z operatorami blacklist, gdy coś pójdzie nie tak.

Opcja 2: poczta w ramach hostingu WWW – wygoda, ale współdzielona reputacja

Wielu hostingodawców www oferuje pocztę „w pakiecie” z serwerem WWW. Dla mikrofirm i freelancerów to na początku wygodne rozwiązanie: jeden panel, jedna faktura, prosta konfiguracja. Jednak cena tej wygody to współdzielenie IP z dziesiątkami lub setkami innych klientów, którzy mogą nie dbać o swoje bezpieczeństwo tak jak Ty.

Jeżeli na tym samym IP ktoś prowadzi masową wysyłkę z kiepską listą mailingową, używa nieaktualnego CMS-a lub padł ofiarą malware, Twoje wiadomości mogą trafiać do spamów mimo poprawnej konfiguracji SPF, DKIM i DMARC. Dla serwera odbiorcy liczy się reputacja adresu IP i domen, które z niego wysyłają. Przy hostingu współdzielonym masz wpływ tylko na swoją domenę, ale nie na zachowanie sąsiadów.

Ta opcja jest sensowna, gdy:

• firma jest bardzo mała (1–3 osoby),
• komunikacja mailowa jest umiarkowana, bez dużych wolumenów sprzedażowych mailingów,
• hostingodawca ma dobre opinie pod kątem reputacji poczty i reagowania na zgłoszenia.

Jeżeli planowany jest intensywny mailing marketingowy, integracje systemowe czy krytyczna komunikacja B2B, często lepiej od razu wybrać dedykowaną usługę pocztową lub model hybrydowy: strona WWW na hostingu współdzielonym, poczta u specjalizowanego dostawcy.

Opcja 3: dostawcy „enterprise” – wysoka jakość, ale DNS i tak jest po Twojej stronie

Google Workspace, Microsoft 365, Proton Mail i podobne platformy dostarczają pocztę wraz z całym ekosystemem narzędzi: dokumenty, współdzielone kalendarze, systemy DLP, mechanizmy antyspamowe klasy enterprise. To bezkonkurencyjne rozwiązanie, gdy firma rośnie, a serwerów i aplikacji przybywa.

Trzeba jednak zrozumieć, gdzie kończy się wygoda, a zaczyna odpowiedzialność administratora:

• rekordy MX, SPF, DKIM i DMARC konfigurujesz sam w swoim panelu DNS – dostawca daje gotowe wartości, ale to Ty wprowadzasz je poprawnie lub błędnie,
• autoryzacja użytkowników (2FA, polityki haseł) leży po Twojej stronie,
• monitorowanie logowań, reagowanie na zgłoszenia phishingu i edukacja pracowników nie dzieje się „magicznie” – to obowiązki wewnętrzne.

Mit: „jak wykupię Microsoft 365/Google Workspace, SPF, DKIM i DMARC same się ustawią”. Te systemy bardzo ułatwiają konfigurację, ale nie wpisują rekordów DNS za Ciebie. W praktyce większość problemów z dostarczalnością poczty przy tych rozwiązaniach wynika z niedokończonej lub błędnej konfiguracji DNS, a nie z błędów dostawcy.

Koszty całkowite: nie tylko opłata za serwer czy licencje

Przy porównaniu modeli nie można patrzeć wyłącznie na faktury za infrastrukturę. Równie ważne jest to, kto i ile czasu poświęci na administrację, aktualizacje, reagowanie na incydenty i rozwiązywanie problemów użytkowników.

Koszty „ukryte” to m.in.:

• czas administratora na konfigurację SPF, DKIM, DMARC i rozwiązywanie konfliktów między systemami (CRM, newsletter, helpdesk),
• czas potrzebny na analizę raportów DMARC i reagowanie na ewentualne nadużycia domeny,
• czas spędzony na odpisywanie klientom: „mail wyszedł, ale nie dotarł, czy możesz sprawdzić spam?”,
• koszt reputacyjny błędów: utracone zapytania ofertowe, opóźnione faktury, nieodebrane powiadomienia.

Dla małej firmy 10–20 osób typowym, rozsądnym wyborem jest dziś poczta w chmurze (Google Workspace, Microsoft 365 lub solidny dostawca poczty biznesowej), z dobrze skonfigurowanymi rekordami DNS. Własny serwer poczty ma sens tam, gdzie istnieje dedykowany zespół techniczny lub specyficzne wymagania (compliance, nietypowe integracje, prywatność na poziomie nieakceptowalnym dla chmury publicznej).

Przygotowanie domeny i DNS – baza pod SPF, DKIM i DMARC

Porządek organizacyjny: kto za co odpowiada

Spora część problemów z pocztą firmową wynika nie z braku wiedzy technicznej, ale z chaosu organizacyjnego. Typowa sytuacja: domena jest zarejestrowana u jednego operatora, DNS jest zarządzany u drugiego, strona stoi na trzecim hostingu, poczta jest u czwartego, a newsletter wysyła jeszcze piąta usługa. Gdy zaczyna się polowanie na błąd SPF czy DMARC, każdy odsyła do kogoś innego.

Na start potrzebne są trzy jasne informacje:

• Kto jest rejestratorem domeny – gdzie opłacany jest sam adres internetowy (np. nazwa.pl, OVH, home.pl, Aftermarket).

Gdzie faktycznie są Twoje rekordy DNS

Samo ustalenie rejestratora domeny to za mało. Kluczowe jest miejsce, w którym trzymane są rekordy DNS – to tam definiujesz SPF, DKIM i DMARC. W praktyce panuje tu spory bałagan: domena kupiona u jednego operatora, ale DNS „przepięty” na Cloudflare czy panel hostingu WWW.

Żeby nie działać w ciemno, trzeba ustalić:

• Serwery nazw (NS) domeny – to one wskazują, kto realnie odpowiada za DNS.
• Dostęp do panelu DNS – kto ma login, kto go administruje i jakie są procedury zmian (np. kto akceptuje dodanie nowego rekordu SPF dla systemu mailingowego).

NS sprawdzisz choćby poleceniem dig NS twojadomena.pl lub przez narzędzia typu „whois” online. Jeżeli w wyniku widać np. ns1.cloudflare.com i ns2.cloudflare.com, to wszelkie zmiany SPF/DKIM/DMARC robisz w panelu Cloudflare, a nie u rejestratora domeny.

Mit, który ciągle wraca: „DNS konfiguruję tam, gdzie opłacam domenę”. Rzeczywistość bywa inna – rejestrator może tylko delegować domenę na zewnętrzny system DNS i wtedy jakakolwiek edycja rekordów „u rejestratora” nie ma żadnego wpływu.

Inwentaryzacja źródeł wysyłki – pełna lista zanim dotkniesz SPF

SPF i DMARC mają sens dopiero wtedy, gdy znasz wszystkie systemy wysyłające maile w imieniu domeny. W praktyce takich źródeł jest więcej, niż się początkowo wydaje. Zanim zaczniesz wpisywać rekord SPF „z głowy”, zrób listę systemów, które faktycznie wysyłają pocztę:

• główny serwer poczty użytkowników (Google Workspace, Microsoft 365, serwer VPS z Postfixem itd.),
• CRM (np. maile „opiekun klienta” wysyłane z domeny firmowej),
• system newsletterowy / marketing automation,
• system faktur / ERP, który wysyła invoice’y z adresu faktury@domena.pl,
• helpdesk / system ticketowy,
• aplikacje SaaS, które pozwalają ustawić nadawcę w Twojej domenie (np. narzędzia do ankiet, webinarów, e-commerce),
• sklepy internetowe, formularze kontaktowe na stronie, skrypty cron na serwerze WWW,
• urządzenia fizyczne: drukarki sieciowe, skanery, UPS-y, systemy alarmowe wysyłające powiadomienia e-mail.

Dopiero mając taką listę, możesz sensownie planować SPF i podpisy DKIM. Typowy błąd: ustawiony SPF tylko dla głównej poczty, a potem zdziwienie, że maile z CRM-a dziwnie częściej lądują w spamie.

Rozdzielenie ról domenowych – subdomeny do zadań specjalnych

Nie każdy system musi wysyłać maile z tej samej, głównej domeny. Bardzo często bezpieczniej i czyściej jest rozdzielić funkcje na subdomeny. Przykład praktyczny:

• firma.pl – komunikacja osobista pracowników (handlowcy, zarząd, biuro),
• news.firma.pl – newsletter i mailing marketingowy,
• support.firma.pl – helpdesk i powiadomienia systemowe,
• billing.firma.pl – faktury i rozliczenia.

Każdej z takich (sub)domen możesz przypisać osobne rekordy SPF, DKIM i DMARC, a także osobne polityki. Dla domeny używanej do rozliczeń z kluczowymi klientami możesz wdrożyć DMARC na poziomie „reject” wcześniej niż dla domeny marketingowej, gdzie wciąż eksperymentujesz z różnymi usługami mailingowymi.

Mit, który utrudnia życie: „wszystko musi iść z głównej domeny, bo inaczej klienci się pogubią”. Klientom jest bardziej obojętne, czy fakturę wysyła faktury@firma.pl, czy faktury@billing.firma.pl, byle nadawca był spójny i rozpoznawalny. Za to Ty zyskujesz dużo większą elastyczność i bezpieczeństwo.

Techniczne ABC: rodzaje rekordów, których będziesz używać

Przy konfiguracji poczty ochronnej używasz głównie trzech typów rekordów DNS:

• TXT – tu umieszczasz SPF, DMARC i często klucze DKIM (choć DKIM bywa w rekordach typu CNAME, zależnie od dostawcy),
• MX – wskazują serwery odbierające pocztę dla domeny,
• CNAME – używany m.in. do delegowania selektorów DKIM na zewnętrznego dostawcę lub do weryfikacji domeny w usługach SaaS.

SPF i DMARC są zawsze w rekordach TXT. DKIM jest w TXT lub w CNAME – np. w Google Workspace klucz DKIM bywa udostępniany jako TXT, a u części dostawców mailingowych wpisujesz CNAME wskazujący na ich infrastrukturę. Dlatego zanim zaczniesz dopisywać „coś, co wygląda jak DKIM”, sprawdź w dokumentacji, jak ma to być zrobione konkretnie w danej usłudze.

Bezpieczne wprowadzanie zmian w DNS

Eksperymentowanie na produkcyjnej domenie „na żywca” to proszenie się o kłopoty. Zanim cokolwiek zmienisz, zwłaszcza w rekordach SPF i MX, zadbaj o kilka prostych zasad:

• Backup rekordów – zrób zrzut wszystkich wpisów DNS (z panelu lub poleceniami typu dig/host). Nawet prosta kopia w pliku tekstowym ratuje nerwy.
• Niski TTL dla rekordów, które modyfikujesz – np. ustaw 300 sekund zamiast kilku godzin. Umożliwia to szybkie odwrócenie zmian i krótszy czas propagacji.
• Testowanie SPF w narzędziach walidujących składnię (np. dig txt + dedykowane testery online) przed przejściem na ostrzejsze polityki DMARC.

Drobna literówka w rekordzie MX czy SPF potrafi odciąć całą firmę od poczty. Lepiej poświęcić kilka minut na testy i kopię, niż kilka godzin na dochodzenie, „kto kliknął” i kiedy.

Konfiguracja podstawowego serwera poczty – SMTP, IMAP, bezpieczeństwo transportu

Rola MTA i MDA – co faktycznie konfigurujesz

Przy własnym serwerze poczty masz do czynienia z kilkoma komponentami. Skrótowo:

• MTA (Mail Transfer Agent) – np. Postfix, Exim; odpowiada za przyjmowanie i wysyłanie wiadomości przez SMTP.
• MDA/IMAP server – np. Dovecot; przechowuje wiadomości w skrzynkach i udostępnia je klientom (Outlook, Thunderbird) przez IMAP/POP3.
• Serwer uwierzytelniania – często zintegrowany z Dovecotem lub systemem (np. uwierzytelnianie przez LDAP, SQL, pliki).

SPF, DKIM i DMARC działają „nad” tym wszystkim, ale to od poprawnej konfiguracji MTA zależy, czy w ogóle prześlesz wiadomość i czy będzie ona oznaczona jako pochodząca od Twojej domeny (Return-Path, nagłówki Received, podpis DKIM).

SMTP – podstawowe założenia konfiguracji wychodzącej

Dla MTA konfigurujesz zwykle dwa scenariusze:

• przyjmowanie poczty z zewnątrz (serwery innych domen wysyłają do Ciebie),
• wysyłanie poczty od Twoich użytkowników i systemów na świat.

Jeżeli stawiasz Postfixa, przy wysyłce poczty użytkowników kluczowe są:

• konfiguracja submission na porcie 587 (lub 465 dla SMTPS) z wymuszonym STARTTLS/TLS,
• wymaganie uwierzytelnienia (SASL) dla użytkowników – żadnego otwartego „relayowania” dla świata,
• ustalenie poprawnego myhostname, mydomain i myorigin, aby nagłówki nie zdradzały lokalnych, dziwnych nazw hostów typu vps123.hosting.local.

Mit: „wystarczy otworzyć port 25, a reszta się jakoś zrobi”. Bez submission z uwierzytelnianiem zaczną się pojawiać dziwne logowania, próby brute-force i – prędzej czy później – udane przejęcie konta, z którego poleci spam.

IMAP i POP3 – dostęp użytkowników do skrzynek

Większość nowych wdrożeń stawia na IMAP, POP3 zostawiając legacy aplikacjom. Kluczowe punkty konfiguracji Dovecota (lub podobnego serwera):

• wymuszenie TLS dla IMAP/POP3 – najlepiej całkowite wyłączenie niezaszyfrowanych portów,
• spójna polityka haseł (długość, złożoność, rotacja tam, gdzie wymagają tego procedury),
• logowanie prób uwierzytelnienia i ewentualne blokady IP po wielu nieudanych próbach (fail2ban i podobne mechanizmy).

Jeżeli użytkownik łączy się po IMAP bez szyfrowania, hasło leci w sieci praktycznie w formie jawnej. Przy pracy zdalnej oznacza to, że każde niezaufane Wi-Fi może stać się źródłem przejętego konta pocztowego, a dalej – przejętej reputacji domeny.

Certyfikaty TLS – Let’s Encrypt i automatyzacja

Transport poczty jest dziś de facto szyfrowany „z definicji”. Trzeba więc zadbać o:

• certyfikat TLS dla hosta serwera poczty (np. mail.firma.pl),
• aktualizację certyfikatów – automatyzacja, np. poprzez certbot lub klienta ACME wbudowanego w panel.

Przy Let’s Encrypt konfiguracja sprowadza się najczęściej do:

1. zapewnienia, że mail.firma.pl wskazuje w DNS na Twój serwer,
2. wygenerowania certyfikatu (HTTP-01 lub DNS-01, w zależności od dostępu),
3. powiązania certyfikatu z Postfixem i Dovecotem,
4. ustawienia automatycznego odnowienia (cron/systemd timer) i reloadu usług po odnowieniu.

Zdarza się mit: „jak certyfikat jest nieważny, to tylko przeglądarka się obraża”. W przypadku poczty część klientów (szczególnie mobilnych) po prostu przestaje się łączyć, użytkownicy klikają „dalej, dalej, akceptuj” bez czytania, a realne MITM pozostaje niezauważone.

Bezpieczeństwo transportu między serwerami (SMTP TLS)

Nawet jeżeli użytkownicy łączą się szyfrowanym IMAP-em, sama wymiana poczty między serwerami odbywa się przez SMTP. Aby to zabezpieczyć:

• włącz i wymuś SMTP TLS (parametry typu smtpd_tls_security_level = may / encrypt w Postfixie),
• monitoruj raporty MTA-STS/TLS-RPT, jeśli je wdrożysz – pozwalają wykryć problemy z negocjacją TLS między serwerami.

Nie wszystkie domeny na świecie wymagają TLS, ale coraz więcej dużych operatorów traktuje brak szyfrowania jako czerwone światło. Nawet jeśli wiadomość „jakoś przejdzie”, reputacja Twojego serwera w ich oczach nie rośnie.

Podstawowe zabezpieczenia antyspamowe po stronie serwera

Samo SPF/DKIM/DMARC nie chroni Cię przed napływem spamu – to bardziej narzędzia reputacyjne i autoryzacyjne. Na własnym serwerze potrzebujesz jeszcze kilku elementów:

• filtr antyspamowy (SpamAssassin, Rspamd lub rozwiązanie komercyjne),
• kontrola RBL (blacklisty IP) – ale z rozsądnym doborem list, żeby nie odrzucać połowy internetu,
• limity wysyłki na użytkownika / IP – liczbę wiadomości na godzinę/dobę, by zminimalizować szkody przy przejęciu konta,
• ochrona przed słownikowymi atakami na adresy (np. odrzucanie wiadomości do nieistniejących skrzynek z odpowiednim komunikatem).

Częsty mit: „jak będę miał dobry filtr antyspamowy, to SPF i DMARC są zbędne”. W rzeczywistości to warstwy tej samej ochrony. Filtry analizują treść i zachowanie, SPF/DKIM/DMARC – zgodność nadawcy z uprawnieniami domeny. Najlepsze efekty są przy łączeniu obu podejść.

SPF – jak działa, jak go poprawnie zdefiniować i nie strzelić sobie w stopę

Istota SPF – kto może wysyłać w imieniu domeny

SPF (Sender Policy Framework) to nic innego jak oświadczenie w DNS: „te serwery IP i te domeny są uprawnione do wysyłania poczty z mojej domeny w polu MAIL FROM/Return-Path”. Serwer odbiorcy bierze adres nadawcy na poziomie protokołu SMTP, sprawdza domenę i ściąga rekord SPF w DNS tej domeny, a potem ocenia, czy IP wysyłającego się tam mieści.

Ważny szczegół: SPF dotyczy głównie adresu technicznego (MAIL FROM), a nie tego, co widać w polu „From:” w kliencie pocztowym. W praktyce większość poważnych systemów dba o spójność tych dwóch, ale atakujący chętnie ją rozjeżdżają. Dlatego SPF sam w sobie nie wystarcza, stąd rola DMARC.

Składnia SPF – jeden rekord TXT, żadnych duplikatów

Najprostszy, poprawny rekord SPF wygląda np. tak:

Praktyczny przykład prostego rekordu SPF

Najprostsza, sensowna deklaracja SPF dla domeny używanej wyłącznie na jednym serwerze pocztowym wygląda tak:

example.pl.  3600  IN  TXT  "v=spf1 mx -all"

Znaczenie poszczególnych elementów:

• v=spf1 – wersja SPF, obowiązkowy początek rekordu,
• mx – zezwól wszystkim adresom IP, na które wskazują rekordy MX domeny, wysyłać pocztę w jej imieniu,
• -all – wszystko inne traktuj jako niedozwolone (twarde fail).

Taki wzorzec ma sens, gdy cała poczta wychodzi z serwera, który jest jednocześnie odbierającym (jego IP znajduje się w rekordach MX). Jeśli wysyłasz także z innych źródeł (np. SaaS do newsletterów, system fakturowy, serwer aplikacyjny), trzeba je dodać do SPF w kontrolowany sposób.

Mechanizmy SPF – co właściwie można wpisać

SPF udostępnia kilka mechanizmów definiowania, kto może wysyłać pocztę. Najczęściej wykorzystywane to:

• ip4: – pojedynczy adres lub sieć IPv4, np. ip4:203.0.113.10 lub ip4:203.0.113.0/24,
• ip6: – odpowiednik dla IPv6,
• mx – adresy IP ze wszystkich rekordów MX domeny,
• a – adres(y) IP z rekordu A/AAAA domeny (lub wskazanej subdomeny),
• include: – dołącz politykę SPF innej domeny, np. dostawcy mailingu,
• exists: – mechanizm „zaawansowany” do warunkowego dopasowania (rzadko potrzebny w małej/średniej firmie),
• all – łapka na końcu – wszystko, co nie zostało dopasowane wcześniej.

Każdy mechanizm można poprzedzić kwalifikatorem:

• + (lub domyślnie brak znaku) – pass, zaakceptuj,
• - – fail, odrzuć,
• ~ – softfail, „raczej nie”, zwykle oznaczane jako podejrzane, ale niekoniecznie odrzucane,
• ? – neutral, „nie mam zdania”.

Przykład bardziej złożonej, ale wciąż czytelnej polityki:

"v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/24 include:spf.protection.outlook.com -all"

Tutaj: jedno konkretne IP, cała podsieć serwerów aplikacyjnych, plus cały zakres serwerów Microsoft 365, a poza tym twardy zakaz.

Jedna domena – jeden rekord SPF

Częsty błąd: dodawanie kolejnych rekordów TXT z v=spf1 przy każdym nowym usługodawcy. DNS formalnie na to pozwala, ale mechanizm SPF już nie. Dla danej domeny ma być dokładnie jeden rekord SPF (jedna wartość z v=spf1), ewentualnie rozbity na kilka fragmentów tekstowych w jednym rekordzie TXT, jeśli przekraczasz limit długości linii.

Jeżeli panel DNS nie krzyczy, a jakieś narzędzie do walidacji SPF zgłasza „multiple SPF records”, problem jest po Twojej stronie. W praktyce trzeba scalić wszystkie deklaracje w jeden spójny zapis. Przykład błędu:

example.pl.  IN  TXT  "v=spf1 mx -all"
example.pl.  IN  TXT  "v=spf1 include:spf.mailprovider.com -all"

Poprawna wersja powinna wyglądać mniej więcej tak:

example.pl.  IN  TXT  "v=spf1 mx include:spf.mailprovider.com -all"

Mit spotykany w panelach hostingowych: „jak dodam drugi SPF, to serwery odbiorcze same wybiorą właściwy”. W rzeczywistości wiele implementacji SPF kończy ocenę błędem i traktuje domenę podejrzliwie.

Limity SPF – 10 zapytań DNS i koniec

Każde użycie mechanizmów include:, a, mx, ptr czy exists: może generować dodatkowe zapytania DNS przy sprawdzaniu SPF. Standard wprowadza limit: maksymalnie 10 odwołań DNS na jedno sprawdzenie SPF.

Jeżeli go przekroczysz, wynik SPF to techniczne permerror, co dla niektórych odbiorców oznacza traktowanie wiadomości tak, jakby SPF nie przeszedł. Przy kilku usługodawcach mailingu i skomplikowanych łańcuchach include: można niepostrzeżenie do tego doprowadzić.

Przykład problematycznej konfiguracji:

"v=spf1 include:_spf.service1.com include:_spf.service2.com include:_spf.service3.com include:_spf.service4.com include:_spf.service5.com -all"

Każdy z tych serwisów mógł już w swoim SPF dodać 2–3 własne include:, co razem przekracza limit. Rozwiązaniem jest uproszczenie polityki, scalanie zakresów IP tam, gdzie to możliwe, albo – w ostateczności – użycie dedykowanej subdomeny z prostszym SPF dla części ruchu (np. news.example.pl tylko dla systemu newsletterowego).

Typowe scenariusze SPF dla małej i średniej firmy

Dla większości firm da się wyróżnić kilka powtarzalnych układów. Dobrze je nazwać po imieniu, zanim zaczniesz wpisywać losowe include:.

1. Tylko własny serwer pocztowy

Firma korzysta wyłącznie z jednego serwera (on-premise lub VPS) z poprawnym rekordem MX. Przykład:

"v=spf1 mx -all"

Można też wskazać adres IP wprost:

"v=spf1 ip4:203.0.113.10 -all"

Druga wersja jest czytelniejsza, jeśli MX-ów jest więcej lub planujesz wkrótce zmienić strukturę MX.

2. Poczta w chmurze (np. Microsoft 365, Google Workspace)

Najczęściej wykorzystywany wzorzec to deklaracja sugerowana przez dostawcę. Przykładowo, dla Microsoft 365:

"v=spf1 include:spf.protection.outlook.com -all"

Dla Google Workspace:

"v=spf1 include:_spf.google.com -all"

Czasem pojawia się pokusa, aby „na zapas” zostawić ~all lub dopisać wszystkie możliwe opcje. W rzeczywistości trzymanie się rekomendacji dużego dostawcy jest bezpieczniejsze niż własna „twórczość” z /16 wpisanymi z palca.

3. Poczta w chmurze + zewnętrzny system mailingowy

Typowy przypadek: użytkownicy korzystają z Microsoft 365, a marketing wysyła kampanie z SendGrid/Mailgun itp. Wtedy rekordu SPF nie duplikuje się, tylko rozszerza:

"v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all"

Pod include: trzeba wpisać dokładnie to, co sugeruje dostawca mailingu. Jeśli ma dedykowaną nazwę SPF (np. _spf.sendgrid.net), użyj jej. Nie zgaduj. Widziane w praktyce „include:mail.sendgrid.com” potrafi być całkowicie bez sensu, bo ta nazwa nie zawiera poprawnego rekordu SPF.

4. Dedykowana subdomena dla systemów automatycznych

Jeżeli ruch marketingowy i transakcyjny jest intensywny, sensowniej bywa wydzielić subdomenę, np. news.example.pl czy notify.example.pl, i przypisać ją wyłącznie do danego systemu. Wtedy:

• domena główna example.pl ma skromny, przejrzysty SPF (np. tylko MX),
• subdomena news.example.pl ma SPF wskazujący konkretnego usługodawcę mailingu,
• DMARC można ustawić osobno dla subdomen, ograniczając wpływ ewentualnych błędów.

Taki podział bywa przydatny, gdy marketing bardzo eksperymentuje z narzędziami i nie chcesz, by każda zmiana dostawcy newsletterów oznaczała naruszanie SPF głównej domeny firmy.

Dobór polityki końcowej: -all vs ~all

Polityka na końcu rekordu SPF decyduje, co się dzieje z nadawcami niezgodnymi z regułą. Dwa najpopularniejsze podejścia:

• -all – mówi: „każdy, kto nie pasuje do wcześniejszych mechanizmów, jest nieuprawniony” (twardy fail),
• ~all – sygnalizuje bardziej miękko: „to raczej nie jest mój serwer, ale Ty, odbiorco, zrób z tym, co uważasz” (softfail).

Bez DMARC wiele serwerów odbiorczych traktuje -all i ~all podobnie – reputacja nadawcy spada, wiadomość ląduje w spamie lub jest oznaczana jako podejrzana. Różnicę widać dopiero przy twardszych politykach DMARC, które biorą wynik SPF jako jeden z czynników.

Bezpieczny schemat wdrożenia w istniejącej, produkcyjnej domenie:

1. zdefiniuj możliwie kompletny SPF z końcówką ~all,
2. zbierz dane z logów i raportów DMARC (o ile już działają), czy coś uzasadnionego nie trafia w softfail,
3. dopracuj SPF (dodaj brakujące mechanizmy),
4. po pewnym czasie ostrożnie przejdź na -all, jeśli nic legalnego nie jest odrzucane.

Mit: „jak dam -all, to na pewno nic mi nie dojdzie, więc lepiej nigdy tego nie robić”. W praktyce dobrze ustawiony SPF z -all istotnie utrudnia podszywanie się pod Twoją domenę, szczególnie gdy dołączy się do tego DMARC.

SPF a forwarding i aliasy – dlaczego poczta „znika”

Klasyczny problem: użytkownik ma skrzynkę firmową, która przekazuje pocztę dalej, np. na prywatny adres w dużym portalu. Nadawca wysyła wiadomość zgodną z SPF do Twojej domeny, Twój serwer przekazuje ją dalej, a serwer docelowy sprawdza SPF… dla IP Twojego serwera przekazującego, a nie oryginalnego nadawcy. Jeśli Twój serwer nie jest uprawniony w SPF tego nadawcy, SPF na kolejnym hopie się wywala.

To efekt uboczny samego projektu SPF – nie ma w nim mechanizmu „przenoszenia” wyniku przy zwykłym forwardingu. Dlatego:

• prosty forwarding do zewnętrznych skrzynek potrafi zepsuć SPF,
• część operatorów stosuje SRS (Sender Rewriting Scheme), czyli zmianę adresu MAIL FROM na własny, aby SPF był zgody z ich domeną,
• bez SRS forwarding bywa loterią – szczególnie przy twardych politykach DMARC nadawców.

Jeżeli masz pod kontrolą serwer pośredniczący, rozważ wdrożenie SRS lub zastąp forwardingiem typu „store & fetch” (POP3/IMAP fetcher po stronie zewnętrznej skrzynki zamiast przekierowania w locie).

SPF a HELO/EHLO – dodatkowy element układanki

Część serwerów odbiorczych sprawdza SPF nie tylko dla domeny w MAIL FROM, ale także dla domeny zadeklarowanej w HELO/EHLO (pierwsza faza rozmowy SMTP). Jeżeli Twój serwer przedstawia się jako vps123.hosting.local, a nie jako publiczny mail.example.pl, efekt może być dość nieprzewidywalny.

Rozsądna konfiguracja przewiduje:

• publiczną nazwę hosta MTA, spójną z rekordem PTR IP i rekordem A (np. mail.example.pl),
• SPF dopuszczający to IP jako uprawnionego nadawcę,
• brak „dziwnych” nazw lokalnych ujawnianych w HELO/EHLO.

Niektóre systemy antyspamowe bardziej ufają serwerom, które mają przejrzyste dane: poprawny reverse DNS, spójne HELO, sensowny SPF. Inne po prostu obniżają punktację za niespójność. Zdarza się więc sytuacja, że SPF „na papierze” jest poprawny, ale przez źle ustawiony HELO reputacja i tak leci w dół.

Testowanie SPF – narzędzia i praktyczne kroki

Zanim zaczniesz zmieniać politykę na ostrzejszą, sensownie jest obejrzeć SPF z kilku stron. Najprostszy zestaw kontroli to:

• dig txt example.pl – czy widzisz dokładnie jeden rekord SPF, bez literówek,
• dedykowane testery SPF (online), które pokażą, ile zapytań DNS wykonuje SPF i czy nie zbliżasz się do limitów,
• wysłanie wiadomości testowej do skrzynki w dużym serwisie (Gmail, Outlook.com) i analiza nagłówków, zwłaszcza linii typu Received-SPF.

W nagłówkach serwera odbiorczego widać często całe rozumowanie: z jakiego IP przyszła wiadomość, jaka domena została sprawdzona, co na to SPF. Przy zmianach w produkcji dobrze jest na chwilę zwiększyć poziom logowania serwera pocztowego, aby mieć pełny kontekst w razie niespodzianek.

SPF w kontekście DMARC – spójność domen