No DMARC record found: jedna linijka, której brakuje twojej domenie

W skrócie

• Komunikat oznacza, że pod adresem _dmarc.yourdomain.com nie ma rekordu TXT. Twój serwer pocztowy nie jest zepsuty.
• Dodaj jeden rekord TXT z hostem _dmarc i wartością v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Przy p=none dostarczanie pozostaje dokładnie takie jak wcześniej.
• Gmail, Yahoo i Outlook.com wymagają tego rekordu tylko od nadawców masowych. Dodaj go mimo to: Google liczy całą domenę i nigdy nie cofa statusu nadawcy masowego, a raporty zaczynają przychodzić dopiero wtedy, gdy rekord istnieje.
• Jeśli narzędzie sprawdzające nadal nic nie znajduje, poszukaj przyczyny: DNS zmieniony u niewłaściwego dostawcy, zdublowana nazwa hosta albo dwa rekordy DMARC. Dwa rekordy znoszą się nawzajem.
• Standard zmienił się w maju 2026 r. wraz z RFC 9989: zniknął pct, nowe są t i np. Pomoc Google w październiku 2026 r. nadal opisuje pct.

„No DMARC record found” (nie znaleziono rekordu DMARC) oznacza, że narzędzie sprawdzające zapytało DNS o rekord TXT pod adresem _dmarc.yourdomain.com i nie dostało odpowiedzi. Na twoim serwerze pocztowym nic się nie zepsuło. Rozwiązaniem jest jeden rekord TXT z hostem _dmarc i wartością v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Przy p=none twoja poczta jest dostarczana dokładnie tak jak wcześniej. Informujesz tylko odbiorców, że stosujesz DMARC, i zaczynasz dostawać raporty.

DMARC to trzeci z trzech rekordów pocztowych, obok SPF i DKIM. SPF wymienia serwery, które mogą wysyłać w imieniu twojej domeny. DKIM podpisuje każdą wiadomość. DMARC mówi odbiorcy, co zrobić, gdy żaden z nich nie potwierdza domeny z twojego adresu From, i dokąd wysłać dzienne podsumowanie. Od maja 2026 r. definiuje go RFC 9989, który zastąpił starszy RFC 7489. Wiele poradników nadal opisuje starszą wersję, podobnie jak strona pomocy Google według stanu na październik 2026 r.

Rekord, który trzeba dodać

Zaloguj się tam, gdzie zarządzasz DNS swojej domeny. To firma, na którą wskazują twoje serwery nazw, a nie zawsze ta, w której domena została kupiona. Dodaj nowy rekord z tymi wartościami:

Zapisany jako linijka w pliku strefy gotowy rekord wygląda tak:

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

Zamień example.com na własną domenę. Oto, co robią trzy części rekordu:

• v=DMARC1 oznacza linijkę jako rekord DMARC. Musi stać na początku, a DMARC1 musi być zapisane wielkimi literami. W przeciwnym razie odbiorcy ignorują cały rekord.
• p=none to polityka: traktuj moją pocztę tak, jak i tak byś ją potraktował. Z powodu tego rekordu nic nie jest blokowane ani przenoszone do spamu.
• rua=mailto:… to adres dla dziennych raportów. Załóż ten adres albo alias, który przekazuje pocztę do ciebie, zanim opublikujesz rekord.

Google wymienia te same trzy pola na stronie Set up DMARC (konfigurowanie DMARC). Prosi też, żeby SPF i DKIM działały od 48 godzin, zanim dodasz DMARC. Jeśli twoje narzędzie sprawdzające zgłasza także te dwa rekordy, napraw je najpierw.

Jak sprawdzić, czy się udało

Zapytaj DNS samodzielnie. W macOS lub Linuksie otwórz terminal i użyj dig. W Windows użyj nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Jeśli rekord jest aktywny, linijka wraca w cudzysłowie. Tak odpowiedziała domena samego Google 5 października 2026 r.:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Pusta odpowiedź oznacza, że rekordu jeszcze nie ma albo nie ma go tam, gdzie szukają odbiorcy. Gdy twoje własne zapytanie pokaże linijkę, ponownie uruchom narzędzie, które wyświetliło komunikat. MXToolbox na przykład opisuje problem słowami „No DMARC Record found” i wyjaśnia, że „twoja domena nie ma opublikowanego rekordu DMARC”.

