Sprawdzanie DMARC

Sprawdź rekord DMARC dowolnej domeny tak, jak czyta go odbierający serwer poczty: gdzie znajduje się polityka, co dzieje się z pocztą, która nie przechodzi, czy raporty do kogoś docierają i czego potrzebują SPF i DKIM, zanim zaczniesz egzekwować politykę.

Aktualizacja: 25 października 2026

Źródła: rekordy TXT _dmarc domeny i jej domen nadrzędnych, przez Google Public DNS (z Cloudflare 1.1.1.1 w tle) · przejście po drzewie z RFC 9989 · autoryzacja raportów według RFC 9990 · SPF i DKIM z naszych własnych narzędzi · nic o tobie nie jest zapisywane

Jak sprawdzić rekord DMARC?

Wpisz domenę powyżej: narzędzie pyta DNS o rekord TXT w _dmarc. plus domena, a gdy go nie ma, idzie w górę do domeny organizacyjnej (RFC 9989 §4.10) i pokazuje, co odbierający serwer robi z pocztą, która nie przechodzi.

Ręcznie zapytaj o tę samą nazwę: dig +short TXT _dmarc.paypal.com albo nslookup -type=TXT _dmarc.paypal.com w Windows. Jedna odpowiedź zaczynająca się od v=DMARC1 to rekord; dwie odpowiedzi oznaczają, że odbiorcy nie używają żadnej z nich (RFC 9989 §4.10).

dig na tym kończy. Nie idzie w górę od subdomeny, nie sprawdza, czy adresy raportów przyjmują raporty, i nie mówi, którego RFC trzyma się odbiorca. To właśnie dodaje to narzędzie.

% dig +short TXT _dmarc.example.com

Każda odpowiedź pod tą nazwą. Ta zaczynająca się od v=DMARC1 to rekord.

Co pokazuje dig, a czego nie

terminal

$ dig +short TXT _dmarc.paypal.com 1

"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"

$ dig TXT _dmarc.mail.google.com | grep status 4

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

1Nazwa to _dmarc. plus domenaNie sama domena: TXT w paypal.com to miejsce na SPF.
2Jeden rekord, v=DMARC1 na początkuDwa rekordy pod jedną nazwą: odbiorcy odrzucają oba (RFC 9989 §4.10).
3Tagi, rozdzielone ;p to polityka; rua i ruf mówią, dokąd trafiają raporty.
4Nic tu nie ma? Idź wyżej_dmarc.mail.google.com to NXDOMAIN: obowiązuje rekord google.com.

Rekord paypal.com tak, jak zwrócił go Google Public DNS dnia 24 października 2026; mail.google.com nie ma własnego.

Jak czytać wynik: widok odbiorcy

Najpierw odpowiedź, jednym zdaniem. Pod nią dowody: rekord tak, jak czytają go odbiorcy, każdy tag podświetlony nad dokładnymi znakami, a na granacie droga, którą odbierający serwer przechodzi dla tej domeny, kończąca się tym, co robi z pocztą, która nie przechodzi.

Bez punktacji: polityka na none to etap, nie porażka, a drabina pod drogą mówi, czego wymaga następny krok.

Sprawdzanie DMARC dla paypal.com: odrzuca pocztę, która nie przechodzi, z widokiem odbiorcy i drabiną egzekwowania polityki — Sprawdzenie DMARC dla paypal.com: werdykt, rekord podzielony na tagi, widok odbiorcy z każdym zapytaniem DNS i tym, co dzieje się z pocztą, która nie przechodzi, oraz drabina egzekwowania. Wybierz numer, żeby zobaczyć, co pokazuje każda część.

DMARC: co to jest i do czego służy?

DMARC mówi odbierającym serwerom poczty, co zrobić z wiadomościami, które używają twojej domeny w wierszu From:, ale nie potrafią udowodnić, że pochodzą od ciebie, i dokąd wysyłać raporty o nich (RFC 9989 §4.7).

