Przestań zgadywać w DNS: przyjazny dla dewelopera przewodnik po MX, SPF, DKIM i DMARC

Dlaczego rekordy DNS poczty mają dziś znaczenie

Uwierzytelnianie poczty było kiedyś opcjonalne. W 2026 roku to absolutna podstawa. Gmail i Outlook egzekwują SPF i DKIM dla nadawców masowych, a DMARC szybko staje się obowiązkowy dla każdej domeny wysyłającej pocztę transakcyjną. Jeśli Twoje rekordy DNS są błędne, wiadomości nie docierają — bez zwrotki, bez ostrzeżenia, po prostu cisza.

Problem polega na tym, że te rekordy są dokumentowane jak RFC, a nie jak narzędzia. Większość deweloperów kopiuje przykłady z instrukcji konfiguracji dostawcy poczty i liczy, że wszystko zadziała. Działa to do momentu, gdy trzeba rozwiązać problem, dodać drugą usługę wysyłkową albo wyjaśnić klientowi, dlaczego wiadomości z formularza kontaktowego trafiają do spamu.

Ten przewodnik omawia MX, SPF, DKIM i DMARC w kolejności, w jakiej faktycznie się z nimi spotkasz — z wystarczającą ilością szczegółów, by skonfigurować je poprawnie, i wystarczającym kontekstem, by debugować je, gdy coś się zepsuje.

Rekordy MX: dokąd trafia poczta przychodząca

Rekordy MX mówią internetowi, które serwery pocztowe przyjmują pocztę dla Twojej domeny. Są najprostsze z całej czwórki, ale też najłatwiej je błędnie skonfigurować.

Rekord MX ma dwie części: numer priorytetu i nazwę hosta. Niższe numery priorytetu są próbowane jako pierwsze. Jeśli używasz Google Workspace, Twoje rekordy MX mogą wyglądać tak:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Końcowe kropki mają znaczenie — sygnalizują, że nazwa hosta jest w pełni kwalifikowana. Większość dostawców DNS dodaje je automatycznie, ale nie wszyscy.

Typowe błędy: wskazywanie rekordów MX na rekord A zamiast na nazwę hosta, ustawianie wszystkich priorytetów na ten sam numer (co niweczy sens posiadania zapasowych serwerów) albo zapominanie o usunięciu starych rekordów MX podczas migracji między dostawcami. Nieaktualne rekordy MX nie leżą tam sobie nieszkodliwie — mogą powodować pętle pocztowe albo dzielić dostarczanie między dwie skrzynki.

Jeśli uruchamiasz własny formularz kontaktowy i chcesz ograniczyć spam bez polegania na usługach firm trzecich, zrozumienie, jak formularze stają się wektorami spamu, jest dobrym punktem wyjścia.

SPF: które serwery mogą wysyłać jako Ty

SPF (Sender Policy Framework) to rekord TXT, który wymienia adresy IP i domeny upoważnione do wysyłania poczty w imieniu Twojej domeny. To pierwszy test, który wykonuje większość serwerów pocztowych, gdy otrzymują wiadomość podającą się za wysłaną od Ciebie.

Podstawowy rekord SPF wygląda tak:

v=spf1 include:_spf.google.com ~all

W rozbiciu na części:

• v=spf1 deklaruje wersję SPF
• include:_spf.google.com deleguje do rekordu SPF Google
• ~all to miękka odmowa — odrzucaj pocztę ze źródeł spoza listy, ale nie bądź zbyt rygorystyczny

Możesz też użyć ip4: lub ip6:, aby dodać konkretne adresy do listy dozwolonych, albo a i mx, aby odwołać się do rekordów A i MX swojej domeny. Mechanizm all na końcu kontroluje, co dzieje się z pocztą ze źródeł, których nie wymieniłeś: -all to twarda odmowa (odrzuć), ~all to miękka odmowa (oznacz jako podejrzane), ?all jest neutralne (brak opinii), a +all oznacza pełną dowolność (nie używaj tego).