Co oznacza każda część rekordu DMARC

Rekord to lista par tag=value rozdzielonych średnikami. Standard wymaga tylko znacznika v, który musi stać na początku. Jako drugi wpisz p: pomoc Google podaje, że „znaczniki v i p muszą być wymienione jako pierwsze”, a starszy standard oczekiwał tej samej kolejności. Oto znaczniki z RFC 9989, sekcja 4.7:

Starsze rekordy często kończą się na pct=100. Ten znacznik miał stosować politykę do części poczty, która nie przechodzi weryfikacji. RFC 9989 usunął go razem z rf i ri i podaje powód:

Doświadczenie operacyjne pokazało, że znacznik „pct” zwykle nie był stosowany dokładnie, chyba że podana wartość wynosiła 0 albo 100 (wartość domyślna), a niedokładności przy innych wartościach bardzo się różniły między implementacjami.

Odbiorcy muszą ignorować znaczniki, których nie znają, więc stare pct=100 nie szkodzi. Rekordy yahoo.com i microsoft.com nadal je zawierały 5 października 2026 r., a strona pomocy Google wciąż zaleca pct przy stopniowym wdrażaniu. W nowym rekordzie go pomiń.

Czy potrzebujesz DMARC, jeśli wysyłasz tylko kilka emaili dziennie?

Według opublikowanych zasad dużych dostawców poczty rekord DMARC jest wymagany, gdy wysyłasz masowo. Poniżej tego progu jest zaleceniem.

Źródła to Email sender guidelines (wytyczne dla nadawców) Google, Sender Best Practices Yahoo i ogłoszenie dla nadawców o dużym wolumenie Microsoftu, wszystkie według stanu na październik 2026 r. Jeśli wysyłasz trzydzieści emaili dziennie z jednej skrzynki, żadne z nich nie wymaga tego rekordu. Mimo to są trzy powody, żeby dodać go już teraz.

• Próg liczy się dla całej domeny i nie jest zerowany. Google sumuje wszystkie wiadomości do prywatnych kont Gmail, które pochodzą z tej samej domeny głównej, łącznie z subdomenami. Jego FAQ dla nadawców mówi: „Nadawcy, którzy choć raz spełnią powyższe kryteria, są trwale uznawani za nadawców masowych”.
• Google i Yahoo zalecają go wszystkim. Google pisze: „zalecamy, aby zawsze konfigurować SPF, DKIM i DMARC dla swoich domen”. Yahoo „zdecydowanie zachęca wszystkich nadawców do opublikowania polityki DMARC dla każdej domeny, która wysyła pocztę”.
• Bez rekordu nie dostajesz raportów. To dzięki nim widzisz, które serwery wysyłają pocztę z twoją domeną w polu From: zarówno twoje własne narzędzia, jak i obce osoby.

Dla nadawców masowych brak rekordu ma konsekwencje. FAQ Google dla nadawców wymienia dla niego błąd tymczasowy 4.7.31: „domena wysyłająca nie ma rekordu DMARC albo rekord DMARC nie określa polityki DMARC”. Ta sama strona podaje, że od listopada 2025 r. pocztę, która nie spełnia wymagań, czekają „tymczasowe i trwałe odrzucenia”.

Rekord dodany, a narzędzie sprawdzające nadal nic nie znajduje?

Wtedy przyczyną jest zwykle jedna z poniższych. Przejdź przez nie z zapytaniem dig podanym wyżej.

