Rekordy MX i TXT — wyjaśnienie

Czym są rekordy MX?

Rekord MX mapuje domenę na jeden lub więcej mail exchangerów, każdy z liczbą priorytetu (preferencji). Nadawcy próbują najpierw najniższej liczby; równe priorytety mogą być load-balansowane. Przykład: `10 mail.example.com` i `20 mail-backup.example.com`.

Cele MX muszą być hostname'ami z rekordami A lub AAAA — nie gołymi adresami IP. Po zmianie MX zweryfikuj w DNS Checker i poczekaj na wygaśnięcie TTL w starych cache. Łącz kontrolę MX z Blacklist Checker, gdy przychodząca poczta nagle trafia do spamu.

Domeny produkcyjne powinny publikować co najmniej dwa hosty MX w różnych sieciach. Gdy główny exchanger jest niedostępny, RFC 5321 wymaga od nadawców próby następnego hosta o niższym priorytecie. Dokumentuj oba priorytety w ticketach zmian i ponownie uruchamiaj DNS Checker po każdej edycji MX, aby wątki supportu pokazywały live priorytety, nie zrzuty panelu.

Czym są rekordy TXT?

Rekordy TXT przechowują dowolne stringi tekstowe. Operatorzy poczty publikują SPF na apex (lub legacy subdomain) jako `v=spf1 ...`, DKIM jako selektory typu `default._domainkey.example.com` i DMARC pod `_dmarc.example.com`. Weryfikacja strony używa krótkich tokenów (`google-site-verification=...`, `MS=ms...`).

Wiele stringów w jednej odpowiedzi TXT jest normalne. Niektóre panele dzielą długie klucze DKIM na fragmenty. Przy troubleshootingu kopiuj dokładną sklejoną wartość z DNS Checker zamiast przepisywać z PDF.

TXT służy też do BIMI, MTA-STS i TLS-RPT w zaawansowanych setupach poczty — nadal publikowany jako tekst pod przewidywalnymi nazwami. Gdy dostawca rotuje selektory DKIM, stary i nowy selektor mogą krótko współistnieć; odpytuj TXT po każdej rotacji i zanotuj TTL przed usunięciem wycofanych kluczy.

SPF, DKIM i DMARC w TXT

SPF wymienia hosty mogące wysyłać pocztę dla domeny (`v=spf1 include:... ~all`). Na jednym owner name może istnieć tylko jeden TXT SPF — zduplikowane stringi SPF całkowicie unieważniają politykę. Scal include zamiast dodawać drugi rekord na apex.

DKIM publikuje klucz publiczny pod `selector._domainkey.example.com`. Wyrównanie z domeną nagłówka From ma znaczenie dla pass/fail DMARC. Po onboardingu relay potwierdź TXT selektora w DNS Checker względem panelu dostawcy przed wysyłką masową.

DMARC pod `_dmarc.example.com` ustawia politykę (`p=none`, `quarantine`, `reject`) i adresy raportów (`rua=`, `ruf=`). Zacznij od `p=none`, aby zbierać raporty agregowane, potem zaostrz, gdy SPF i DKIM stabilnie się wyrównują. Raporty aggregate pomagają wykryć nieautoryzowanych nadawców, zanim przejdziesz na `p=reject`. Po każdej migracji poczty ponownie sprawdź wszystkie trzy rodziny przez DNS Checker — sam MX nigdy nie dowodzi poprawnego SPF.

Jak sprawdzić MX i TXT online

Krok 1 — Otwórz DNS Checker i wpisz domenę (apex lub subdomenę). Krok 2 — Uruchom pełny lookup lub skup się na sekcjach MX i TXT. Krok 3 — Porównaj priorytet, cele i stringi TXT z przewodnikiem setup dostawcy poczty. Krok 4 — Jeśli wartości są nieaktualne, zanotuj TTL i ponów zapytanie po wygaśnięciu.

Dla samego MX otwórz narzędzie DIG, wybierz typ MX i sprawdź sekcję answer. Użyj tej samej domeny w WHOIS, by potwierdzić, że nameservery zgadzają się z panelem DNS, który edytowałeś.

Archiwizuj wynik checkera w ticketach: priorytety, hostname exchangerów, pełne stringi SPF/DKIM/DMARC i wartości TTL. Gdy Authentication-Results nadal pokazuje błędy po poprawce, poczekaj pełne okno TTL i ponownie uruchom DNS Checker — rekursywne cache często przeżywają moment Save w panelu. Przy wysyłce masowej zachowaj też nagłówki wiadomości testowych obok snapshotu DNS.

Weryfikacja i tokeny TXT stron trzecich

Search Console, Microsoft 365, Stripe i wystawcy certyfikatów każdy prosi o unikalny dowód TXT na apex lub etykietach `_dnsauth`. Te tokeny współistnieją ze SPF jako osobne rekordy TXT pod tą samą nazwą — w przeciwieństwie do SPF, wiele niepowiązanych stringów TXT na jednym owner jest dozwolone. Nie usuwaj verification TXT zaraz po sukcesie — niektóre usługi okresowo ponownie weryfikują domenę.

Przed usunięciem « starych » TXT podczas cleanup potwierdź, że żaden nie jest aktywną weryfikacją ani kluczem DKIM. DNS Checker wypisuje każdą odpowiedź TXT pod nazwą, aby porównać z dokumentacją dostawcy zamiast zgadywać z pamięci. Dla Stripe i CA często potrzebne są osobne etykiety `_dnsauth` lub `_acme-challenge` — sprawdź dokładną nazwę z dokumentacji vendora.

