DMARC, SPF i DKIM: dlaczego ktoś wysyła faktury z Twojej domeny i jak to zablokować w 30 dni

Klient dzwoni w czwartek po południu i pyta, dlaczego na fakturze jest inny numer konta niż zwykle. Dokument wygląda normalnie: logo się zgadza, stopka się zgadza, nadawca to ksiegowosc@twojafirma.pl. Tylko że nikt w firmie tej faktury nie wysłał.

Tego samego popołudnia handlowiec zgłasza coś pozornie niezwiązanego. Od tygodnia oferty do nowych klientów nie docierają. Sprawdził u dwóch osób, u obu leżały w spamie.

To nie są dwa problemy. To jeden problem, który ma dwa objawy.

Poniżej znajdziesz wyjaśnienie, skąd się to bierze, jak w kwadrans sprawdzić, czy dotyczy Twojej firmy, i jak to naprawić w miesiąc bez ryzyka, że po drodze zablokujesz własną pocztę.

W skrócie: SPF, DKIM i DMARC to trzy wpisy w DNS Twojej domeny, dzięki którym serwery odbiorców mogą sprawdzić, czy wiadomość naprawdę pochodzi od Twojej firmy, i zdecydować, co zrobić z tą, która nie pochodzi.

Dwa objawy, jedna przyczyna

Twoja domena ma reputację. Nie w sensie marketingowym, tylko całkiem technicznym: serwery pocztowe na całym świecie prowadzą o niej statystyki. Ile wiadomości z niej wyszło, ile trafiło do spamu, ile zostało oznaczonych jako oszustwo, ile udało się zweryfikować.

Kiedy nikt nie pilnuje, kto może wysyłać pocztę w imieniu Twojej domeny, dzieją się dwie rzeczy naraz.

Po pierwsze, każdy może się pod nią podszyć. Wysłanie maila z adresem ksiegowosc@twojafirma.pl w polu nadawcy nie wymaga żadnego dostępu do Twoich systemów. Nie trzeba się nigdzie włamywać ani znać żadnego hasła.

Po drugie, Twoja własna poczta zaczyna wyglądać podejrzanie. Skoro serwer odbiorcy widzi wiadomości z tej domeny wysyłane z przypadkowych serwerów na całym świecie i nie ma jak sprawdzić, które są prawdziwe, traktuje wszystkie z rezerwą. Łącznie z ofertą, którą handlowiec wysłał dziesięć minut temu.

Naprawienie jednego naprawia drugie. To ta sama warstwa konfiguracji.

Dlaczego poczta w ogóle na to pozwala

Protokół, na którym działa e-mail, powstał w latach osiemdziesiątych, w sieci, w której wszyscy się znali. Nikt nie zakładał, że ktokolwiek będzie kłamał na temat tego, kim jest.

Dlatego pole „Od”, które widzisz w programie pocztowym, to zwykły tekst. Można w nim wpisać cokolwiek. Działa to dokładnie jak nadawca napisany długopisem na kopercie: poczta go nie weryfikuje, bo nie ma jak. Dostarcza list tam, gdzie jest adresat, a to, co jest napisane w lewym górnym rogu, to deklaracja nadawcy, nie fakt.

SPF, DKIM i DMARC to warstwa dobudowana później, właśnie po to, żeby tę deklarację dało się zweryfikować. Żadna z nich nie jest domyślnie włączona. Jeśli nikt ich nie ustawił w Twojej domenie, po prostu ich nie ma.

SPF, DKIM i DMARC bez żargonu

Trzy mechanizmy, trzy różne zadania. Działają dopiero razem.

SPF, czyli lista serwerów uprawnionych do wysyłki

SPF to wpis w DNS, w którym deklarujesz, które serwery mogą wysyłać pocztę w imieniu Twojej domeny. Serwer odbiorcy sprawdza, czy wiadomość przyszła z któregoś z nich.