Dowodem jest SPF lub DKIM, zgodny (aligned) z domeną z From:: SPF przechodzący dla domeny zwrotnej z tej samej organizacji albo podpis DKIM z d= twojej domeny. Wystarczy jedno zgodne zaliczenie (RFC 9989 §5.3.5); cała reszta nie przechodzi DMARC, a o dalszym losie decyduje polityka z rekordu: dostarczyć, folder spamu albo odrzucić.

Raporty to druga połowa. Odbiorcy honorujący rua wysyłają dzienne podsumowanie każdego serwera, który wysyłał jako twoja domena, i tak znajdujesz prawowitych nadawców, o których zapomniano, zanim zaczniesz egzekwować politykę.

Dwie wiadomości, jeden wiersz From:

From: billing@example.comp=reject · rua=mailto:dmarc@example.com

Twoja faktura, wysłana przez usługę pocztyprzez usługę z własnym DKIM, więc podpisuje d=example.com

SPFpass · bounces.esp.example (niezgodny)
DKIMpass · d=example.com (zgodny)
DMARCpass: wystarczy jeden zgodny wynik

Dostarczono

Sfałszowana faktura z 203.0.113.9serwer, którego example.com nigdy nie autoryzowała

SPFfail · 203.0.113.9 nie ma na liście
DKIMnone · brak podpisu
DMARCfail → p=reject

Odrzucono

550 5.7.1 Email rejected per DMARC policy for example.com

Jutrzejszy raport zbiorczy dla dmarc@example.com: 1 wiadomość z 203.0.113.9, SPF fail, DKIM none, disposition reject.

Zaliczenie nie obiecuje dostarczenia (filtry odbiorcy nadal decydują), a niepowodzenie przy p=reject to prośba, nie rozkaz (RFC 9989 §5.4, §7.4). Adresy z RFC 5737; tekst odpowiedzi to przykład z samego RFC 9989.

Tagi rekordu DMARC: objaśnienie

Rekord DMARC to lista par tag=wartość w rekordzie TXT w _dmarc. plus domena: najpierw v=DMARC1, potem tagi polityki, zgodności i raportów w dowolnej kolejności (RFC 9989 §4.7).

RFC 9989 (maj 2026) zastąpiło RFC 7489. Dodało np, psd i t, a usunęło pct, rf i ri: obecni odbiorcy je ignorują, a odbiorcy wciąż na RFC 7489 je czytają, więc rekord z pct=25 znaczy dla różnych odbiorców co innego.

Tagi, których nie opublikujesz, przyjmują wartości domyślne, a narzędzie pokazuje je też: brak sp oznacza, że subdomeny dostają p.

Każdy tag według tego, co robi

v=DMARC1; p=reject; sp=quarantine; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1

WersjaPolitykaTest i sufiksZgodnośćRaportyUsunięty

Tag	Co ustawia	Domyślnie	Status	Spotykany w
v	WersjaDMARC1	wymagana, pierwsza	RFC 9989	192
p	Polityka dla domenynone · quarantine · reject	none, jeśli brak, a rua jest poprawny	RFC 9989	192
sp	Polityka dla istniejących subdomennone · quarantine · reject	p	RFC 9989	39
np	Polityka dla nazw, które nie istniejąnone · quarantine · reject	sp, potem p	nowy w RFC 9989	2
t	Tryb testowy: o stopień poniżej politykiy · n	n	nowy w RFC 9989	0
psd	Sufiks publiczny (y) lub domena organizacyjna (n)y · n · u	u	nowy w RFC 9989	1
adkim	Zgodność DKIMr · s	r	RFC 9989	20
aspf	Zgodność SPFr · s	r	RFC 9989	24
rua	Dokąd trafiają raporty zbiorczemailto:…	brak raportów	RFC 9989	186
ruf	Dokąd trafiają raporty o niepowodzeniachmailto:…	brak raportów	RFC 9989	120
fo	Kiedy wysyłać raporty o niepowodzeniach0 · 1 · d · s	0	RFC 9989	96
pct	Część poczty, która nie przechodzi, do której stosuje się politykę0–100	–	usunięty	70
rf	Format raportu o niepowodzeniachafrf	–	usunięty	9
ri	Interwał raportów, sekundy86400	–	usunięty	14