Po dodaniu verification TXT od razu odpytaj przez DNS Checker, potem ponownie po TTL, jeśli vendor nadal zgłasza błąd. Niektórzy rejestratorzy publikują strefy partiami co kilka minut — dwa identyczne przebiegi checkera pięć minut apart dają pewność szybciej niż sam refresh UI vendora. Przy statusie « pending » zachowaj oba przebiegi checkera w tickecie jako dowód publikacji.

Typowe problemy

Brak SPF to najszybsza droga do folderów spam. Zły priorytet MX kieruje pocztę na wycofany host. Literówki w TXT weryfikacji psują Search Console lub setup Microsoft 365. Nieaktualne odpowiedzi cache po nieobniżonej TTL przed cutover wyglądają jak «DNS zepsuty», gdy propagacja jeszcze trwa.

Duplikaty SPF pod tą samą nazwą unieważniają SPF całkowicie — scal w jeden TXT. DMARC bez wyrównanego DKIM/SPF raportuje błędy, ale ich nie naprawia; traktuj DMARC jako warstwę polityki nad działającymi rekordami auth.

Wskazanie MX na etykietę tylko z CNAME psuje rozwiązywanie na strict resolverach. Publikacja MX na hostname bez działających A/AAAA tworzy cichą utratę poczty — potwierdzaj cele exchangerów w DNS Checker po każdej zmianie targetu MX.

MX i TXT podczas migracji

Migracje poczty cicho się psują, gdy MX jest zaktualizowany zanim SPF/DKIM/DMARC są gotowe u nowego dostawcy, lub gdy stare MX zostają z niższymi liczbami priorytetu niż zamierzono. Opublikuj baseline przez DNS Checker przed cutover, potem porównuj sekcje MX i TXT co godzinę w oknie migracji. Uwzględnij w baseline nie tylko apex, ale też subdomeny mail lub smtp, jeśli biorą udział w routingu.

Obniż TTL na MX i krytycznych TXT 24–48 godzin przed przełączeniem, jeśli host DNS na to pozwala. Potwierdź niższy TTL publicznie przez DNS Checker — niektóre panele pokazują 300 sekund, podczas gdy live strefa nadal serwuje 3600 do zakończenia następnego cyklu publikacji. Zanotuj w tickecie, kto odpowiada za publish u rejestratora i u hosta DNS, jeśli to różne zespoły.

Trzymaj MX starego dostawcy z wyższym priorytetem (większą liczbą), dopóki nie zweryfikujesz dostawy przychodzącej na nowym stacku, potem usuń wycofane exchangery. Poczta wychodząca może nadal używać starych include SPF, dopóki nie zaktualizujesz apex TXT — sprawdź oba kierunki przez DNS Checker przed zamknięciem ticketu.

Udokumentuj właściciela każdego stringu TXT (weryfikacja marketingu, poczta IT, raporty DMARC finansów), aby przyszłe cleanupy nie usunęły produkcyjnych rekordów uwierzytelniania przez pomyłkę.

Najczęściej zadawane pytania

Ile trwa, zanim zmiany DNS staną się widoczne?

Większość resolverów respektuje TTL (time to live). Przy TTL 3600 sekund spodziewaj się do godziny, zanim wygasną odpowiedzi w cache. Obniż TTL przed migracją, wprowadź zmianę i zweryfikuj nowe wartości w DNS Checker.

Czy mogę sprawdzić MX i TXT bez instalacji dig?

Tak. Otwórz DNS Checker, wpisz domenę i filtruj lub przewiń do sekcji MX i TXT. Dla pojedynczego typu rekordu możesz też użyć narzędzia DIG z typem MX lub TXT.

Dlaczego poczta działa, a SPF nadal pada?

SPF autoryzuje tylko wysyłające IP lub łańcuchy include. Działający rekord MX nie oznacza poprawnego SPF. Porównaj wychodzące IP SMTP z łańcuchem include SPF i użyj lookup TXT, by potwierdzić, że live string zgadza się z dokumentacją dostawcy poczty.

Czy powinienem używać wielu rekordów MX?

Tak w produkcji. Opublikuj co najmniej dwa hosty MX z różnymi priorytetami (niższa liczba = wyższy priorytet). Gdy primary jest niedostępny, nadawcy próbują następnego priorytetu zgodnie z RFC 5321.

Który RFC definiuje SPF?

SPF jest zdefiniowany w RFC 7208 (dawniej RFC 4408). DKIM to RFC 6376, a DMARC to RFC 7489. Wszystkie publikowane są jako rekordy TXT pod przewidywalnymi nazwami.

Czy mogę opublikować MX i SPF na tej samej etykiecie hostname?

MX i SPF zwykle żyją na różnych nazwach — MX na apex lub subdomenie mail, SPF jako TXT na apex. Nigdy nie stawiaj CNAME na etykiecie, która potrzebuje też MX lub SPF. Użyj DNS Checker, aby potwierdzić, że konfliktujące typy nie dzielą jednego owner name. Gdy dostawca prosi o « jeden rekord dla wszystkiego », prawie zawsze chodzi o różne nazwy, a nie jeden label z MX i SPF jednocześnie.

Jak często ponownie sprawdzać MX i TXT w produkcji?

Po każdej zmianie DNS lub dostawcy poczty, plus kwartalne audyty dla domen wysyłających masową pocztę. Automatyczny monitoring przez API DN01 może alertować, gdy priorytety MX lub stringi SPF odbiegają od oczekiwanych wartości.

Czy DNS Checker przechowuje moje lookupy?

Udane sprawdzenia mogą pojawić się w lokalnej historii sesji przeglądarki dla wygody. Użyj udokumentowanego API z własnym tokenem, jeśli potrzebujesz powtarzalnego monitoringu bez web UI.