DMARC to rekord TXT pod adresem _dmarc.<your domain>, 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, 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, ż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, proponowanym standardem (Proposed Standard), który unieważnia też RFC 9091, oraz RFC 9990 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 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.

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 <name> 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 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 <selector>._domainkey.<d domain>. Narzędzie, które podpisuje wiadomości jako d=vendor-mail.example, przechodzi DKIM, ale nie przechodzi DMARC.

Według RFC 8301 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 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.

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 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:

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

Rekord dla każdego etapu. Przechodź dalej dopiero po tygodniu czystych raportów.

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

_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.<report domain>. 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 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:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

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:

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 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

_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

_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ą:

Szkic BIMI 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 zalecają kwadratowe, wyśrodkowane logo na jednolitym tle, o rozmiarze poniżej 32 KB. Google dodał obsługę CMC we wrześniu 2024 roku. Rekord według przewodnika wdrożeniowego BIMI Group:

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.

Źródła: wytyczne Google dla nadawców i FAQ, dobre praktyki Yahoo dla nadawców oraz ogłoszenie Microsoftu z kwietnia 2025 roku i strona pomocy dotycząca błędu 5.7.515. 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, i w naszym poradniku o dostarczalności.

DMARC w domenie wysyłkowej Brew

Konfiguracja domeny 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:

; 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, 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 kilku dostawców, w tym Yahoo i Fastmail, wyświetla też logo deklarowane samodzielnie, bez certyfikatu.