Spotykany w: ile z 192 rekordów DMARC opublikowanych przez 196 znanych domen zawiera dany tag (odczytane 24 października 2026; 69 z 70 tagów pct mówi pct=100). Wartości domyślne i status z RFC 9989 §4.7 i Dodatku C.

Polityka DMARC: p=none, quarantine czy reject

p=none prosi odbiorców, by dostarczali pocztę, która nie przechodzi, jak zwykle i tylko o niej raportowali; quarantine prosi, by traktowali ją jako podejrzaną, zwykle kierując do spamu; reject prosi, by odrzucali ją w trakcie rozmowy SMTP.

None to etap, nie porażka: RFC 9989 §7.4 sugeruje co najmniej miesiąc na nim z płynącymi raportami i drugie tyle na quarantine, zanim przejdziesz na reject. Domeny, z których ludzie piszą na listy mailingowe, powinny zatrzymać się na quarantine.

Więksi dostawcy skrzynek też to dzielą: gmail.com i outlook.com publikują p=none dla samej domeny i sp=quarantine dla subdomen, a google.com, yahoo.com i microsoft.com publikują reject.

Gdzie ląduje sfałszowana wiadomość

Dostarczonop=none

apache.orggmail.comsamsung.com

23 z 192

Folder spamup=quarantine

github.comapple.comamazon.com

30 z 192

Odrzuconop=reject

google.compaypal.commicrosoft.com

139 z 192

W końcu decydują odbiorcy: mogą dostarczyć pocztę, która nie przechodzi przy p=reject, i nie wolno im odrzucać wyłącznie na podstawie polityki (RFC 9989 §5.4, §7.4). Badanie jednego z dostawców pokazuje, jak daleko w tyle jest reszta sieci: wśród 1,8 miliona największych domen na początku 2026 roku EasyDMARC naliczyło 29,2% przy p=none i 22,9% przy quarantine lub reject.

Czy DMARC jest naprawdę potrzebny?

Tak, jeśli wysyłasz masowo do Gmaila, Yahoo lub Outlook.com: wszystkie trzy wymagają rekordu DMARC, a p=none wystarcza, by spełnić tę regułę. Egzekwowanie (quarantine lub reject) powstrzymuje innych przed wysyłaniem jako twoja domena, a logo BIMI go wymaga.

Gmail wymaga go od nadawców wysyłających ponad 5000 wiadomości dziennie na konta Gmail (wymóg od: 1 lutego 2024); Yahoo wymaga go, nie podając wolumenu (wymóg od: luty 2024); Outlook.com wymaga go powyżej 5000 dziennie (wymóg od: 5 maja 2025). Bez rekordu Gmail odpowiada 4.7.31 (a 4.7.32, gdy From: nie jest zgodny), a Outlook.com odrzuca z 550 5.7.515.

Dla domeny, która nic nie wysyła, DMARC to najtańsza ochrona, jaka istnieje: p=reject, null MX i v=spf1 -all, tak jak publikuje example.com (M3AAWG).

Czego każdy dostawca skrzynek oczekuje od nadawców masowych

Gmail1 lut 20245000+ dziennie na konta Gmail4.7.31 · 4.7.32

Yahoolut 2024brak opublikowanego proguDMARC musi przejść

Outlook.com5 maj 20255000+ dziennie550 5.7.515

Dostarczonop=nonespełnia regułę wszystkich trzech dostawców

Folder spamuquarantinezatrzymuje większość podszywania się · możliwe logo BIMI

Odrzuconorejectzatrzymuje podszywanie się przy drzwiach · BIMI

✓Wymagane: rekord, p=none lub ostrzejszyiOchrona: quarantine lub reject

Ze stron dla nadawców każdego dostawcy, odczytane 24 października 2026. Odsetek spamu poniżej 0,3% i wypisanie jednym kliknięciem to też reguły, ale DNS ich nie pokaże; widok Wymagania w narzędziu mówi, które części potrafi udowodnić.

Jak naprawić błędy DMARC: przekazywanie, listy mailingowe, domena dostawcy