SPF ma dwie ostre krawędzie. Po pierwsze, psuje się przy przekazywaniu poczty, bo serwer przekazujący nie znajduje się w Twoim rekordzie SPF. Po drugie, rekordy SPF mają limit dziesięciu zapytań DNS. Jeśli dodasz zbyt wiele usług firm trzecich, przekroczysz limit i SPF przestanie działać. Rozwiązaniem jest spłaszczenie rekordu SPF — zastąpienie dyrektyw include: rzeczywistymi zakresami IP — ale wymaga to utrzymania, gdy dostawcy zmieniają swoje adresy IP.

DKIM: kryptograficzny dowód tożsamości nadawcy

DKIM (DomainKeys Identified Mail) dodaje podpis cyfrowy do Twojej poczty wychodzącej. Serwer odbierający sprawdza podpis względem klucza publicznego opublikowanego w Twoim DNS. Jeśli podpis jest prawidłowy, a wiadomość nie została zmodyfikowana, DKIM przechodzi.

W przeciwieństwie do SPF, DKIM przetrwa przekazywanie, ponieważ podpis podróżuje razem z wiadomością. Jest też bardziej elastyczny — możesz mieć wiele kluczy DKIM dla różnych usług wysyłkowych, każdy z własnym selektorem.

Rekord DNS DKIM wygląda tak:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Selektor (default w tym przykładzie) jest dowolny — wybiera go Twój dostawca poczty. Wartość p= to klucz publiczny, zwykle długi ciąg zakodowany w base64. Twój dostawca poczty generuje klucz prywatny i używa go do podpisywania wiadomości wychodzących.

Konfigurację DKIM niemal zawsze obsługuje dostawca poczty. Twoim zadaniem jest skopiować rekord TXT, który Ci poda, i wkleić go do DNS. Trudność polega na tym, że niektórzy dostawcy DNS źle obsługują długie rekordy TXT — albo je obcinają, albo wymagają podzielenia wartości na kilka ciągów w cudzysłowach.

Aby sprawdzić, czy DKIM działa, wyślij testową wiadomość na adres Gmail i sprawdź nagłówki. Poszukaj dkim=pass w nagłówku Authentication-Results.

DMARC: egzekwowanie polityki i raportowanie

DMARC (Domain-based Message Authentication, Reporting and Conformance) łączy SPF i DKIM oraz mówi serwerom odbierającym, co zrobić, gdy uwierzytelnianie się nie powiedzie. Włącza też raportowanie, dzięki czemu możesz zobaczyć, kto wysyła pocztę jako Twoja domena — zarówno legalnie, jak i podszywając się pod nią.

Minimalny rekord DMARC wygląda tak:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none oznacza tylko monitorowanie — nie odrzucaj ani nie kieruj do kwarantanny wiadomości, które nie przeszły testów
• rua=mailto:[email protected] określa, dokąd wysyłać raporty zbiorcze

Gdy masz pewność, że SPF i DKIM działają, możesz zaostrzyć politykę do p=quarantine (wysyłaj nieudane wiadomości do spamu) albo p=reject (odbijaj je od razu). Możesz też ustawić politykę dla subdomen przy użyciu sp= oraz określić procent wiadomości, do których polityka ma być stosowana, za pomocą pct=.

Raporty DMARC to pliki XML wysyłane codziennie przez głównych odbiorców. Są rozwlekłe i trudne do czytania w surowej postaci, ale mówią dokładnie, które wiadomości przeszły lub nie przeszły uwierzytelniania i dlaczego. Jeśli widzisz, że legalna poczta jest odrzucana, raporty pokażą, który test SPF lub DKIM zawodzi.

Jedna pułapka: DMARC wymaga zgodności domen. Dla SPF domena w nagłówku Return-Path musi pasować do domeny w nagłówku From (albo być subdomeną). Dla DKIM domena d= w podpisie DKIM musi pasować do domeny From. Jeśli używasz zewnętrznej usługi wysyłkowej, musi ona obsługiwać niestandardowe ścieżki zwrotne albo podpisywanie DKIM Twoją domeną, a nie swoją.

