Sprawdzanie rekordu TXT, rekordów MX i innych rekordów DNS domeny

Sprawdzanie rekordu TXT i sprawdzanie rekordów MX to najczęstsze zadania z DNS: w TXT przechowuje się SPF, DKIM, DMARC i weryfikacje własności domeny, a MX wskazuje, dokąd dostarczać pocztę. Najszybciej sprawdzisz rekordy DNS domeny online, wpisując domenę w sprawdzanie DNS: narzędzie za darmo i bez rejestracji pokaże rekordy A, AAAA, CNAME, MX, NS, TXT, SOA i SRV wraz z ich wartościami i TTL. Serwery pocztowe z priorytetami dokładniej rozłoży sprawdzanie MX, a z wiersza poleceń to samo pokażą nslookup -type=txt example.com i nslookup -type=mx example.com. Poniżej: jak czytać wynik i co zrobić, jeśli rekordy „się nie aktualizują”.

Jak sprawdzić rekordy DNS domeny online

1. Otwórz sprawdzanie DNS i wpisz domenę: example.com. Protokołu i ścieżki nie trzeba usuwać — narzędzie samo wyodrębni nazwę hosta z adresu.
2. Subdomenę wpisz w całości: www.example.com, shop.example.com. Każda nazwa ma własne rekordy, a CNAME zwykle jest ustawiony właśnie na subdomenie.
3. Porównaj wynik z danymi od hostingu lub dostawcy poczty: IP w rekordzie A, nazwy w MX, ciągi w TXT.
4. Zwróć uwagę na kolumnę TTL — podpowie, po ilu sekundach odświeży się pamięć podręczna, jeśli właśnie coś zmieniłeś.

Narzędzie odpytuje rekordy przez resolver naszego serwera, czyli pokazuje, co widzi jeden punkt w sieci w tej chwili. Aby sprawdzić propagację zmian, porównaj odpowiedź z publicznymi resolverami za pomocą poleceń z następnej sekcji.

Nazw z podkreśleniem, takich jak _dmarc.example.com, nie wpisuje się w ogólne sprawdzanie — do rekordów pocztowych są osobne narzędzia: sprawdzanie rekordów MX pokaże serwery pocztowe z priorytetami i IP, sprawdzanie SPF rozłoży mechanizmy i łańcuchy include, a sprawdzanie DMARC — politykę i adresy raportów.

Sprawdzanie DNS przez nslookup i dig

nslookup jest dostępny w Windows, macOS i Linuksie, dig — w macOS i większości dystrybucji Linuksa. Ostatni parametr nslookup lub argument @ w dig określa, który serwer DNS odpytać.

nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8
nslookup -type=CNAME www.example.com

dig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com NS +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig selector1._domainkey.example.com TXT +short
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

W PowerShellu to samo robi Resolve-DnsName example.com -Type MX. Aby zobaczyć, co naprawdę jest zapisane w strefie, bez pamięci podręcznych po drodze, odpytaj bezpośrednio serwer autorytatywny: najpierw dig example.com NS +short, potem dig @ns1.twoj-dostawca.net example.com A. Polecenie dig +trace example.com przejdzie cały łańcuch od serwerów głównych i pokaże, na którym kroku odpowiedź odbiega od oczekiwanej.

Typy rekordów DNS i co w nich sprawdzać

Sprawdzanie rekordu CNAME

CNAME mówi: „ta nazwa jest aliasem innej nazwy, pytaj tam”. Ustawia się go na subdomenach, które wskazują na usługę zewnętrzną: kreator stron, CDN, sklep na platformie (np. Shopify czy Shoper). Rekord CNAME domeny sprawdzisz online, wpisując subdomenę w sprawdzanie DNS, albo poleceniem dig www.example.com CNAME +short.

• CNAME nie może współistnieć z innymi rekordami dla tej samej nazwy. Dlatego na głównej domenie (example.com, gdzie zawsze są NS i SOA) zwykłego CNAME ustawić nie można. Niektórzy dostawcy DNS oferują zamiennik — ALIAS, ANAME lub „spłaszczanie” CNAME: z zewnątrz taki rekord wygląda jak zwykły A.
• Łańcuchy CNAME → CNAME → CNAME działają, ale spowalniają rozwiązywanie nazwy i utrudniają szukanie błędów.
• CNAME na nieistniejącą nazwę to częsta przyczyna, dla której subdomena „się nie otwiera” po wyłączeniu usługi zewnętrznej.
• Kropka na końcu. W niektórych panelach wartość trzeba wpisać z kropką na końcu, inaczej zostanie do niej dopisana Twoja domena i wyjdzie shop.example.net.example.com.