Znajdź źródło, które nie przechodzi, w raportach zbiorczych i napraw je u nadawcy: podpisz je DKIM dla własnej domeny albo przenieś je na domenę zwrotną w twojej organizacji. Trzy przyczyny wyjaśniają większość niepowodzeń.

Przekazywanie zachowuje podpis DKIM, ale psuje SPF, więc zaliczenie niesie DKIM. Listy mailingowe, które edytują wiadomość, psują oba. A usługa poczty, która podpisuje własną domeną, zalicza DKIM dla siebie, nie dla ciebie: włącz jej własny DKIM (zwykle CNAME w rodzaju s1._domainkey) i własną ścieżkę zwrotną.

Trzy niepowodzenia, co pokazuje raport i jak to naprawić

Przekazywanie

SPF192.0.2.80 nie ma w SPF domeny example.com
DKIMpodpis nienaruszony

Raport pokazujespf=fail dkim=pass → pass

Podpisuj wszystko DKIM; DKIM przetrwa przekazywanie. ARC (RFC 8617) pomaga przekazującym poręczyć za wiadomość.

Lista mailingowa

SPFwysyła serwer listy
DKIMtreść zmieniona: skrót nie pasuje

Raport pokazujespf=fail dkim=fail → fail

Listy, które przepisują From:, to naprawiają; domeny, z których ludzie piszą na listy, zostają na quarantine (RFC 9989 §7.4).

Domena dostawcy

SPFpass dla bounces.esp.example: niezgodny
DKIMpass dla esp.example: niezgodny

Raport pokazujedkim=pass(esp.example) → fail

Włącz własny DKIM dostawcy: s1 i s2 domeny paypal.com to CNAME do SendGrid, który podpisuje jako paypal.com.

Adresy z RFC 5737; esp.example to symbol zastępczy. CNAME SendGrid to prawdziwe selektory domeny paypal.com (24 października 2026).

DMARC dla subdomen: sp i np

Subdomena bez własnego rekordu dostaje politykę swojej domeny organizacyjnej: sp dla subdomen, które istnieją, np dla nazw, które nie istnieją, każde z powrotem do p (RFC 9989 §4.7).

Subdomena, która publikuje własny rekord, używa go dla siebie. Ale rekord między nazwą a jej domeną organizacyjną nigdy nie jest używany dla tej nazwy: pokazuje to drzewo berkeley.edu, gdzie sp=none z eecs.berkeley.edu nie sięga do www.eecs.berkeley.edu (RFC 9989 §4.10.1).

np to tania wygrana: nazwy, które nie istnieją, nie wysyłają prawdziwej poczty, więc np=reject blokuje fałszerstwa z nich nawet wtedy, gdy p jest jeszcze na none. Odbiorcy z RFC 7489 nie znają np i używają sp.

Drzewo berkeley.edu tak, jak czyta je odbiorca

berkeley.edup=reject; np=reject; psd=n; rua=…własny rekord · psd=n: domena organizacyjnaOdrzucono

www.berkeley.edubrak rekorduistnieje → sp, brak → pOdrzucono

eecs.berkeley.edup=reject; sp=none; rua=…własny rekord → pOdrzucono

www.eecs.berkeley.edubrak rekorduprzejście: rekord eecs.berkeley.edu jest pomijany (to nie domena organizacyjna) → p z berkeley.eduOdrzucono

nosuch-x7.berkeley.eduNXDOMAINnie istnieje → npOdrzucono

sp=none z eecs.berkeley.edu nigdy nie jest stosowane: rekord między nazwą a jej domeną organizacyjną nie jest dla niej używany (RFC 9989 §4.10.1). Narzędzie oznacza go jako rekord, który nie jest używany.

Odczytane 24 października 2026 przez Google Public DNS. nosuch-x7.berkeley.edu to wymyślona nazwa; jej NXDOMAIN jest prawdziwy.

Jak czytać raporty DMARC (rua)

Raport zbiorczy to dzienny plik XML od każdego odbiorcy, który wymienia każdy serwer wysyłający pocztę jako twoja domena, ile wiadomości i czy SPF, DKIM i DMARC przeszły (RFC 9990).

