Strona główna › Poradniki

Konfiguracja SPF, DKIM i DMARC: rekordy, pułapki i weryfikacja

Opublikowano 2026-11-03 ／ Zaktualizowano 2026-11-03 ／ Autor Yuki Nakazawa

Konfiguracja SPF, DKIM i DMARC nie jest już opcjonalna, jeśli wysyłasz e-maile z własnej domeny. Wykonaj ją w tej kolejności: opublikuj jeden rekord SPF, włącz podpisywanie DKIM kluczem 2048-bitowym, a następnie opublikuj rekord DMARC, zaczynając od p=none z włączonym raportowaniem. Przy okazji upewnij się, że adres IP, z którego wysyłana jest Twoja poczta, ma zgodny odwrotny DNS (PTR).

Ten poradnik sprawdzi się niezależnie od tego, czy wysyłasz pocztę z hostingu współdzielonego, własnego VPS, Google Workspace, Microsoft 365 czy usługi wysyłki masowej. Zawiera rekordy, które można dostosować, błędy najczęściej psujące uwierzytelnianie oraz sposób potwierdzenia, że wszystko działa, na podstawie nagłówka prawdziwej wiadomości.

Poniższe informacje zostały sprawdzone w dokumentach RFC oraz na oficjalnych stronach Google, Yahoo i Microsoft według stanu z listopada 2026 r. Wymagania dostawców poczty się zmieniają, dlatego rozstrzygające są ich strony.

Co potwierdza SPF, DKIM i DMARC i w jakiej kolejności je wdrożyć

SPF (Sender Policy Framework) pozwala domenie wskazać w DNS, które serwery mogą wysyłać jej pocztę. Serwer odbiorcy sprawdza nadawcę z koperty (adres SMTP MAIL FROM, który później pojawia się jako Return-Path), pobiera rekord SPF tej domeny i sprawdza, czy łączący się adres IP jest na liście. Sam SPF nie mówi nic o adresie From, który widzi czytelnik.

DKIM (DomainKeys Identified Mail) dodaje do każdej wiadomości podpis kryptograficzny. System nadawczy podpisuje wiadomość kluczem prywatnym, a odbiorcy weryfikują podpis za pomocą klucza publicznego opublikowanego w DNS. Prawidłowy podpis dowodzi, że domena podpisująca (wartość d=) wzięła odpowiedzialność za wiadomość i że podpisane nagłówki oraz treść nie zostały zmienione po drodze.

DMARC (Domain-based Message Authentication, Reporting and Conformance) wiąże oba mechanizmy z widoczną domeną From. Wiadomość przechodzi DMARC tylko wtedy, gdy SPF lub DKIM przechodzi pomyślnie oraz uwierzytelniona domena jest zgodna (aligned) z domeną From. Rekord DMARC informuje też odbiorców, co zrobić z wiadomościami, które nie przeszły weryfikacji (nic, kwarantanna lub odrzucenie), i dokąd wysyłać raporty zbiorcze — dzięki nim znajdziesz źródła wysyłki, o których zapomniałeś.

Kolejność konfiguracji

1. Spisz wszystkie systemy, które wysyłają pocztę w imieniu Twojej domeny: własny serwer, Google Workspace lub Microsoft 365, usługi newsletterowe i transakcyjne, formularze na stronie, narzędzia do fakturowania i obsługi zgłoszeń (help desk).
2. Opublikuj jeden rekord SPF obejmujący je wszystkie.
3. Włącz DKIM w każdym systemie nadawczym i opublikuj jego klucz publiczny.
4. Opublikuj DMARC z p=none i adresem raportowania rua. Google sugeruje, aby po skonfigurowaniu SPF i DKIM odczekać 48 godzin przed dodaniem DMARC.
5. Czytaj raporty, popraw źródła, które nie przechodzą weryfikacji, a następnie przejdź na p=quarantine, a w końcu na p=reject.

Konfiguracja SPF: jeden rekord, dziesięć wyszukiwań

SPF to rekord TXT ustawiany na samej domenie. Oto domena, która wysyła pocztę z własnego serwera przez IPv4 i IPv6, a także korzysta z Google Workspace:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

W większości paneli DNS pole hosta pozostawia się puste (lub wpisuje @), wybiera typ TXT i wkleja wartość zaczynającą się od v=spf1. Typowe elementy:

Pułapki SPF