To odpowiednik listy osób upoważnionych do odbioru przesyłek w recepcji. Jeśli ktoś jest na liście, przechodzi. Jeśli nie ma go na liście, coś tu nie gra.

Czego SPF nie robi: nie sprawdza treści wiadomości i nie gwarantuje, że nikt jej po drodze nie zmienił.

DKIM, czyli podpis, którego nie da się podrobić

DKIM dokłada do każdej wychodzącej wiadomości podpis kryptograficzny. Serwer wysyłający podpisuje ją kluczem prywatnym, a klucz publiczny leży w Twoim DNS, żeby każdy odbiorca mógł ten podpis zweryfikować.

To odpowiednik pieczęci lakowej na kopercie. Potwierdza dwie rzeczy naraz: że list wyszedł od Ciebie i że nikt go po drodze nie otworzył ani nie podmienił.

Czego DKIM nie robi: nie mówi odbiorcy, co zrobić z wiadomością, która podpisu nie ma albo ma zły.

DMARC, czyli polityka i raporty

DMARC dokłada dwie rzeczy, których nie ma ani SPF, ani DKIM.

Pierwsza to instrukcja. Mówisz w niej serwerom odbiorców, co mają zrobić z wiadomością, która nie przeszła weryfikacji: przepuścić, wrzucić do spamu albo odrzucić.

Druga to raporty. Serwery pocztowe zaczynają regularnie przysyłać zestawienia tego, kto wysyłał pocztę z Twojej domeny i jak ta poczta wypadła przy weryfikacji. To jedyny moment, w którym widzisz pełen obraz własnej wysyłki, łącznie z systemami, o których dawno zapomniałeś.

Najważniejsze zdanie w tym artykule

Ani SPF, ani DKIM nie patrzą na adres, który widzi odbiorca.

To brzmi jak detal, a jest sednem całej sprawy i powodem, dla którego samo ustawienie SPF i DKIM nie chroni przed podszywaniem.

SPF weryfikuje domenę z koperty SMTP, czyli z adresu zwrotnego, którego odbiorca nigdy nie ogląda. DKIM weryfikuje domenę zapisaną w samym podpisie. Żaden z nich nie porównuje tych wartości z tym, co jest wyświetlone w polu „Od” w Outlooku czy Gmailu.

Oszust może więc wysłać wiadomość z własnej domeny, poprawnie skonfigurowanej, z poprawnym SPF i poprawnym podpisem DKIM, a w polu „Od” wpisać Twój adres. Wszystkie weryfikacje przejdą. Odbiorca zobaczy Twoją firmę.

Dopiero DMARC sprawdza zgodność, po angielsku alignment: czy domena, która przeszła weryfikację, to ta sama domena, którą widzi człowiek. Jeśli nie, uruchamia się Twoja polityka.

Dlatego firma z poprawnym SPF i DKIM, ale bez DMARC, nadal jest podszywalna. I dlatego ogromna część polskich firm ma dwa z trzech elementów i jest przekonana, że temat jest załatwiony.

Dlaczego to przestało być opcjonalne

Przez lata uwierzytelnianie poczty było dobrą praktyką, którą stosowali ci, którym się chciało. To się skończyło i zmienili to nie regulatorzy, tylko sami dostawcy skrzynek.

Google i Yahoo wprowadziły wymagania dla nadawców masowych w lutym 2024 roku. Domena wysyłająca ponad 5 000 wiadomości dziennie musi mieć SPF, DKIM i opublikowaną politykę DMARC na poziomie co najmniej p=none.

Microsoft dołączył 5 maja 2025 roku, z tym samym progiem 5 000 wiadomości dziennie, dla skrzynek konsumenckich: outlook.com, hotmail.com i live.com. Wiadomości niespełniające wymagań nie trafiają do spamu, tylko są odrzucane na poziomie serwera, z komunikatem 550 5.7.515 Access denied.