Jak sprawdzić rekord TXT domeny

1. Ustal, pod jaką nazwą powinien być rekord. SPF i weryfikacja Search Console — na samej domenie (w panelu DNS zwykle „@”), DMARC — na _dmarc.example.com, DKIM — na selektor._domainkey.example.com. Weryfikacje innych usług — tam, gdzie wskazała usługa.
2. Sprawdź online. Dla samej domeny — sprawdzanie DNS: zakładka TXT pokaże wszystkie rekordy TXT z TTL. Nazw z podkreślnikiem ogólne sprawdzanie nie przyjmuje — do nich służą sprawdzanie SPF, sprawdzanie DKIM i sprawdzanie DMARC.
3. Albo z wiersza poleceń:

   nslookup -type=txt example.com
   nslookup -type=txt _dmarc.example.com 8.8.8.8
   dig TXT example.com +short
   dig TXT _dmarc.example.com +short
   dig @ns1.twoj-dostawca.net TXT example.com +short

   Ostatnie polecenie pyta bezpośrednio serwer autorytatywny — rekord widać od razu po dodaniu, bez czekania na pamięć podręczną.
4. Porównaj wartość znak po znaku z tym, co podała usługa: zbędna spacja, ucięty klucz albo cudzysłowy wewnątrz wartości psują weryfikację.

Rekordu weryfikacyjnego Google nie usuwaj po zweryfikowaniu usługi: bez niego weryfikacja może zostać utracona.

Częste błędy w rekordach TXT

• Dwa rekordy v=spf1. Według standardu SPF to błąd i weryfikacja przestaje działać w całości. Mechanizmy drugiej usługi trzeba dopisać do istniejącego rekordu. Uwaga: nasze sprawdzanie SPF analizuje pierwszy znaleziony rekord v=spf1, więc duplikatów szukaj na liście TXT w sprawdzaniu DNS albo poleceniem dig TXT example.com +short.
• Cudzysłowy w wartości. W większości paneli wartość wpisuje się bez cudzysłowów — panel doda je sam. Wklejone w cudzysłowach czasem stają się częścią tekstu i dig pokazuje "\"v=spf1 ...\"".
• Ciąg dłuższy niż 255 znaków. Pojedynczy ciąg w rekordzie TXT ma limit 255 znaków, więc długa wartość — zwykle 2048-bitowy klucz DKIM — jest zapisywana jako kilka ciągów w cudzysłowach w jednym rekordzie: "v=DKIM1; k=rsa; p=MIIB..." "...ciąg dalszy". Odbiorca skleja je bez spacji. Wiele paneli dzieli wartość samo; błędem jest utworzenie zamiast tego dwóch osobnych rekordów TXT.
• Zła nazwa. W polu „Nazwa” wpisano pełną domenę, a panel dopisał ją jeszcze raz: wyszło _dmarc.example.com.example.com.

Jak działają same rekordy i jak je skonfigurować — w artykułach SPF, DKIM i DMARC oraz DKIM: rekord i selektor.

Rekordy TXT: SPF, DKIM i DMARC

Jeśli e-maile z domeny trafiają do spamu, sprawdź trzy rekordy TXT:

example.com.                     TXT  "v=spf1 include:_spf.google.com ~all"
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com.              TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• SPF — lista serwerów, które mogą wysyłać pocztę z domeny. Rekord v=spf1 musi być jeden: dwa rekordy SPF unieważniają weryfikację. Liczba zapytań DNS przy sprawdzaniu SPF jest ograniczona do dziesięciu, a długie łańcuchy include łatwo ją przekraczają.
• DKIM — klucz publiczny podpisu, znajduje się pod adresem selektor._domainkey.domena. Selektor ustala dostawca poczty; bez niego rekordu nie znajdziesz.
• DMARC — polityka dla wiadomości, które nie przeszły SPF i DKIM: none (tylko raporty), quarantine (do spamu), reject (odrzuć).

W TXT przechowuje się też potwierdzenia własności: na przykład usługę typu domena w Search Console weryfikuje się rekordem TXT — zobacz artykuł o podłączaniu usługi.

Jak sprawdzić rekordy MX

Rekord MX mówi nadawcom, który serwer przyjmuje pocztę domeny. Ma dwa pola: priorytet i nazwę serwera. Im mniejsza liczba, tym wyższy priorytet: najpierw próbuje się serwera z 10, gdy jest niedostępny — z 20. Kilka rekordów MX o tym samym priorytecie dzieli ruch — nadawcy wybierają między nimi, to zwykłe równoważenie obciążenia.