• Jeden rekord SPF na nazwę. RFC 7208 zabrania wielu rekordów SPF dla tej samej domeny; odbiorcy zwracają permerror i SPF nie przechodzi dla żadnej wiadomości. Dodając usługę, edytuj istniejący rekord i dopisz jej include:, zamiast tworzyć drugi rekord v=spf1.
• Limit 10 wyszukiwań. Mechanizmy include, a, mx, ptr i exists oraz modyfikator redirect wywołują wyszukiwania DNS, a ich łączna liczba w całej ewaluacji, łącznie z wyszukiwaniami w zagnieżdżonych include, nie może przekroczyć 10. Przekroczenie daje permerror. ip4:, ip6: i all nic nie kosztują. RFC 7208 stanowi też, że odbiorcy powinni przerwać po dwóch wyszukiwaniach, które nie zwracają odpowiedzi, dlatego usuń include dla usług, z których już nie korzystasz.
• ~all a -all. -all oznacza, że źródła spoza listy nie są autoryzowane (fail); ~all oznacza, że prawdopodobnie nie są autoryzowane (softfail). Google zaleca ~all dla domen Workspace; Microsoft zaleca -all dla domen Microsoft 365, które używają też DKIM i DMARC. Jeśli nie masz jeszcze pewności, że znasz wszystkich nadawców, zacznij od ~all i pozwól, by egzekwowaniem zajął się DMARC.
• Subdomeny potrzebują własnego rekordu. Rekord SPF w example.com nie obejmuje news.example.com. Umieszczenie usługi wysyłki masowej na osobnej subdomenie daje jej też oddzielną pulę 10 wyszukiwań i oddziela jej reputację od poczty pracowników.
• Błędy składni. Microsoft wymienia typowe: include= zamiast include:, spacja po dwukropku oraz kropka na końcu dołączanej domeny.

Dla domen, które nigdy nie wysyłają poczty, opublikuj v=spf1 -all, aby utrudnić podszywanie się pod nie.

Konfiguracja DKIM: klucze 2048-bitowe i selektory

DKIM składa się z dwóch części: system nadawczy podpisuje wiadomości kluczem prywatnym, a w DNS publikowany jest odpowiadający mu klucz publiczny. W Google Workspace, Microsoft 365, większości paneli hostingowych i większości usług e-mail klucz generuje się w konsoli administracyjnej i kopiuje wyświetloną wartość DNS.

Długość klucza i selektory

Używaj 2048-bitowego klucza RSA. RFC 8301 ustala 1024 bity jako minimum i stanowi, że podpisujący powinni używać co najmniej 2048 bitów; zakazuje też rsa-sha1. Wytyczne Google są zgodne: wybierz 2048 bitów, jeśli Twój dostawca DNS to obsługuje, a 1024 tylko wtedy, gdy nie.

Selektor to etykieta wskazująca, który klucz podpisał wiadomość, dzięki czemu domena może mieć jednocześnie kilka kluczy — po jednym na usługę wysyłkową lub na okres rotacji. Klucz publiczny znajduje się w selector._domainkey.yourdomain. Google Workspace używa domyślnie selektora google. Microsoft 365 używa dwóch rekordów CNAME, selector1._domainkey i selector2._domainkey, wskazujących na klucze hostowane przez Microsoft; dokładne wartości docelowe pobierz z portalu Defender lub za pomocą Get-DkimSigningConfig, ponieważ ich format zależy od dzierżawy (tenanta).

Publikowanie długiego klucza publicznego

2048-bitowy klucz publiczny jest dłuższy niż 255 znaków dozwolonych w pojedynczym ciągu znaków DNS, dlatego w pliku strefy zapisuje się go jako kilka ciągów w cudzysłowach w jednym rekordzie TXT:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Zastąp fragmenty w nawiasach swoim rzeczywistym kluczem. Odbiorcy łączą ciągi bez spacji, więc klucz można podzielić w dowolnym miejscu. Wiele paneli automatycznie dzieli długie wartości: najpierw wklej całą wartość, a dziel ją samodzielnie tylko wtedy, gdy panel jej nie przyjmie. Upewnij się, że przy kopiowaniu nic nie zginęło; puste p= oznacza, że klucz został unieważniony.

Na własnym VPS z Postfiksem lub podobnym MTA parę kluczy może utworzyć milter podpisujący, taki jak OpenDKIM, np. opendkim-genkey -b 2048 -s selector1 -d example.com. Zawartość wygenerowanego pliku z kluczem publicznym opublikuj w sposób pokazany powyżej.

Sprawdź, czy wiadomości są faktycznie podpisywane

Otwórz wysłaną wiadomość i poszukaj nagłówka DKIM-Signature:. Jego znacznik d= powinien zawierać Twoją domenę, a s= opublikowany selektor. Wiele usług e-mail domyślnie podpisuje wiadomości własną domeną; to przechodzi DKIM, ale nie jest zgodne z Twoją domeną From, więc nie pomaga w DMARC. Włącz w usłudze uwierzytelnianie własnej domeny, aby d= wskazywało Twoją domenę.