Próg 5 000 wiadomości dziennie brzmi jak coś, co Twojej firmy nie dotyczy. Dwie uwagi.

Po pierwsze, nigdy nie wiesz, czy próg nie zostanie obniżony, a kierunek jest jednoznaczny i od dwóch lat ten sam. Po drugie i ważniejsze: filtry antyspamowe nie działają na zasadzie „poniżej progu wszystko wolno”. Brak uwierzytelniania to punkt ujemny w ocenie każdej wiadomości, niezależnie od wolumenu. Próg dotyczy twardego odrzucania. Gorsza dostarczalność dotyczy wszystkich.

Uwaga: standard zmienił się w maju 2026

To jest miejsce, w którym większość dostępnych w polskim internecie poradników o DMARC jest już nieaktualna, łącznie z bazami wiedzy dużych hostingów.

W maju 2026 roku IETF opublikowało RFC 9989, wraz z RFC 9990 i RFC 9991. Dokumenty te zastępują obowiązujący od 2015 roku RFC 7489 i przenoszą DMARC ze statusu informacyjnego na ścieżkę standardu (Proposed Standard). W praktyce oznacza to, że DMARC przestał być branżową konwencją, a stał się formalnym standardem internetowym, na który można się powołać w wymaganiach przetargowych i politykach bezpieczeństwa.

Trzy zmiany, które mają znaczenie przy wdrożeniu:

Znikł tag pct. To ten, którym przez lata ustawiało się procent wiadomości objętych polityką, i który do dziś widnieje w niemal każdym polskim poradniku jako pct=100. W nowej specyfikacji go nie ma, podobnie jak tagów rf i ri. Rekord z pct nadal będzie działał u odbiorców korzystających ze starszej implementacji, ale przepisywanie dziś gotowca sprzed trzech lat oznacza wdrażanie nieaktualnej konfiguracji.

Pojawił się tag np. Określa politykę dla nieistniejących subdomen, czyli takich, które nie mają żadnego wpisu w DNS. Wcześniej był to obszar niejednoznaczny i atakujący z niego korzystali, wysyłając wiadomości z subdomen, które formalnie nie istnieją.

Zmienił się sposób ustalania domeny nadrzędnej. Zamiast statycznej listy Public Suffix List odbiorcy korzystają teraz z przechodzenia drzewa DNS w górę. Praktyczny wniosek dla firm z rozbudowaną strukturą subdomen: najbezpieczniej jest opublikować jawny rekord DMARC dla każdej domeny i subdomeny, z której faktycznie wychodzi poczta, zamiast liczyć na dziedziczenie.

Jeśli konfigurowaliście DMARC wcześniej, nie trzeba nic przepisywać na już. Ale jeśli robicie to teraz, warto to zrobić zgodnie z aktualnym standardem, a nie z poradnikiem, który wciąż uczy tagów usuniętych ze specyfikacji.

Sprawdź własną domenę w 15 minut

Nie potrzebujesz do tego administratora ani dostępu do żadnego panelu.

Wejdź na dowolne darmowe narzędzie sprawdzające konfigurację poczty — MXToolbox albo Google Admin Toolbox są w zupełności wystarczające — i wpisz nazwę swojej domeny. Interesują Cię trzy rzeczy: czy jest rekord SPF, czy jest rekord DKIM i czy jest rekord DMARC.

Zobaczysz jeden z czterech wyników.

Brak rekordu DMARC. Domena jest otwarta na podszywanie. Każdy może wysłać wiadomość z Twojego adresu i nikt tego nie zatrzyma ani nie zgłosi.

p=none. Rekord jest, ale nic nie blokuje. To tryb wyłącznie obserwacyjny. Jeśli dodatkowo nie ma w nim adresu raportowego, nie daje absolutnie nic: nie chroni i nie informuje.

p=quarantine. Wiadomości, które nie przejdą weryfikacji, trafiają do spamu odbiorcy. Realna ochrona, choć niepełna.