Jak przeprowadzić audyt obecnej konfiguracji

Większość problemów z DNS jest niewidoczna, dopóki czegoś nie zepsuje. Oto jak sprawdzić rekordy, zanim pojawi się problem:

1. Odpytaj rekordy MX: dig MX example.com powinno zwrócić nazwy hostów serwerów pocztowych i ich priorytety. Sprawdź, czy pasują do dokumentacji Twojego dostawcy poczty.

1. Sprawdź składnię SPF: dig TXT example.com i poszukaj rekordu v=spf1. Przepuść go przez walidator SPF, aby wykryć błędy składni i naruszenia limitu zapytań.

1. Zweryfikuj klucze DKIM: Wyślij testową wiadomość i obejrzyj nagłówek DKIM-Signature. Wyodrębnij selektor i domenę, a następnie odpytaj dig TXT selector._domainkey.example.com, aby potwierdzić, że klucz publiczny istnieje.

1. Zweryfikuj politykę DMARC: dig TXT _dmarc.example.com powinno zwrócić Twój rekord DMARC. Upewnij się, że rua= wskazuje adres, który faktycznie monitorujesz.

1. Przetestuj od końca do końca: Użyj usługi takiej jak mail-tester.com albo wyślij wiadomość na adres Gmail i sprawdź pełne nagłówki. Poszukaj spf=pass, dkim=pass i dmarc=pass w nagłówku Authentication-Results.

Jeśli debugujesz, dlaczego wiadomości nie docierają, nagłówki są Twoim najlepszym narzędziem. Większość klientów pocztowych pozwala wyświetlić surowe nagłówki — w Gmail otwórz wiadomość, kliknij trzy kropki i wybierz „Pokaż oryginał”. Nagłówek Authentication-Results powie dokładnie, który test zawiódł i dlaczego.

Kiedy używać polityk subdomen

Jeśli wysyłasz pocztę z wielu subdomen — na przykład newsletter.example.com do marketingu i app.example.com do poczty transakcyjnej — możesz ustawić osobne polityki DMARC dla każdej subdomeny. Pozwala to egzekwować rygorystyczne polityki na subdomenach, które kontrolujesz, przy zachowaniu luźniejszej polityki na domenie głównej.

Ceną jest złożoność. Każda subdomena potrzebuje własnych rekordów SPF, DKIM i DMARC, a Ty musisz śledzić, które usługi wysyłkowe są upoważnione dla których subdomen. Dla większości małych zespołów jedna dobrze skonfigurowana domena jest prostsza i równie bezpieczna.

Co zrobić, gdy uwierzytelnianie się psuje

Najczęstszy scenariusz awarii to dodanie nowej usługi wysyłkowej bez aktualizacji DNS. Jeśli zaczynasz używać nowego dostawcy poczty transakcyjnej, musisz dodać jego include SPF lub zakres IP, skonfigurować podpisywanie DKIM Twoją domeną i zweryfikować zgodność DMARC.

Drugi najczęstszy problem to przekazywanie. Jeśli użytkownicy przekazują Twoją pocztę na inny adres, SPF zawiedzie, bo serwer przekazujący nie znajduje się w Twoim rekordzie SPF. DKIM zwykle przetrwa przekazywanie, więc dopóki DKIM przechodzi, a Twoja polityka DMARC dopuszcza częściową zgodność, wiadomość powinna nadal zostać dostarczona. Jeśli widzisz, że przekazywana poczta jest odrzucana, sprawdź politykę DMARC — p=reject przy rygorystycznej zgodności zepsuje przekazywanie.

Trzeci problem to propagacja DNS. Zmiany w rekordach DNS mogą propagować się godzinami, a różne serwery pocztowe cache'ują rekordy przez różny czas. Jeśli właśnie zaktualizowałeś rekord i coś nie działa, odczekaj kilka godzin i przetestuj ponownie. Propagację możesz sprawdzić narzędziem takim jak whatsmydns.net.

