Sprawdzanie rekordów MX
Sprawdź rekordy MX domeny: priorytety serwerów pocztowych, TTL, zgodność z SPF. Diagnozuj problemy z dostarczaniem emaili. Bezpłatnie.
-
1Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku. -
2Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce. -
3Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.
return "Wynik gotowy w 0.1s";
}
MX Record Lookup Report Generated: 2026-10-20 23:58:29 Domain: gmail.com - 5 gmail-smtp-in.l.google.com (TTL 2425s) - 10 alt1.gmail-smtp-in.l.google.com (TTL 2425s) - 20 alt2.gmail-smtp-in.l.google.com (TTL 2425s) - 30 alt3.gmail-smtp-in.l.google.com (TTL 2425s) - 40 alt4.gmail-smtp-in.l.google.com (TTL 2425s) Domain: example.com No MX records found Domain: microsoft.com - 10 microsoft-com.mail.protection.outlook.com (TTL 2863s)
Rekordy MX (suma)
ze wszystkich sprawdzonych domen
Najniższy priorytet
niższy = serwer preferowany
Preferowany serwer
TTL preferowanego
czas życia rekordu w cache DNS
Linie
Znaki
Tryb
Z TTL
Sprawdzone domeny
Z rekordami MX
Bez rekordów MX
| Domena | Priorytet | Serwer pocztowy (target) | TTL |
|---|---|---|---|
| gmail.com | 5 | gmail-smtp-in.l.google.com | 2 425 s |
| gmail.com | 10 | alt1.gmail-smtp-in.l.google.com | 2 425 s |
| gmail.com | 20 | alt2.gmail-smtp-in.l.google.com | 2 425 s |
| gmail.com | 30 | alt3.gmail-smtp-in.l.google.com | 2 425 s |
| gmail.com | 40 | alt4.gmail-smtp-in.l.google.com | 2 425 s |
| microsoft.com | 10 | microsoft-com.mail.protection.outlook.com | 2 863 s |
Brak wierszy oznacza, że domena nie opublikowała rekordów MX albo nazwa jest niepoprawna — wtedy poczta spada na rekord A/AAAA samej domeny (zachowanie z RFC 5321).
| Zachowanie | Jak działa kod | Uwagi |
|---|---|---|
| Źródło danych | dns_get_record($domena, DNS_MX) — rekordy MX z serwerów DNS | Pola: pri (priorytet), target (serwer), ttl (czas życia) |
| Fallback | gdy dns_get_record jest niedostępny albo nic nie zwrócił — getmxrr() | Starsza funkcja zwraca tylko priorytet i serwer, bez TTL |
| Sortowanie | rekordy sortowane rosnąco po priorytecie (usort, operator <=>) | Niższy priorytet = serwer preferowany; serwery próbowane po kolei |
| Deduplikacja | identyczne pary priorytet+serwer scalane do jednego wiersza | Serwery DNS potrafią zwrócić ten sam rekord kilkukrotnie |
| Normalizacja domeny | obcięcie schematu http(s):// i ścieżki, kropka końcowa, małe litery, IDN→ASCII | Wklejenie URL-a (https://domena.pl/kontakt) też zadziała |
| Limit wejścia | pierwsze 50 domen z listy | Kolejne linie są ignorowane, żeby zapytanie DNS nie trwało w nieskończoność |
| TTL w raporcie | pokazywany tylko z włączoną opcją „Tak” przy polu Checkbox | TTL bywa odświeżany przy każdym zapytaniu — traktuj go orientacyjnie |
Warto wiedzieć — rekordy MX a dostarczalność poczty
Priorytet: niższy = preferowany
Serwer nadawcy próbuje rekordów od najniższego priorytetu w górę; kolejne biorą ruch, gdy preferowany nie odpowiada. Równe priorytety to rozkład obciążenia, nie awaria.
Brak MX = awaryjna trasa
Domena bez rekordów MX nie musi być martwa: zgodnie z RFC 5321 nadawca spróbuje dostarczyć pocztę na adres z rekordu A/AAAA samej domeny. To jednak rozwiązanie awaryjne, nie dobre praktyka.
MX to trasa, nie zaproszenie
Poprawne MX mówią, GDZIE dostarczać pocztę, ale nie gwarantują przyjęcia. O wiarygodności nadawcy decydują rekordy TXT: SPF, DKIM i DMARC — sprawdź je osobno dla domeny nadawcy.
TTL a zmiana dostawcy poczty
Przy migracji poczty najpierw obniż TTL (np. do 300 s), potem zmieniaj MX — stara wartość żyje w cache resolverów do wygaśnięcia. Wysoki TTL (np. 86 400 s) oznacza nawet dobę propagacji.
Oceń to narzędzie:
Powiązane narzędzia
Inne narzędzia, które mogą Ci się przydaćSprawdzanie rekordów MX – diagnostyka DNS poczty email
Rekordy MX (Mail Exchange) wskazują serwery odpowiedzialne za odbieranie poczty dla domeny. Błędna konfiguracja MX = email niedostarcza lub trafia do spamu. Narzędzie weryfikuje rekordy MX domeny, sprawdza priorytety i porównuje z konfiguracją popularnych usług pocztowych.
Czym są rekordy MX
Rekord MX: wpis DNS wskazujący serwer SMTP odbierający email dla domeny. Format: priorytet (liczba) + hostname. Niższy priorytet = wyższy pierwszeństwo. Przykład Google Workspace: MX 1 aspmx.l.google.com, MX 5 alt1.aspmx.l.google.com, MX 5 alt2.aspmx.l.google.com, MX 10 alt3.aspmx.l.google.com. Wiele rekordów MX = redundancja (failover).
Priorytety MX i redundancja
Serwer wysyłający email próbuje MX z najniższym priorytetem (wartość 1 > wartość 10). Jeśli niedostępny: przechodzi do następnego. Ta sama wartość priorytetu: losowy wybór (load balancing). Zalecana konfiguracja: min. 2 rekordy MX różnych providerów dla redundancji. Jeśli tylko 1 MX: awaria = brak poczty.
MX dla popularnych usług
Google Workspace: aspmx.l.google.com + alt1-4. Microsoft 365: domena.mail.protection.outlook.com. OVH: mx1.mail.ovh.net (priorytety 1/5/50). Hetzner: mx.hetzner.com. Zoho: mx.zoho.eu (EU), mx.zoho.com. FastMail: in1-smtp.messagingengine.com. ProtonMail: mail.protonmail.ch. Self-hosted Postfix: własny hostname.
Diagnozowanie problemów email
Email nie dochodzi: sprawdź rekordy MX (dig MX domena.pl). Sprawdź A record hosta MX (musi wskazywać na IP). Sprawdź SPF (TXT: v=spf1...). Sprawdź DMARC (TXT: _dmarc.domena.pl). Sprawdź blacklisty (MXToolbox blacklist check). Sprawdź logi SMTP serwera: /var/log/mail.log. Przetestuj wysyłkę: mail-tester.com.
Jak narzędzie ustala rekordy MX
Narzędzie wysyła do publicznego serwera DNS zapytanie typu MX dla podanej nazwy domeny. Odpowiedź to lista par: wartość preferencji (priorytet) oraz nazwa hosta pełniącego rolę exchange. DNS nie zwraca przy tym adresów IP — dostajesz wyłącznie nazwy, dlatego dla każdego hosta wykonywane jest dodatkowe zapytanie A (IPv4) i AAAA (IPv6), żeby potwierdzić, że host w ogóle istnieje w DNS.
Otrzymana lista jest sortowana rosnąco po priorytecie. Kolejność w odpowiedzi z serwera nie ma znaczenia — o wyborze decyduje wyłącznie liczba: mniejsza wartość oznacza wcześniejszą próbę dostarczenia. Narzędzie pokazuje więc wpisy w kolejności, w jakiej przechodziłby je nadawca, i zwraca uwagę na powtórzone priorytety oraz na brak rozwinięcia nazwy w rekord A lub AAAA.
Trzeci etap to kontrola spójności: czy domena ma jakikolwiek rekord MX, czy host MX nie jest przypadkiem aliasem CNAME (dla MX niedozwolonym), czy nie występuje rekord zerowy (null MX, czyli priorytet 0 i host zapisany jako kropka), który świadomie odcina domenę od poczty, oraz czy zestaw rekordów nie różni się między resolverami w trakcie propagacji.
Przykład: migracja domeny firma.pl z OVH do Microsoft 365
- Zapisz stan wyjściowy. Przed zmianami odczytaj rekordy MX dla firma.pl — w OVH jest to mx1.mail.ovh.net z priorytetami 1, 5 i 50. Zanotuj całą listę, bo to jedyny pewny sposób powrotu do konfiguracji sprzed migracji.
- Ustal host docelowy. W panelu Microsoft 365 odczytaj nazwę hosta MX przypisaną do domeny. Ma ona postać domena.mail.protection.outlook.com, gdzie zamiast słowa domena wstawiasz własną nazwę.
- Wprowadź rekord docelowy. Tam, gdzie dostawca wymaga pojedynczego wpisu (Microsoft 365), usuń wpisy OVH i dodaj rekord firma.pl.mail.protection.outlook.com. Przerwę między usunięciem a dodaniem trzymaj jak najkrótszą.
- Odczekaj czas życia rekordu. Po upływie TTL uruchom sprawdzanie ponownie. W wyniku powinien pojawić się host Outlook, a po starych wpisach OVH nie może zostać żaden ślad.
- Zweryfikuj hosty. Sprawdź, czy każdy zwrócony host MX rozwija się do rekordu A lub AAAA. Host bez adresu IP to wpis, który nigdy nie odbierze poczty.
- Potwierdź odbiorem wiadomości. Wyślij testową pocztę na skrzynkę w domenie i dopiero po jej odebraniu uznaj migrację za zakończoną. Kontrola DNS pokazuje konfigurację, nie działanie serwera.
Rekordy MX i priorytety dla typowych dostawców
| Dostawca | Host MX | Priorytet |
|---|---|---|
| Google Workspace | aspmx.l.google.com | 1 |
| Google Workspace | alt1.aspmx.l.google.com | 5 |
| Google Workspace | alt2.aspmx.l.google.com | 5 |
| Google Workspace | alt3.aspmx.l.google.com | 10 |
| Microsoft 365 | domena.mail.protection.outlook.com | jeden wpis |
| OVH | mx1.mail.ovh.net | 1 / 5 / 50 |
| Hetzner | mx.hetzner.com | — |
| Zoho | mx.zoho.eu (UE) lub mx.zoho.com | — |
Jak korzystać z wyniku
- Zapisuj wynik przed zmianą i po niej — bez stanu wyjściowego nie odróżnisz błędu konfiguracji od trwającej propagacji.
- Kontroluj priorytety, nie tylko nazwy hostów — dwa wpisy o tej samej wartości oznaczają losowy wybór serwera, a nie failover. Redundancja działa przy różnych priorytetach.
- Uwzględnij TTL — po edycji w panelu resolver może jeszcze zwracać stare dane. Nie diagnozuj problemu wcześniej, niż minie czas życia rekordu.
- Sprawdź rekord A każdego hosta MX — sama nazwa w MX nic nie daje, jeśli nie rozwija się do adresu IP.
- Nie zakładaj, że subdomeny dziedziczą MX — dla subdomeny potrzebny jest jej własny rekord MX, inaczej poczta kierowana jest na adres z rekordu A.
Czego wynik nie pokaże
- Jedno źródło odpowiedzi — wynik pochodzi z konkretnego resolvera i zależy od jego cache oraz TTL. Inny serwer DNS może zwrócić inny zestaw rekordów.
- Brak testu dostarczalności — narzędzie odczytuje DNS, ale nie łączy się z serwerem pocztowym odbiorcy. Poprawne MX nie dowodzą, że skrzynka przyjmuje wiadomości.
- Brak oceny SPF, DKIM i DMARC — te mechanizmy działają niezależnie od MX, więc technicznie poprawny wpis nadal może trafiać do spamu.
- Nietypowe konfiguracje — wildcard MX, hosty ukryte za aliasem CNAME i rekord null MX wymagają ręcznej interpretacji i bywają mylące w automatycznym odczycie.
Najczęstsze pytania
Jak sprawdzić rekordy MX w terminalu?
dig MX domena.pl (Linux/Mac, pakiet dnsutils). nslookup -type=MX domena.pl (Windows). host -t MX domena.pl. Odczyt TTL: dig MX domena.pl +nocmd +noall +answer. Sprawdź A record serwera MX: dig A aspmx.l.google.com. PowerShell: Resolve-DnsName -Type MX domena.pl.
Dlaczego email trafia do spamu?
Brak SPF lub fail. Brak DKIM (podpis emaila). Brak DMARC lub p=none. Reputacja IP: serwer na blackliście. Content spam filtry: słowa kluczowe. Brak reverse DNS (PTR record) dla IP serwera wysyłającego. Zbyt wysoki bounce rate. Za mały spam complaint rate. Sprawdź: mail-tester.com, MXToolbox Super Tool.
Czym różni się rekord MX od A i CNAME?
A record: mapuje hostname na IP (np. mail.domena.pl → 1.2.3.4). MX record: wskazuje serwer pocztowy dla domeny (z priorytetem). CNAME: alias nazwy (np. www → domena.pl). MX musi wskazywać na A record, NIE na CNAME – standard RFC zabrania MX pointing to CNAME (choć wiele serwerów to akceptuje, nie jest to prawidłowe).
Ile czasu zajmuje propagacja rekordów MX?
TTL rekordu: min. 300s (5 min) do 86400s (24h). Zmiana MX: propagacja globalnie 24-48h. Praktycznie: większość serwerów widzi zmianę w 1-4h. Przed migracją poczty: obniż TTL do 300s na kilka dni. Po migracji: podnieś TTL. Sprawdź propagację: dnschecker.org → wybierz typ MX.
Jak działa fallback MX gdy główny serwer niedostępny?
Serwer wysyłający próbuje kolejno: MX priorytetu 1 → timeout → MX priorytetu 5 → itd. Retry queue: serwer wysyłający ponawia próby przez 4-5 dni. Bounce (NDR): wysyłany po wyczerpaniu prób. Tymczasowy błąd (4xx): serwer ponawia. Permanentny błąd (5xx): natychmiastowy bounce.
Po co domenie kilka rekordów MX?
Aby poczta dotarła także wtedy, gdy główny serwer jest niedostępny. Nadawca próbuje kolejno serwerów według priorytetu, a przy równych priorytetach wybiera jeden z nich losowo.
Co się stanie, gdy usunę wszystkie rekordy MX?
Nadawca nie znajdzie serwera wskazanego przez MX i spróbuje dostarczyć pocztę na adres z rekordu A domeny. W praktyce wiadomości polecą pod zły adres albo zostaną odrzucone.
Czy priorytet MX 0 jest błędem?
Nie. Zero to prawidłowa, najwyższa preferencja i typowy wybór dostawców takich jak Microsoft 365. Błędem jest jedynie rekord null MX, w którym priorytet 0 łączy się z hostem zapisanym jako kropka.
Jak długo trwa propagacja zmiany rekordu MX?
Zmiana jest widoczna po wygaśnięciu TTL rekordu w serwerach pośredniczących. Do tego czasu narzędzie może pokazywać stary stan, dlatego po edycji sprawdzaj wynik ponownie.
Czy rekord MX może wskazywać bezpośrednio adres IP?
Nie. Rekord MX zawiera nazwę hosta, a nie adres IP. Adres podaje dopiero rekord A lub AAAA tego hosta, dlatego oba wpisy trzeba sprawdzić razem.
Powiązane narzedzia: generator rekordu SPF, sprawdzanie rekordow DNS i tester naglowkow email.