Konfiguracja DMARC: zacznij od p=none, potem egzekwuj

DMARC to rekord TXT w _dmarc pod Twoją domeną. Zacznij od trybu monitorowania, w którym odbiorcy są proszeni, by nie zmieniali sposobu obsługi Twojej poczty, i poproś o raporty zbiorcze:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Raporty zbiorcze to czytelne maszynowo zestawienia, które adresy IP wysyłały pocztę w imieniu Twojej domeny i czy przeszła ona weryfikację; Google sugeruje osobną skrzynkę lub grupę do ich odbierania. Gdy raporty pokażą, że każde prawidłowe źródło przechodzi weryfikację ze zgodnością domen, zaostrz zasady, edytując ten sam rekord, a nie dodając drugi:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Zgodność domen w prostych słowach

Aby przejść DMARC, co najmniej jeden z mechanizmów SPF lub DKIM musi przejść weryfikację dla domeny zgodnej z domeną From. W trybie łagodnym muszą się zgadzać domeny organizacyjne, więc podpis DKIM z d=example.com jest zgodny z pocztą z alerts@news.example.com. Tryb ścisły wymaga dokładnego dopasowania. Usługi e-mail często używają własnej domeny w Return-Path, więc SPF nie będzie zgodny, nawet jeśli przejdzie weryfikację; zgodny DKIM to praktyczny sposób, aby takie wiadomości przeszły DMARC.

Jeśli chcesz mieć inne zasady dla subdomen, dodaj sp=. Na przykład p=reject; sp=quarantine odrzuca niezweryfikowaną pocztę z domeny głównej, a niezweryfikowane wiadomości z subdomen jedynie poddaje kwarantannie.

Uwaga o zaktualizowanym standardzie

W maju 2026 r. DMARC został ponownie opublikowany jako RFC 9989, który zastępuje RFC 7489. Istniejące rekordy nadal działają i nadal zaczynają się od v=DMARC1. Nowy standard usuwa znacznik pct, który rzadko był stosowany dokładnie poza wartościami 0 i 100, i dodaje znaczniki takie jak t=y (tryb testowy) i np (zasady dla nieistniejących subdomen). Niektóre strony pomocy dostawców nadal pokazują pct, dlatego najmniej niejednoznacznym sposobem wdrażania egzekwowania jest stopniowe przechodzenie przez kolejne wartości p=.

Odwrotny DNS (PTR) dla adresu IP nadawcy

Odwrotny DNS przypisuje adresowi IP nazwę hosta. Google wymaga, aby wszyscy nadawcy wysyłający na prywatne konta Gmail mieli rekord PTR, którego nazwa hosta wskazuje z powrotem na ten sam adres IP nadawcy, a Yahoo wymaga prawidłowego DNS w przód i odwrotnego DNS dla adresów IP nadawców oraz zaleca czytelny, niegeneryczny rekord PTR.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

Rekord PTR nie znajduje się w strefie Twojej domeny. Kontroluje go właściciel adresu IP, więc na VPS ustawia się go w panelu sterowania dostawcy (często pod nazwą reverse DNS lub rDNS), a następnie tworzy odpowiadający mu rekord A (AAAA dla IPv6) we własnym DNS. Jeśli wysyłasz przez IPv6, adres IPv6 wymaga takiej samej konfiguracji. W Google Workspace, Microsoft 365, usługach e-mail i na większości hostingów współdzielonych adresami IP nadawczymi i ich odwrotnym DNS zarządza za Ciebie dostawca.

Jak zweryfikować konfigurację

Odczytaj Authentication-Results

Wyślij wiadomość testową na zewnętrzną skrzynkę i wyświetl pełne nagłówki. W Gmailu otwórz wiadomość i wybierz Pokaż oryginał. Pomoc Google dotycząca DKIM zaznacza, że należy wysłać wiadomość do innego użytkownika, a nie do siebie. Poszukaj nagłówka podobnego do tego:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

Dokładny układ zależy od odbiorcy. Liczy się spf=pass, dkim=pass i dmarc=pass oraz Twoja domena w header.i lub header.d i w header.from. Jeśli SPF przechodzi dla domeny usługi, a DKIM pokazuje inną domenę, DMARC nie przejdzie: najpierw popraw zgodność DKIM.

Odpytaj DNS bezpośrednio

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

W systemie Windows to samo zadanie wykonuje nslookup -type=TXT _dmarc.example.com. Rozpropagowanie zmian w DNS może potrwać; według Google zarówno SPF, jak i DKIM mogą zacząć działać dopiero po 48 godzinach. Bezpłatne narzędzia online również mogą przeanalizować Twoje rekordy i policzyć wyszukiwania SPF.