Czytaj według źródła: twoje własne serwery i usługi powinny pokazywać zgodne zaliczenie; znana usługa, która nie przechodzi, potrzebuje własnego DKIM; nieznany adres, który nie przechodzi przy p=reject, to podszywanie się, zatrzymane. Serwis raportów (dmarcian, Valimail, EasyDMARC, Postmark i inne) zamienia tysiące plików w taką listę.

Raporty na adres w innej domenie docierają tylko wtedy, gdy ta domena się zgodzi: publikuje yourdomain._report._dmarc.its-host z v=DMARC1 (RFC 9990 §4). Narzędzie pyta za ciebie i podaje dokładny rekord, gdy go brakuje.

Jeden raport, czytany wiersz po wierszu

<org_name>google.com</org_name>1

<date_range>23 paź, 00:00 UTC – 24 paź, 00:00 UTC</date_range>

<policy_published>example.com · p=reject</policy_published>2

<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3

<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4

1Kto zgłaszaJeden plik od odbiorcy dziennie (RFC 9990: co najmniej co 24 godziny).
2Polityka, którą znalazłCo przeczytał w _dmarc.example.com.
3Przekazana poczta uratowana przez DKIMSPF nie przeszedł u przekazującego; zgodny podpis przeszedł DMARC.
4Podszywanie się, zatrzymaneNieznany serwer, nic zgodnego, odrzucone.

paypal.comrua=mailto:d@rua.agari.comrua.agari.compaypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ autoryzowany: raporty płyną

Serwisy raportów rozpoznawane przez narzędziedmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 więcej

XML jest skrócony i zmyślony (adresy dokumentacyjne, RFC 5737); rekord autoryzacji to prawdziwy rekord paypal.com, odczytany 24 października 2026.

Sprawdzanie DMARC: najczęstsze pytania

DMARC: co to jest?

DMARC to rekord DNS, który mówi odbierającym serwerom poczty, co zrobić z wiadomościami używającymi twojej domeny w wierszu From:, ale niezgodnymi pod względem SPF i DKIM: dostarczyć, odesłać do kwarantanny albo odrzucić. Wskazuje też, dokąd odbiorcy wysyłają raporty o takiej poczcie. Publikuje się go jako rekord TXT w _dmarc plus twoja domena; definiuje go RFC 9989, które w maju 2026 zastąpiło RFC 7489.

Co pokazuje narzędzie do sprawdzania rekordu DMARC?

Czyta rekord TXT w _dmarc plus domena, a gdy go nie ma, rekord domen nadrzędnych, tak jak robi to odbiorca. To narzędzie pokazuje rekord tag po tagu z wartościami domyślnymi, politykę dla domeny, jej subdomen i nazw, które nie istnieją, czy adresy raportów przyjmują raporty oraz rekord SPF i klucze DKIM domeny, bez oceny punktowej.

Jak wykonać test DMARC?

Sprawdź domenę powyżej, żeby zobaczyć opublikowaną politykę: to test DMARC, na który odpowie DNS. Żeby sprawdzić, czy prawdziwa wiadomość przechodzi, wyślij ją na skrzynkę, którą kontrolujesz, i przeczytaj nagłówek Authentication-Results albo wklej nagłówki do Analizy Nagłówków E-mail. Walidator DMARC sprawdza składnię rekordu; tylko wiadomość pokaże, czy SPF lub DKIM były zgodne.

Od jakiej polityki DMARC zacząć?

Zacznij od p=none i adresu rua, żeby odbiorcy wysyłali ci dzienne raporty bez zmiany dostarczania. Napraw każdego prawowitego nadawcę, który nie przechodzi, zwykle włączając jego własny DKIM, a potem przejdź na quarantine i wreszcie reject. RFC 9989 sugeruje co najmniej miesiąc na p=none i drugie tyle na quarantine. Domena, która nie wysyła poczty, może od razu przejść na p=reject.

Czy p=none chroni moją domenę?

