# DMARC: od p=none do p=reject w 30 dni Kanoniczny adres URL: https://brew.new/pl/blog/dmarc-p-none-to-reject-in-30-days Autor: Thomas Park Opublikowano: 2026-10-04 Zaktualizowano: 2026-10-04 DMARC to rekord TXT pod adresem `_dmarc.`, który mówi serwerom odbiorczym, co zrobić z pocztą z Twoją domeną w nagłówku From, jeśli nie przechodzi ani SPF, ani DKIM zgodnych z tą domeną (tzw. alignment), oraz dokąd wysyłać raporty. `p=none` prosi tylko o raporty, `p=quarantine` prosi serwery odbiorcze, by traktowały taką pocztę jako podejrzaną, a `p=reject`, by ją odrzucały. Gmail, Yahoo i Microsoft akceptują `p=none` od nadawców masowych, więc wiele domen publikuje tę politykę i na tym poprzestaje: raportuje o podszywających się nadawcach, ale ich nie blokuje. Analiza 73,3 mln domen przeprowadzona przez Red Sift, cytowana w [kwietniu 2026 roku](https://redsift.com/blog/email-authentication-bespinlabs-redsift), wykazała, że jakąkolwiek politykę DMARC miało 14,9% z nich, a `p=reject` egzekwowało 2,5%. EasyDMARC, inny dostawca usług DMARC, [podał w 2025 roku](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/), że wśród firm z listy Fortune 500, które mają DMARC, `p=reject` stosowało 62,7%, a wśród firm z listy Inc. 5000 – 15,2%. Oto 30-dniowy plan dojścia do `p=reject`, rekord po rekordzie, dla domeny, z której wysyłają poczta firmowa, jeden lub dwa ESP, helpdesk i narzędzie do fakturowania. Trzydzieści dni wystarczy w przypadku subdomeny wysyłkowej. Domena, której pracownicy używają do codziennej korespondencji, potrzebuje więcej czasu. ## Najważniejsze wnioski - Pierwszego dnia opublikuj `v=DMARC1; p=none; rua=mailto:...`. Bez `rua` serwerom odbiorczym nie wolno wysyłać raportów zbiorczych. - Każdy uprawniony nadawca musi przechodzić SPF lub DKIM zgodne z domeną z nagłówka From. W przypadku większości narzędzi oznacza to podpisywanie DKIM Twoją domeną. - Ogranicz SPF do maksymalnie 10 mechanizmów wymagających zapytań DNS, licząc także zagnieżdżone include, bo inaczej cała Twoja poczta dostanie `permerror`. - Przejdź na `p=quarantine` 15. dnia, a na `p=reject` 22. dnia, za każdym razem po tygodniu czystych raportów. W przypadku domeny, której pracownicy używają do codziennej poczty, RFC 9989 zaleca miesiąc na każdym z dwóch pierwszych etapów. - RFC 9989 (maj 2026) oznacza `pct` jako historyczny. Pomiń stopniowe przechodzenie przez `pct=10` i `pct=50`. - BIMI wymaga `p=quarantine` lub `p=reject` w domenie organizacyjnej, braku `sp=none`, logo w formacie SVG Tiny PS, a w przypadku Gmail także certyfikatu VMC lub CMC. ## Co zmieniło się w DMARC w 2026 roku W maju 2026 roku IETF zastąpiła RFC 7489, dokument informacyjny (Informational) z 2015 roku, specyfikacją DMARCbis: [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), proponowanym standardem (Proposed Standard), który unieważnia też RFC 9091, oraz [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) dotyczącym raportów zbiorczych. Tu ważne są trzy zmiany: - **`pct` ma status historyczny.** Dodatek A.6 stwierdza, że ten tag „zwykle nie był stosowany dokładnie, chyba że podana wartość wynosiła 0 albo 100”. - **`t=y` zastępuje `pct=0`.** Serwery odbiorcze stosują politykę o jeden poziom łagodniejszą niż Twoja, więc `p=reject; t=y` działa jak quarantine. To przełącznik testowy. - **`np` to nowość.** Dotyczy subdomen, które nie istnieją w DNS, a starsze serwery odbiorcze muszą go ignorować. Do ustalania domeny organizacyjnej zamiast listy sufiksów publicznych (Public Suffix List) służy teraz przechodzenie drzewa DNS (DNS tree walk). ## Trzy rekordy, od których zależy DMARC DMARC przechodzi, gdy przechodzi SPF lub DKIM **i** domena, która przeszła weryfikację, jest zgodna z domeną z nagłówka From. Wystarczy jeden zgodny wynik pozytywny. ### SPF i limit 10 zapytań DNS SPF autoryzuje serwery dla domeny z koperty (`MAIL FROM` lub return-path). To jedyna tożsamość, której używa DMARC; HELO się nie liczy. [RFC 7208, sekcja 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) ogranicza liczbę mechanizmów wymagających zapytań DNS do 10: `include`, `a`, `mx`, `ptr`, `exists` i `redirect`, liczonych przez wszystkie zagnieżdżone include. `ip4`, `ip6` i `all` nic nie kosztują. Po przekroczeniu limitu wynik to `permerror`. Ta sama sekcja dopuszcza też najwyżej dwa „puste zapytania” (void lookups), zwykle include dla nazwy hosta, która już nie istnieje. ```dns example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all" ``` To już 4 zapytania, zanim doliczysz to, co zagnieżdża każdy dostawca, więc rozwiąż każdy include przez `dig +short TXT ` aż do końca łańcucha. Żeby zmieścić się w limicie 10, usuń nieużywane narzędzia albo daj każdemu ESP własną subdomenę adresu zwrotnego, np. `bounce.example.com`, z osobnym limitem 10 zapytań. [Przewodnik Microsoftu po konfiguracji SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) zaleca kończenie rekordu na `-all` w domenach, które korzystają też z DKIM i DMARC. Wiele ESP domyślnie używa własnej domeny adresu zwrotnego, która nie jest zgodna z Twoją. Skonfiguruj własny adres zwrotny albo oprzyj się na DKIM. ### DKIM: klucze 2048-bitowe, selektory i rotacja DKIM podpisuje każdą wiadomość domeną `d=` i selektorem `s=`, a serwer odbiorczy pobiera klucz z `._domainkey.`. Narzędzie, które podpisuje wiadomości jako `d=vendor-mail.example`, przechodzi DKIM, ale nie przechodzi DMARC. Według [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) podpisujący muszą używać kluczy RSA o długości co najmniej 1024 bitów i powinni używać kluczy 2048-bitowych. To samo mówią [wytyczne Google dla nadawców](https://support.google.com/mail/answer/81126) w odniesieniu do wysyłki na osobiste konta Gmail. Klucz 2048-bitowy przekracza limit 255 znaków na jeden ciąg w rekordzie TXT, więc wpisuje się go jako kilka ciągów w cudzysłowach w jednym rekordzie. Większość dostawców DNS dzieli go za Ciebie. ```dns s202610._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..." "...remainder-of-the-2048-bit-key...IDAQAB" ) ``` Daj każdemu systemowi wysyłkowemu własny selektor i nigdy nie używaj tej samej nazwy ponownie. Data w nazwie, np. `s202610`, sprawia, że historia pozostaje czytelna. [Zalecenia M3AAWG dotyczące rotacji kluczy](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) mówią, by wymieniać klucze co najmniej co sześć miesięcy: 1. Opublikuj nowy selektor i poczekaj, aż się rozpropaguje. 2. Przełącz podpisywanie na nowy klucz. 3. Zostaw stary klucz publiczny w DNS na 7–30 dni, żeby poczta będąca jeszcze w drodze przeszła weryfikację. 4. Wycofaj stary selektor, ustawiając puste `p=`. Nie usuwaj go. ### Zgodność domen: tryb swobodny czy ścisły RFC 9989 definiuje dwa tryby: | Tryb | Tag | Domena, która przeszła SPF/DKIM | Domena z nagłówka From | Zgodne? | |---|---|---|---|---| | Swobodny (relaxed, domyślny) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Tak, ta sama domena organizacyjna | | Ścisły (strict) | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Nie, nazwy muszą być identyczne | | Dowolny | | `vendor.example.net` | `example.com` | Nie | RFC 9989 zauważa, że „niemal wszyscy właściciele domen uznali swobodną zgodność za wystarczającą”. Nie dodawaj `aspf` ani `adkim`. Ścisła zgodność SPF psuje typowy adres zwrotny w subdomenie. ## Plan na 30 dni ![30-dniowa oś czasu wdrażania DMARC w czterech etapach: dni 1–7 z p=none i raportami rua, dni 8–14 na poprawki u nadawców, 15. dzień z p=quarantine, 22. dzień z p=reject, a od 30. dnia BIMI, z dokładnym rekordem TXT dla każdego etapu.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *Rekord dla każdego etapu. Przechodź dalej dopiero po tygodniu czystych raportów.* | Dni | Polityka | Co robisz | Warunek przejścia dalej | |---|---|---|---| | 1–7 | `p=none` | Publikujesz rekord z `rua`, spisujesz wszystkie źródła | 7 dni raportów od Google, Yahoo i Microsoftu | | 8–14 | `p=none` | Poprawiasz DKIM i SPF, wycofujesz nieużywanych nadawców | Każde uprawnione źródło przechodzi zgodne SPF lub DKIM | | 15–21 | `p=quarantine` | Pilnujesz, czy uprawniona poczta nie trafia do kwarantanny | 7 dni bez niepowodzeń po stronie uprawnionych źródeł | | 22–30 | `p=reject` | Nadal czytasz raporty, dodajesz `np=reject` | Tydzień stabilnej pracy | | 30+ | `p=reject` | Zaczynasz wdrażać BIMI | Wydany certyfikat | Jeśli w drugim tygodniu wyjdzie na jaw źródło, którego nikt nie potrafi naprawić, zostań przy `p=none`. Odrzucanie własnych faktur jest gorsze niż spóźnione egzekwowanie. ### Dni 1–7: opublikuj p=none z raportowaniem ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` Raporty to skompresowane gzipem pliki XML, przychodzące co najmniej raz dziennie od każdego serwera odbiorczego, więc kieruj `rua` do usługi przetwarzającej raporty, a nie do człowieka. Jeśli adres należy do innej domeny organizacyjnej, według RFC 9990 serwery odbiorcze go ignorują, chyba że autoryzuje go rekord `example.com._report._dmarc.`. Usługi przetwarzające raporty publikują ten rekord same, a w przypadku własnych domen musisz go dodać samodzielnie. Opublikuj dokładnie jeden rekord DMARC. Jeśli kreatory konfiguracji zostawią pod `_dmarc.example.com` dwa rekordy `v=DMARC1`, serwery odbiorcze odrzucą oba. Pomiń `ruf`. RFC 9989 zauważa, że serwery odbiorcze dbające o prywatność usuwają z raportów o niepowodzeniach większość danych albo w ogóle ich nie wysyłają, a FAQ w [ogłoszeniu Microsoftu dla nadawców dużych wolumenów](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) informuje, że Microsoft wysyła raporty `rua` i nie planuje wysyłać `ruf`. ### Jak czytać raport zbiorczy RFC 9990 opisuje raporty XML wysyłane „codziennie (lub częściej)”, po jednym dla każdej domeny z polityką. Oto jeden rekord, zaadaptowany z przykładu w tym dokumencie: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` W `policy_evaluated` pola `dkim` i `spf` to wyniki **zgodności**, a `disposition` to działanie, które podjął serwer odbiorczy. `auth_results` zawiera surowe wyniki i ich domeny. Tutaj oba przechodzą dla `vendor.example`, więc oba nie przechodzą testu zgodności: to dostawca, który wysyła jako Ty, ale nie podpisuje wiadomości jako Ty. Włącz u niego własny DKIM albo uwierzytelnianie domeny. ### Dni 1–7: znajdź nieznanych nadawców Pogrupuj wyniki według `source_ip`, `envelope_from` oraz DKIM `domain` i `selector`, posortuj według `count` i przypisz do kategorii: | Wzorzec w raporcie | Prawdopodobna przyczyna | Działanie | |---|---|---| | Zgodny DKIM lub SPF przechodzi | Poprawna konfiguracja | Brak | | DKIM i SPF przechodzą dla domen dostawcy | Narzędzie SaaS używa własnej tożsamości | Włącz własny DKIM | | Zgodny DKIM przechodzi, SPF nie, IP dostawcy poczty lub listy mailingowej | Przekierowanie lub lista mailingowa | Zwykle brak. Zgodny DKIM przetrwa przekierowanie | | Brak DKIM, SPF nie przechodzi, IP nie do przypisania | Podszywanie się | Brak. To właśnie zatrzymuje `p=reject` | Aby ustalić, do kogo należy adres IP, uruchom `dig -x 192.0.2.123 +short` i sprawdź selektor, który często zawiera nazwę dostawcy. Potem zapytaj dział finansów, obsługi klienta i sprzedaży, co jeszcze wysyła pocztę jako firma: fakturowanie, helpdesk, zaproszenia z kalendarza, biurowe skanery. Poczta przekierowana i wiadomości z list mailingowych nie przejdą weryfikacji z przyczyn, których nie naprawisz, a [FAQ Google dla nadawców](https://support.google.com/mail/answer/14229414) nie wymaga dla nich zgodności, więc nie czekaj na nie. ### Dni 8–14: popraw każde uprawnione źródło Zacznij od najwyższego `count` i schodź w dół: 1. **Poczta firmowa** (Google Workspace, Microsoft 365). Włącz DKIM w konsoli administracyjnej, z kluczem 2048-bitowym, jeśli jest dostępny, i sprawdź, czy include dostawcy jest w rekordzie SPF. 2. **ESP i narzędzia marketingowe.** Skonfiguruj uwierzytelnianie domeny, żeby podpisywały wiadomości Twoim `d=`, a jeśli to możliwe, także własny adres zwrotny. 3. **Helpdesk, fakturowanie, CRM.** Tak samo jak w przypadku ESP. Jeśli któreś z tych narzędzi nie potrafi podpisywać Twoją domeną, użyj subdomeny, dla której może podpisywać, albo jego własnej domeny. 4. **Nieużywane narzędzia.** Usuń ich include i selektory. Na koniec ponownie policz zapytania SPF. ### Dzień 15: p=quarantine ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` Kwarantanna zwykle oznacza folder spamu. Wypatruj uprawnionych źródeł z dyspozycją `quarantine`. Na próbę możesz ustawić `p=quarantine; t=y`, co prosi serwery zgodne z RFC 9989 o zastosowanie `none`, choć RFC ma dopiero kilka miesięcy i nie każdy serwer odbiorczy respektuje już `t`. ### Dzień 22: p=reject ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com" ``` Serwery odbiorcze respektujące `p=reject` odrzucają niezgodną pocztę w trakcie sesji SMTP, ale RFC 9989 każe im stosować kwarantannę, gdy polityka jest jedynym dowodem, więc część takich wiadomości trafi do spamu. To samo RFC mówi, że domena z `p=reject` „nie może (MUST NOT) polegać wyłącznie na SPF” i musi podpisywać pocztę DKIM, bo przekierowanie psuje SPF, ale nie DKIM. Najpierw potwierdź zgodny DKIM w każdym źródle. Zachowaj `rua` na stałe. Nowe narzędzie z przyszłego kwartału pojawi się w raportach, zanim zaczną o nim mówić zgłoszenia do działu wsparcia. ### Kiedy wydłużyć plan Sekcja 7.4 RFC 9989 mówi, że domeny, których użytkownicy piszą na listy mailingowe, „nie powinny” (SHOULD NOT) publikować `p=reject`, a te, które to robią, powinny najpierw spędzić „co najmniej miesiąc” na `p=none` i „równie długi okres” na `p=quarantine`. Dotyczy to większości głównych domen firmowych, więc w ich przypadku daj każdemu z dwóch pierwszych etapów miesiąc. Subdomena używana wyłącznie przez Twój ESP nie ma ruchu z list mailingowych i może utrzymać 30-dniowe tempo. ### Polityka dla subdomen: sp= i np= `p` obejmuje domenę i jej subdomeny. `sp` nadpisuje ją dla istniejących subdomen, a `np` dla nieistniejących. Subdomena z własnym rekordem korzysta z niego, a RFC 9989 ignoruje w takim przypadku `sp`. Dedykowana subdomena wysyłkowa, np. `mail.example.com`, używana przez jeden ESP ze zweryfikowanymi SPF i DKIM, może opublikować `p=reject` od pierwszego dnia. `p=none; sp=reject` w domenie głównej chroni subdomeny, dopóki kończysz pracę nad główną domeną, ale blokuje BIMI. Domeny zaparkowane powinny publikować `v=spf1 -all`, zgodnie z przewodnikiem Microsoftu po SPF, oraz `v=DMARC1; p=reject;` pod `_dmarc`. ## Od 30. dnia: BIMI BIMI wyświetla Twoje logo obok uwierzytelnionej poczty w skrzynkach, które je obsługują: | Wymaganie | Szczegóły | Źródło | |---|---|---| | Polityka DMARC | `p=quarantine` lub `p=reject` w domenie organizacyjnej i w domenie z nagłówka From | Szkic BIMI | | Polityka dla subdomen | Jeśli `sp` jest opublikowane, nie może mieć wartości `none` | Szkic BIMI | | Procent | Przy quarantine `pct` nie może być niższe niż 100 | Szkic BIMI | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, element ``, bez skryptów i zewnętrznych odwołań, bez `x=` i `y=` w elemencie głównym | BIMI Group | | Certyfikat | Gmail wymaga VMC (zarejestrowany znak towarowy, znacznik weryfikacji) lub CMC (bez znaku towarowego i bez znacznika) | Google | [Szkic BIMI](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) jest w 14. wersji (maj 2026) i nadal pozostaje dokumentem Internet-Draft napisanym w odniesieniu do RFC 7489, stąd `pct`. Pomiń `pct` i nie ustawiaj `t=y`. Reguła domeny organizacyjnej dotyczy też nadawców z subdomen: gdy `mail.example.com` ma `p=reject`, a `example.com` ma `p=none`, serwery odbiorcze nie mogą wyświetlić logo, więc domena główna też musi przejść cały plan. [Wytyczne BIMI Group dotyczące plików SVG](https://bimigroup.org/creating-bimi-svg-logo-files/) zalecają kwadratowe, wyśrodkowane logo na jednolitym tle, o rozmiarze poniżej 32 KB. Google [dodał obsługę CMC we wrześniu 2024 roku](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). Rekord według [przewodnika wdrożeniowego BIMI Group](https://bimigroup.org/implementation-guide/): ```dns default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem" ``` Rejestracja znaku towarowego trwa miesiącami, więc jeśli planujesz VMC, zacznij już teraz. ## Czego wymagają Gmail, Yahoo i Microsoft Żaden z nich nie wymaga egzekwowania, a jedynie rekordu DMARC i zgodności domen. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Próg | Blisko 5000 wiadomości dziennie do osobistych kont Gmail, liczone dla domeny głównej; po osiągnięciu status jest stały | Nadawcy masowi, bez konkretnej liczby | Ponad 5000 wiadomości dziennie do outlook.com, hotmail.com i live.com, liczone dla domeny From | | SPF i DKIM | Oba | Oba | Oba muszą przechodzić | | DMARC | Rekord wymagany, `p=none` akceptowane | Co najmniej `p=none`, `rua` zdecydowanie zalecane | Co najmniej `p=none` | | Zgodność | SPF lub DKIM | SPF lub DKIM, tryb swobodny wystarczy | SPF lub DKIM | | Skutek niespełnienia | Tymczasowe i trwałe odrzucenia od listopada 2025 roku | Nie podano | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Źródła: [wytyczne Google dla nadawców](https://support.google.com/mail/answer/81126) i [FAQ](https://support.google.com/mail/answer/14229414), [dobre praktyki Yahoo dla nadawców](https://senders.yahooinc.com/best-practices/) oraz [ogłoszenie Microsoftu z kwietnia 2025 roku](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) i [strona pomocy dotycząca błędu 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com). Microsoft zaczął egzekwować wymagania 5 maja 2025 roku, po aktualizacji z 29 kwietnia, która zmieniła działanie z przenoszenia do folderu wiadomości-śmieci na odrzucanie. FAQ Google mówi, że zgodność zarówno SPF, jak i DKIM „w końcu stanie się wymaganiem dla nadawców”, więc w drugim tygodniu zadbaj o zgodność obu. O wypisaniach i wskaźnikach spamu przeczytasz w artykule o tym, [co nadal obowiązuje, gdy Twoje e-maile wysyła agent](/pl/blog/agent-email-deliverability), i w naszym [poradniku o dostarczalności](/pl/blog/email-deliverability). ## DMARC w domenie wysyłkowej Brew [Konfiguracja domeny](https://docs.brew.new/get-started/verify-your-sending-domain) w Brew wymaga: - **DKIM**, czyli rekordu TXT pod selektorem `._domainkey` w Twojej domenie wysyłkowej. Wymagany. - **SPF**, czyli rekordu MX i rekordu TXT dla `send.<your sending domain>`, adresu zwrotnego Brew. Wymagany. - **DMARC**, czyli rekordu TXT pod `_dmarc.<your sending domain>`. Opcjonalny, ale zalecany. - Rekordu **CNAME** do śledzenia kliknięć, tylko jeśli używasz własnej subdomeny śledzącej. Domena może wysyłać, gdy tylko SPF i DKIM zostaną zweryfikowane, a Brew proponuje pasującą wartość DMARC: ```dns ; dedicated sending subdomain, e.g. mail.example.com _dmarc.mail.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com" ; apex domain, or a domain Brew can't prove is dedicated _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` Dedykowana subdomena dostaje `p=reject`, bo nic z niej nie wysyła, zanim SPF i DKIM Brew zostaną zweryfikowane. Domena główna dostaje `p=none`, bo prawdopodobnie wysyłają z niej też Twoje inne narzędzia, więc przeprowadź opisany wyżej plan. Zgodność pozostaje w trybie swobodnym, bo adres zwrotny `send.<domain>` jest zgodny tylko w tym trybie. Brew odczytuje bieżący rekord `_dmarc.<sending domain>` przy dodawaniu domeny, przy weryfikacji i przy każdym ponownym sprawdzeniu. Wynik pokazuje sekcja **Domeny**, a także `get_domain_health` przez MCP i `GET /v1/domains/{domainId}/health`: - **`dmarc_missing`**, czyli ostrzeżenie z dokładnym rekordem do dodania. - **`dmarc_invalid`**, gdy pod tą nazwą są dwa rekordy DMARC albo rekord ma błędną wersję, politykę lub zduplikowane tagi. Wskazuje rekord do usunięcia. - **Zweryfikowano**, gdy zostanie znaleziony dokładnie jeden prawidłowy rekord. Automatyczna konfiguracja DNS zapisuje rekord DMARC tylko wtedy, gdy żaden jeszcze nie istnieje, więc nigdy go nie dubluje. Sprawdzenie odbywa się w domenie wysyłkowej, a nie w domenie nadrzędnej, więc daj każdej subdomenie wysyłkowej własny rekord, także tej dla [poczty transakcyjnej](/pl/blog/transactional-emails), jeśli rozdzielasz te dwa rodzaje wysyłek zgodnie z zaleceniem dokumentacji. Raporty czytasz w usłudze przetwarzającej `rua` i tam decydujesz, kiedy przejść na reject. ## Najczęściej zadawane pytania ### Jak długo zostać przy p=none przed przejściem na quarantine? Dopóki pełny tydzień raportów nie pokaże, że każde uprawnione źródło przechodzi zgodne SPF lub DKIM. W przypadku subdomeny wysyłkowej to zwykle tydzień lub dwa. Dla domeny, której pracownicy używają do codziennej poczty, RFC 9989 zaleca co najmniej miesiąc. Dwa lata na `p=none` bez czytania raportów nic nie dają. ### Czy tag pct w DMARC jest przestarzały? Tak. RFC 9989 oznacza `pct` jako „historyczny” i zastępuje jego jedyne wiarygodne wartości tagiem `t`: `t=y` działa jak `pct=0`, a `t=n` jak `pct=100`. Starsze serwery odbiorcze mogą nadal odczytywać `pct`, ale nigdy nie stosowały wartości pośrednich konsekwentnie, więc zmieniaj politykę pełnymi krokami. ### Czy p=reject zablokuje moją przekierowaną pocztę? Zwykłe przekierowanie najczęściej psuje SPF, ale nie DKIM, więc zgodny DKIM nadal przechodzi. Listy mailingowe, które zmieniają temat lub stopkę, psują DKIM, a niektóre, by to zrekompensować, przepisują nagłówek From. Najlepszą ochroną jest zgodny DKIM we wszystkich źródłach. ### Czy Gmail i Yahoo wymagają p=reject? Nie. Oba wymagają od nadawców masowych opublikowania DMARC i akceptują `p=none`, podobnie jak Microsoft powyżej 5000 wiadomości dziennie do Outlook.com. Egzekwowanie zatrzymuje podszywanie się i jest wymagane przez BIMI, ale żaden z tych trzech dostawców go nie wymaga. ### Czy do BIMI potrzebuję VMC? W przypadku Gmail potrzebujesz VMC, który wymaga zarejestrowanego znaku towarowego i wyświetla znacznik weryfikacji, albo CMC, który wyświetla logo bez znacznika. Według [BIMI Group](https://bimigroup.org/understanding-bimi-certificate-types/) kilku dostawców, w tym Yahoo i Fastmail, wyświetla też logo deklarowane samodzielnie, bez certyfikatu.