Jeśli uwierzytelnianie przechodzi pomyślnie, a poczta nadal wraca lub trafia do spamu, sprawdź, czy Twój adres IP nadawczy lub domena nie znajdują się na DNSBL, za pomocą naszego narzędzia do sprawdzania czarnych list, a kolejne kroki opisuje artykuł e-maile niedostarczane z powodu czarnej listy.

Wymagania Gmaila, Yahoo i Outlook.com wobec nadawców

Najwięksi dostawcy poczty egzekwują dziś uwierzytelnianie. Według stanu z listopada 2026 r. ich oficjalne strony podają, co następuje.

• Gmail (obowiązuje od 1 lutego 2024 r.): każdy, kto wysyła na prywatne konta Gmail, potrzebuje SPF lub DKIM, zgodnego DNS w przód i odwrotnego DNS, połączenia TLS oraz wskaźnika spamu poniżej 0,3% w Postmaster Tools. Nadawcy wysyłający ponad 5 000 wiadomości dziennie potrzebują dodatkowo zarówno SPF, jak i DKIM, rekordu DMARC (dopuszczalne jest p=none), domeny From zgodnej z SPF lub DKIM oraz rezygnacji z subskrypcji jednym kliknięciem w przypadku poczty marketingowej. Klucze DKIM muszą mieć co najmniej 1024 bity, przy czym zalecane jest 2048.
• Yahoo (egzekwowanie od lutego 2024 r.): wszyscy nadawcy potrzebują SPF lub DKIM, prawidłowego DNS w przód i odwrotnego DNS oraz wskaźnika spamu poniżej 0,3%. Nadawcy masowi potrzebują zarówno SPF, jak i DKIM, zasady DMARC co najmniej p=none, która przechodzi weryfikację, zgodności domeny From (wystarczy tryb łagodny), działającej rezygnacji jednym kliknięciem oraz prawidłowego DNS w przód i odwrotnego DNS dla adresów IP nadawczych.
• Outlook.com (usługa konsumencka obsługująca outlook.com, hotmail.com i live.com): domeny wysyłające ponad 5 000 e-maili dziennie muszą przechodzić SPF i DKIM oraz publikować DMARC co najmniej p=none, zgodny z SPF lub DKIM. Microsoft zapowiedział, że od 5 maja 2025 r. niezgodne wiadomości będą odrzucane z błędem 550; 5.7.515.

Pełną treść znajdziesz w wytycznych Google dla nadawców e-maili, dobrych praktykach Yahoo dla nadawców oraz ogłoszeniu Microsoft dotyczącym Outlook.com. Nawet jeśli wysyłasz znacznie mniej wiadomości, skonfigurowanie wszystkich trzech mechanizmów już teraz sprawi, że ewentualne obniżenie progu w przyszłości Cię nie zaskoczy. Rozwiązywanie problemów specyficznych dla Gmaila opisuje artykuł Gmail nie dostarcza Twoich e-maili.

Najczęstsze błędy

• Drugi rekord SPF. Dodawanie nowego rekordu v=spf1 dla każdej usługi unieważnia SPF dla całej domeny. Połącz wszystko w jeden rekord.
• Zbyt wiele include. Stare usługi pozostawione w SPF zużywają pulę 10 wyszukiwań. Usuń to, z czego już nie korzystasz, i przenieś pocztę masową na subdomenę.
• Klucz opublikowany, podpisywanie niewłączone. W Google Workspace po udostępnieniu rekordu DNS trzeba jeszcze kliknąć Rozpocznij uwierzytelnianie; inne platformy mają podobny przełącznik.
• Usługa podpisuje własną domeną. SPF i DKIM przechodzą, DMARC nie. Włącz podpisywanie własną domeną.
• Przejście od razu na p=reject. Zapomniany formularz na stronie lub system fakturowania z dnia na dzień przestaje dostarczać pocztę. Zacznij od p=none i czytaj raporty.
• Uszkodzenia przy kopiowaniu. Dodatkowe cudzysłowy w wartości, obcięty klucz lub nazwa hosta, która staje się _dmarc.example.com.example.com, bo panel sam dopisuje domenę. Szybkie sprawdzenie za pomocą dig wychwyci wszystkie te błędy.

Najczęściej zadawane pytania

Wykorzystane strony oficjalne

Fakty podane w tym artykule zostały sprawdzone w momencie publikacji na poniższych stronach oficjalnych. Zasady i działanie usług mogą się zmienić bez uprzedzenia, dlatego przed podjęciem ważnych decyzji warto sprawdzić strony oficjalne.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Powiązane poradniki

Wszystkie poradniki →