Nie. p=none prosi odbiorców, by traktowali pocztę, która nie przechodzi, jak zwykle, więc sfałszowaną wiadomość oceniają tylko ich własne filtry antyspamowe. Daje za to raporty i spełnia regułę Gmaila, Yahoo i Outlook.com dla nadawców masowych. Traktuj go jako etap monitoringu: ochrona zaczyna się od quarantine, a reject zatrzymuje sfałszowaną pocztę, zanim do kogokolwiek dotrze.

Co oznacza t=y w rekordzie DMARC?

t=y to tryb testowy z RFC 9989: odbiorcy stosują o stopień łagodniejszą politykę niż opublikowana, więc p=reject działa jak quarantine, a p=quarantine jak none. Nie ma wpływu na p=none i nie zmienia raportów. Odbiorcy wciąż na RFC 7489 nie znają tego tagu i stosują politykę tak, jak jest zapisana. Usuń t=y, gdy raporty pokażą, że wszyscy prawowici nadawcy są zgodni.

Czy tag pct jest jeszcze używany?

RFC 9989 usunęło pct razem z rf i ri, bo wartości inne niż 0 i 100 były stosowane niespójnie. Obecni odbiorcy go ignorują i stosują politykę do całej poczty, która nie przechodzi. Odbiorcy wciąż na RFC 7489 próbkują: pct=25 przy quarantine wysyła do spamu jedną czwartą takiej poczty, a resztę dostarcza. pct=100 jest nieszkodliwy; w fazie testów użyj t=y.

Dlaczego mój adres rua jest „bez autoryzacji”?

Gdy raporty trafiają do skrzynki w innej domenie organizacyjnej, ta domena musi się zgodzić, publikując rekord TXT o nazwie yourdomain._report._dmarc.its-host z wartością v=DMARC1 (RFC 9990 §4). Bez niego odbiorcy, którzy to sprawdzają, pomijają ten adres. Rekord trafia do DNS odbiorcy raportów, nie do twojego: serwisy raportów publikują wildcard dla wszystkich klientów, więc zwykle to literówka albo skrzynka partnera.

Czy subdomeny potrzebują własnego rekordu DMARC?

Zwykle nie. Subdomena bez rekordu dostaje politykę swojej domeny organizacyjnej: sp dla subdomen, które istnieją, np dla nazw, które nie istnieją, oba z powrotem do p. Publikuj rekord na subdomenie tylko wtedy, gdy potrzebuje innej polityki. Rekord na nazwie pośredniej, jak team.example.com dla www.team.example.com, nie jest używany dla głębszej nazwy.

Co się stanie, gdy domena opublikuje dwa rekordy DMARC?

Odbiorcy odrzucają oba, więc żadna polityka DMARC nie obowiązuje i nie są wysyłane żadne raporty, nawet jeśli jeden z nich mówi reject (RFC 9989 §4.10). Zwykle zdarza się to, gdy dodano nowy rekord bez usunięcia starego albo gdy hosting DNS doda domyślny. Zostaw jeden rekord w _dmarc i usuń drugi; narzędzie pokazuje, który wygląda na zamierzony.

Dlaczego DMARC nie przechodzi, skoro SPF przechodzi?

DMARC wymaga, by SPF przeszedł dla domeny zgodnej z adresem From:. Większość usług poczty wysyła z własną domeną zwrotną, więc SPF przechodzi dla nich, nie dla ciebie, i to się nie liczy. To samo dotyczy DKIM podpisanego domeną usługi. Skonfiguruj własny DKIM lub własną ścieżkę zwrotną usługi, żeby domena, która przechodzi, była twoja.

Narzędzie pokazuje brak rekordu, mimo że rekord dodano przed chwilą. Dlaczego?

Najpierw sprawdź pole hosta: większość paneli DNS chce tylko _dmarc, a wpisanie tam _dmarc.example.com tworzy _dmarc.example.com.example.com. Potem poczekaj, aż stara odpowiedź wygaśnie: jeśli nazwę sprawdzano wcześniej, resolvery trzymają jej NXDOMAIN przez ujemny TTL strefy, często od 5 minut do godziny. SERVFAIL lub przekroczenie czasu pokazuje się jako „nie udało się sprawdzić”, nigdy jako brak rekordu.