p=reject. Wiadomości podszywające się pod Twoją domenę są odrzucane i nigdy nie docierają do odbiorcy. To jest cel.

Warto sprawdzić przy okazji, czy rekord SPF nie kończy się na +all. Jeśli tak, oznacza to, że dopuszczasz wysyłkę z dowolnego serwera na świecie, czyli masz rekord, który technicznie istnieje i nie robi nic.

Krok, na którym wywraca się większość wdrożeń

Do tego momentu wszystko wygląda prosto: trzy wpisy w DNS, kwadrans roboty. Problem w tym, że zanim zaostrzysz politykę, musisz wiedzieć, kto w ogóle wysyła pocztę w imieniu Twojej firmy. A to prawie zawsze więcej systemów, niż ktokolwiek pamięta.

Lista do przejścia:

• Microsoft 365 albo Google Workspace, czyli poczta pracowników
• system fakturowy i program księgowy
• CRM, zwłaszcza jeśli wysyła sekwencje handlowe
• platforma mailingowa i newsletter
• sklep internetowy: potwierdzenia zamówień, statusy wysyłki, przypomnienia o koszyku
• formularz kontaktowy i chat na stronie
• system rekrutacyjny i narzędzia kadrowe
• automatyzacje w Make, Zapier czy n8n
• powiadomienia z systemów technicznych: monitoring, helpdesk, backup
• drukarki wielofunkcyjne z funkcją skanowania do maila
• systemy podpisu elektronicznego i obiegu dokumentów
• domeny parkowane, domeny z literówkami i subdomeny

Każda pozycja z tej listy, którą pominiesz, to poczta, która zniknie w momencie przejścia na p=reject. Nie trafi do spamu. Po prostu nie dotrze, a nadawca dowie się o tym najwcześniej wtedy, gdy klient zapyta, dlaczego nie dostał faktury.

Dlatego nie zaczyna się od p=reject. Nigdy.

Wdrożenie w 30 dni, etapami

Kolejność ma znaczenie i każdy etap ma swoje uzasadnienie.

Kluczowy jest etap czwarty. To w nim raporty pokazują rzeczywistość: nadawców, o których nikt nie pamiętał, integracje wdrożone trzy lata temu przez osobę, która już nie pracuje, i wysyłkę z systemów, o których dział IT nie wiedział.

Jest jednak haczyk. Raporty DMARC przychodzą jako spakowane pliki XML, kilka do kilkudziesięciu dziennie, w formacie przeznaczonym dla maszyn. Wygląda to mniej więcej tak jak surowy zrzut bazy danych. Nikt tego nie czyta ręcznie dłużej niż dwa dni.

Dlatego przy wdrożeniu potrzebne jest narzędzie zbierające raporty i pokazujące je w czytelnej formie, albo ktoś, kto robi to po Waszej stronie. Bez tego etap czwarty kończy się tym, że rekord DMARC zostaje na zawsze w trybie p=none, czyli w stanie, w którym nie chroni przed niczym.

Pięć błędów, które wysyłają firmową pocztę do spamu

Kolejność według tego, jak często je spotykamy.

1. Dwa rekordy SPF w jednej domenie. Powstaje przy okazji wdrażania drugiego systemu wysyłkowego, gdy ktoś dodaje nowy wpis zamiast rozszerzyć istniejący. Efekt jest gorszy niż brak SPF w ogóle: zgodnie ze specyfikacją domena z dwoma rekordami SPF nie przechodzi weryfikacji w ogóle. Rekord SPF ma być dokładnie jeden.

2. Przekroczony limit dziesięciu odwołań DNS w SPF. SPF pozwala na maksymalnie dziesięć zapytań DNS przy sprawdzaniu rekordu. Każde include dodane przy podłączaniu kolejnej usługi zbliża Cię do limitu, a niektóre popularne usługi zużywają po kilka. Po przekroczeniu weryfikacja kończy się błędem permerror i cała poczta przestaje przechodzić SPF. Objaw jest typowy: wszystko działało latami, ktoś podłączył jedno nowe narzędzie i nagle połowa poczty ląduje w spamie.