• DNS został zmieniony w niewłaściwym miejscu. Jeśli twoje serwery nazw są w innej firmie niż rejestrator, rekordy wpisane u rejestratora nigdy nie są odpytywane. dig +short NS example.com pokazuje, kto odpowiada za twoją domenę.
• Host jest błędny. Rekord leży w samym example.com albo pod zdublowaną nazwą, jak opisano wyżej. Odbiorcy pytają tylko o _dmarc.example.com.
• Są dwa rekordy DMARC. Standard jest tu surowy: „Jeśli dla jednego celu zwróconych zostanie kilka rekordów polityki DMARC, wszystkie są odrzucane”. Połącz je w jeden. Dwa adresy raportów trafiają do jednego rua, rozdzielone przecinkiem.
• Pierwszy znacznik to nie dokładnie v=DMARC1. Małe litery, literówka taka jak DMARC 1 albo p= przed nim unieważniają rekord.
• Typ rekordu to nie TXT albo wartość została wklejona z dokumentu razem z cudzysłowami drukarskimi. Wpisz wartość jako zwykły tekst, bez cudzysłowów, chyba że pomoc twojego dostawcy DNS ich wymaga.
• Stara odpowiedź jest jeszcze w pamięci podręcznej. Serwery DNS przez pewien czas pamiętają odpowiedź „nie ma takiego rekordu”. Zapytaj bezpośrednio jeden ze swoich serwerów nazw, dopisując jego nazwę do zapytania, na przykład dig +short TXT _dmarc.example.com @ns1.example.net. Jeśli rekord się tam pokazuje, narzędzia sprawdzające wkrótce też go zobaczą.

Dokąd trafiają raporty i co z nimi zrobić

Każdy odbiorca, który dostał pocztę z twoją domeną w polu From, wysyła raport na adres rua. Według strony Google About DMARC reports (o raportach DMARC) są one „zwykle wysyłane emailem raz dziennie”. Raport to plik XML, zwykle skompresowany, dołączony do emaila. Format opisuje RFC 9990.

Google ostrzega, że duże organizacje „mogą dostawać setki, a nawet tysiące raportów dziennie”, i zaleca grupę albo osobną skrzynkę. Liczba zależy od tego, ile wysyłasz i do ilu domen, więc jedna lub dwie skrzynki dają ich znacznie mniej. Wystarczy alias taki jak dmarc@ z filtrem do osobnego folderu.