Najważniejsze wnioski

• Rekordy MX kierują pocztę przychodzącą; SPF, DKIM i DMARC uwierzytelniają pocztę wychodzącą. Rozwiązują różne problemy i potrzebujesz wszystkich czterech.
• SPF psuje się przy przekazywaniu i ma limit dziesięciu zapytań. DKIM przetrwa przekazywanie, ale wymaga konfiguracji per usługa. DMARC łączy je w całość i włącza raportowanie.
• Zacznij od p=none w DMARC, monitoruj raporty przez kilka tygodni, a potem zaostrz do p=quarantine albo p=reject, gdy masz pewność, że legalna poczta przechodzi.
• Błędy DNS są ciche. Testuj konfigurację prawdziwą pocztą i sprawdzaj nagłówki, aby potwierdzić, że SPF, DKIM i DMARC przechodzą.
• Jeśli uwierzytelnianie psuje się po dodaniu nowej usługi wysyłkowej, sprawdź include w SPF, selektory DKIM i zgodność DMARC. Nagłówki powiedzą Ci, który test zawiódł.

FAQ

Q: Czy mogę mieć wiele rekordów SPF?

A: Nie. Wiele rekordów SPF spowoduje, że wszystkie zostaną zignorowane. Jeśli musisz upoważnić wiele usług, użyj dyrektyw include: w jednym rekordzie SPF albo wypisz zakresy IP bezpośrednio. Pilnuj limitu dziesięciu zapytań.

Q: Czy potrzebuję DMARC, jeśli wysyłam tylko kilka wiadomości dziennie?

A: Tak. W DMARC nie chodzi o wolumen — chodzi o udowodnienie, że jesteś tym, za kogo się podajesz. Nawet małe domeny korzystają na DMARC, bo zapobiega podszywaniu się i daje wgląd w problemy z dostarczaniem. Zacznij od p=none i adresu do raportów.

Q: Co się stanie, jeśli DKIM i SPF zawiodą, ale wiadomość wygląda na legalną?

A: To zależy od Twojej polityki DMARC. Jeśli p=none, poczta zostanie dostarczona z ostrzeżeniem. Jeśli p=quarantine, trafi do spamu. Jeśli p=reject, zostanie odbita. Dlatego przed egzekwowaniem rygorystycznej polityki warto monitorować raporty DMARC — możesz mieć legalnych nadawców, o których nie wiedziałeś.

Q: Czy mogę używać tego samego klucza DKIM dla wielu domen?

A: Technicznie tak, ale nie rób tego. Każda domena powinna mieć własną parę kluczy DKIM. Współdzielenie kluczy utrudnia rotację i zwiększa zasięg szkód, jeśli klucz prywatny zostanie ujawniony.

Q: Jak często rotować klucze DKIM?

A: Nie ma uniwersalnej reguły, ale raz w roku to rozsądna częstotliwość dla większości domen. Jeśli podejrzewasz, że klucz został ujawniony, obróć go natychmiast. Upewnij się, że opublikujesz nowy klucz publiczny w DNS, zanim zaczniesz podpisywać nowym kluczem prywatnym, i pozostaw stary klucz w DNS przez kilka dni po rotacji, aby obsłużyć opóźnioną pocztę.

<!-- tool-cta:start -->

💡 Wypróbuj to: Sprawdź opublikowaną politykę dowolnej domeny za pomocą DMARC Lookup, aby zobaczyć, jak rekordy MX, SPF i DMARC współdziałają w praktyce.

<!-- tool-cta:end -->

Źródła

• RFC 7208: Sender Policy Framework (SPF) — Specyfikacja SPF, w tym reguły składni i limit dziesięciu zapytań.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Specyfikacja DKIM, obejmująca generowanie i weryfikację podpisów.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Specyfikacja DMARC, w tym składnia polityk i format raportowania zbiorczego.
• Google Workspace: Prevent spoofing and spam — Praktyczne wskazówki dotyczące konfiguracji SPF, DKIM i DMARC dla domen Google Workspace.