3. Rekord SPF kończący się na +all. Oznacza „każdy serwer na świecie może wysyłać w imieniu tej domeny”. Rekord technicznie poprawny, ochronnie bezwartościowy. Pojawia się zwykle jako obejście problemu z dostarczalnością, który ktoś rozwiązał najszybszą metodą.

4. DMARC bez adresu raportowego. Rekord z samą polityką, bez tagu rua, to polityka bez widoczności. Nie wiesz, kto podszywa się pod Twoją domenę, nie wiesz, które z Twoich systemów nie przechodzą weryfikacji, i nie masz podstaw, żeby bezpiecznie zaostrzyć ustawienia. Wdrażanie DMARC bez raportowania jest mniej więcej tak sensowne jak montaż alarmu bez syreny.

5. Domeny parkowane i subdomeny bez polityki. Firmy kupują domeny z literówkami, warianty .com i .eu, domeny po dawnych markach i domeny pod kampanie. Żadna z nich nie wysyła poczty, więc nikt się nimi nie zajmuje. Dla atakującego to prezent: domena należąca do Was, bez żadnej polityki, idealna do podszywania. Każda domena w Waszym posiadaniu, również ta, z której nic nie wychodzi, powinna mieć rekord DMARC z polityką odrzucania.

Co to daje poza samym bezpieczeństwem

Pytanie o uwierzytelnianie poczty pojawia się dziś w trzech miejscach, w których firmy bywają na nie zupełnie nieprzygotowane.

Ankiety zgodności od dużych kontrahentów. Przy kwalifikacji dostawcy coraz częściej pada pytanie o SPF, DKIM i DMARC, zwykle w formularzu bez pola „nie dotyczy”. Ten sam mechanizm, który znacie z pytań o NIS2 i ustawę o KSC.

Kwestionariusze ubezpieczycieli cyber. Ochrona przed podszywaniem jest jednym ze standardowych punktów oceny ryzyka, a ubezpieczyciel sprawdza stan zabezpieczeń nie tylko przy zawieraniu polisy, ale też przy zgłoszeniu szkody. Pisaliśmy o tym szerzej w tekście o wymaganiach ubezpieczycieli w 2026.

Certyfikacja ISO 27001. Uwierzytelnianie poczty wchodzi w zakres zabezpieczeń komunikacji i jest jednym z prostszych do wykazania punktów. Więcej w artykule o wdrożeniu ISO 27001 w małej firmie.

Do tego dochodzi rzecz, której nie widać w żadnej ankiecie: sam proces inwentaryzacji nadawców jest mini-audytem firmy. Za każdym razem wychodzą z niego integracje, o których nikt nie pamiętał, konta serwisowe po byłych pracownikach i systemy wysyłające pocztę mimo że dawno przestały być używane. To dokładnie ten sam typ porządku, o którym pisaliśmy przy inwentaryzacji zależności i dostawców.

Od czego zacząć

Sprawdzenie własnej domeny zajmuje kwadrans i nie wymaga niczyjej zgody. Zrób to dziś, zanim przeczytasz cokolwiek dalej na ten temat. Wynik powie Ci, czy masz problem, czy nie.

Jeśli okaże się, że rekordu DMARC nie ma albo stoi na p=none bez raportowania, mamy dla Was gotowy proces: audyt konfiguracji domeny, inwentaryzacja wszystkich systemów wysyłających pocztę w imieniu firmy, uporządkowanie SPF i DKIM, wdrożenie DMARC etapami oraz stały monitoring raportów w ramach obsługi. Bez ryzyka, że po drodze zniknie Wam faktura do klienta.

Napisz do nas albo zadzwoń. Sam audyt domeny robimy szybko i na jego podstawie widać od razu, czy jest się czym przejmować.