Adres powinien być w tej samej domenie co rekord. Jeśli chcesz dostawać raporty gdzie indziej, ta druga domena musi się zgodzić, publikując własny rekord. Bez niego odbiorcy muszą zignorować adres (RFC 9990, sekcja 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

Dlatego darmowy adres Gmail nie sprawdza się jako adres raportów: gmail.com nie publikował takiego rekordu, gdy sprawdzaliśmy to 5 października 2026 r.

W pliku każdy blok record odpowiada jednemu serwerowi wysyłającemu: zawiera jego adres IP, liczbę wiadomości oraz, w części policy_evaluated, informację, czy DKIM i SPF przeszły dla twojej domeny. Szukasz dwóch rzeczy. Znane ci serwery, które pokazują fail, wymagają naprawy, a jak to zrobić, wyjaśnia poradnik DMARC nie przechodzi, chociaż SPF i DKIM przechodzą. Serwery, których nie znasz, to albo zapomniane narzędzie, albo ktoś, kto używa twojej nazwy.

Po p=none: kiedy zaostrzyć politykę

p=none to tryb monitorowania. Spełnia minimum, którego wymagają dostawcy poczty, ale nikomu nie przeszkadza w podrabianiu twojego adresu. Robią to dopiero p=quarantine, która prosi odbiorców, żeby traktowali pocztę nieprzechodzącą weryfikacji jako podejrzaną, i p=reject, która prosi o jej odrzucenie.

Zanim zaostrzysz politykę, każde prawowite źródło twojej poczty musi przechodzić weryfikację. RFC 9989 mówi, że takie luki „MUSZĄ zostać usunięte przed jakąkolwiek próbą” egzekwowania i że, zależnie od tego, jak często wysyłasz, pewność „może wymagać wielu miesięcy” raportów. Strona Google o wdrażaniu uznaje, że tydzień raportów „zwykle wystarcza”. Z jedną skrzynką i jednym lub dwoma narzędziami bliżej ci do liczby Google, ale daj sobie kilka tygodni, żeby w raportach pojawiły się też comiesięczna wysyłka faktur i formularz kontaktowy.

W sprawie samego kroku oba źródła się różnią. Google nadal proponuje p=quarantine; pct=5 i podnoszenie tej liczby. Standard porzucił pct i oferuje zamiast tego:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y prosi odbiorców, żeby na razie traktowali niepowodzenia o jeden poziom łagodniej, czyli jak none. Gdy raporty pozostają czyste, usuń t=y. Pamiętaj, że odbiorca, który nie zna tego znacznika, ignoruje go i stosuje quarantine w pełni, a strony Google według stanu na październik 2026 r. nie wspominają o t. Jeśli surowsza polityka uderzyłaby w pocztę, której jeszcze nie możesz naprawić, zostań przy p=none.

Gdzie w tym wszystkim jest WarmupBay

Gdy łączysz skrzynkę, WarmupBay sprawdza SPF, DKIM i DMARC jej domeny. Jeśli brakuje rekordu DMARC, pokazuje gotowy rekord do skopiowania. Rozgrzewanie możesz zacząć mimo to. Jeśli po 72 godzinach rekordów nadal brakuje, rozgrzewanie się zatrzymuje.

WarmupBay nie może dodać rekordu za ciebie, bo twój DNS należy do ciebie, i nie zbiera ani nie czyta raportów DMARC. Zajmuje się krokiem, który następuje po rekordach: twoja skrzynka wymienia kilka emaili dziennie z innymi skrzynkami we wspólnej sieci, zaczynając od trzech i dodając jeden dziennie, żeby aktywność wysyłki rosła stopniowo. 10 emaili dziennie jest za darmo. Zobacz, co obejmują kontrola i rozgrzewanie, albo połącz swoją skrzynkę, gdy rekord jest już na miejscu.

Częste pytania

Czy rekord DMARC dla example.com obejmuje też subdomeny, takie jak news.example.com?

Tak. Odbiorca najpierw pyta o rekord pod _dmarc.news.example.com. Jeśli go nie ma, sięga po rekord domeny organizacyjnej, czyli example.com. Wobec subdomeny stosowana jest polityka z sp, jeśli ją ustawisz, a w przeciwnym razie polityka z p.

Czy mogę opublikować v=DMARC1; p=none bez adresu rua?

Tak. To prawidłowy rekord i liczy się jako opublikowana polityka. Nie dostaniesz jednak raportów, więc nie zobaczysz, czy twoja własna poczta przechodzi weryfikację ani kto jeszcze używa twojej domeny. Yahoo określa działający adres rua jako zdecydowanie zalecany, a Google zaleca, żeby zawsze go podawać.

Czy potrzebuję rekordu DMARC dla drugiej domeny, której używam tylko do cold mailingu?

Tak. Odbiorcy sprawdzają domenę z adresu From każdej wiadomości, więc rekord w domenie głównej nie obejmuje innej domeny. Użyj w drugiej domenie tej samej linijki. Jeśli jej raporty mają trafiać na adres w domenie głównej, domena główna musi opublikować rekord autoryzacji opisany w części „Dokąd trafiają raporty”.

Co powinna opublikować domena, która nigdy nie wysyła emaili?

Ścisłą parę. M3AAWG zaleca dla domen, które nigdy nie wysyłają poczty, rekord SPF v=spf1 -all i rekord DMARC z p=reject, żeby nikt nie mógł użyć ich w adresie From. Dla DMARC jest to linijka v=DMARC1; p=reject pod _dmarc.

Czy p=none jest gorsze dla mojej poczty niż p=quarantine albo p=reject?

Opublikowane zasady dla nadawców Gmaila, Yahoo i Outlook.com wymagają co najmniej p=none i niczego surowszego. Polityka decyduje o tym, co dzieje się z pocztą, która nie przechodzi DMARC, a więc także ze sfałszowaną pocztą wysłaną w twoim imieniu. Jedna funkcja wymaga więcej: BIMI, czyli logo obok twoich wiadomości, według pomocy Google wymaga quarantine albo reject.

Źródła

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)