1. Wpisz domenę w sprawdzanie rekordów MX: pokaże serwery pocztowe według priorytetu, ich adresy IPv4 i IPv6, rekordy PTR i rozpozna dostawcę poczty.
2. Albo uruchom nslookup -type=mx example.com lub dig MX example.com +short — odpowiedź wygląda jak 10 mx1.example.net.
3. Upewnij się, że każda nazwa z MX sama rozwiązuje się na adres: dig A mx1.example.net +short.
4. Porównaj listę z instrukcją dostawcy poczty: zwykle wymaga usunięcia wszystkich starych MX, a nie dodania swoich obok.

Brak rekordów MX? Zgodnie z RFC 5321 nadawcy spróbują dostarczyć pocztę na adres A/AAAA samej domeny — to tak zwany niejawny MX. Domena, która w ogóle nie przyjmuje poczty, powinna opublikować null MX, czyli rekord 0 . (RFC 7505): nadawca od razu zwróci wiadomość. Bez MX i bez A poczty na domenę nie da się dostarczyć.

MX odpowiada tylko za odbiór. Za to, żeby Twoje wiadomości nie lądowały w spamie u odbiorców, odpowiadają SPF, DKIM i DMARC, a drogę konkretnej wiadomości pokażą jej nagłówki — zob. jak czytać nagłówki wiadomości e-mail.

TTL i propagacja DNS

TTL to czas w sekundach, przez który resolvery przechowują odpowiedź w pamięci podręcznej. Przy TTL 3600 dostawca, który raz zapytał o Twój rekord A, przez godzinę będzie podawał starą wartość, nawet jeśli już ją zmieniłeś. Tak zwana „propagacja DNS” to właśnie stopniowe wygasanie pamięci podręcznych na całym świecie. Zmiana serwerów NS u rejestratora trwa zwykle dłużej: rekordy w strefie domeny najwyższego poziomu mają własny, zazwyczaj długi TTL.

• Przed planowanymi zmianami obniż TTL do 300 sekund — z wyprzedzeniem nie krótszym niż stary TTL.
• Jeśli sprawdzałeś nazwę, zanim utworzono rekord, odpowiedź negatywna też trafia do pamięci podręcznej — na czas z rekordu SOA strefy.
• Przeszkadza też lokalna pamięć podręczna: w Windows czyści ją ipconfig /flushdns, w macOS — sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
• Jeśli serwer autorytatywny odpowiada poprawnie, a publiczne resolvery nie, to nie błąd: trzeba poczekać, aż minie TTL.

Kiedy trzeba to sprawdzać

• Strona nie otwiera się u wszystkich. Częsta przyczyna — rekordy zmieniono niedawno i część dostawców ma jeszcze stare dane.
• E-maile trafiają do spamu. Sprawdź SPF, DKIM i DMARC w rekordach TXT.
• Przeprowadzka na inny hosting. Przed przełączeniem warto zapisać bieżące rekordy.
• Podłączanie usługi zewnętrznej: poczty, CDN, kreatora stron — prawie zawsze to CNAME lub TXT.

Typowe błędy

• Rekordy edytowane w złym miejscu. Jeśli NS domeny wskazują na jednego dostawcę, zmiany w panelu innego (np. rejestratora) na nic nie wpływają. Najpierw sprawdź NS.
• Dwa rekordy SPF po podłączeniu drugiej usługi pocztowej zamiast połączenia ich w jeden.
• CNAME na głównej domenie, który psuje MX i TXT.
• Zapomniane MX przy przeprowadzce: strona działa, a poczta przestała dochodzić.
• Stary IP dla www: rekord A głównej domeny zaktualizowano, a dla www zostawiono poprzedni.

Lista kontrolna przeprowadzki na inny hosting

1. Dobę wcześniej obniż czas życia rekordów — wtedy przełączenie szybko się rozejdzie.
2. Zapisz bieżące rekordy: A, MX, TXT i NS muszą być spisane przed zmianami.
3. Uruchom stronę na nowym serwerze i sprawdź ją po IP, nie ruszając domeny.
4. Przełącz rekord A i obserwuj odpowiedzi z różnych resolverów.
5. Upewnij się, że poczta działa: o MX i SPF przy przeprowadzce zapomina się najczęściej.
6. Przywróć poprzedni czas życia rekordów i sprawdź certyfikat SSL pod nowym adresem.