Błąd nieprawidłowej domeny to diagnoza, którą należy zbadać, a nie standardowe wyjaśnienie jednego błędu. Nazwa może być zniekształcona pod względem składniowym, poprawna składniowo, ale nieistniejąca, tymczasowo niemożliwa do rozwiązania, nienadająca się do routingu poczty lub odrzucona przez lokalną politykę tożsamości serwera. Zachowaj całą diagnostykę i pole, do którego się odnosi, przed edycją DNS . Zmiana niewłaściwej nazwy może zakłócić działanie poczty bez usunięcia błędu.
Zidentyfikuj dziedzinę i gramatykę
Referencje: RFC 5321 §2.3.5, RFC 5321 §4.1.2.
Zapisz, czy odrzucona wartość jest uwzględniona EHLO, POCZTA OD, RCPT TO, widoczny nagłówek lub rekord DNS . Konteksty te nie mają wspólnej gramatyki uniwersalnej. W przypadku zwykłych nazw domen SMTP RFC 5321 definiuje reguły dotyczące etykiet i oddzielnie omawia literały adresowe. Podkreślenie w nazwie hosta SMTP nie jest uznawane za ważne tylko dlatego, że podkreślenia są używane w specjalnych nazwach właścicieli DNS takich jak _dmarc lub _domainkey .
RFC 5321 sekcje 2.3.5 i 4.1.2 są odpowiednimi punktami wyjścia dla składni domeny SMTP . Nie używaj uproszczonego wyrażenia regularnego nazwy hosta do sprawdzania poprawności każdego adresu e-mail, adresu międzynarodowego lub rekordu DNS . Urządzenie lokalne celowo obejmuje tylko ograniczony podzbiór nazw liter, cyfr i łączników w formacie ASCII i zgłasza ten limit.
Oddziel rozdzielczość od składni
Referencje: RFC 1035 §4.1.1, RFC 5321 §5, RFC 7505 §3.
Składniowo poprawna nazwa może zwrócić NXDOMAIN , wskazując, że wyszukiwana nazwa nie istnieje w tej odpowiedzi DNS . Tymczasowa awaria rozwiązania, taka jak SERVFAIL nie jest równoznaczna z nieistnieniem i nie powinna być naprawiana poprzez wymyślenie nowego Rekord SPF. Zachowaj zapytanego właściciela, typ, funkcję rozpoznawania nazw, status odpowiedzi, odpowiedzi i sygnaturę czasową. W przypadku autoryzacji sprawdzaj wiarygodne dane i delegowanie w ramach normalnego procesu diagnostycznego organizacji.
W przypadku routingu odbiorców sprawdź MX i obowiązujące reguły zastępcze SMTP , zamiast testować tylko to, czy domena ma witrynę internetową. Domena może być przeznaczona do użytku w Internecie bez akceptowania poczty. MX o wartości null wyraźnie stwierdza, że domena nie przyjmuje poczty; to nie jest brak Rekord MX zastąpić przypadkowo. RFC 7505 definiuje to rozróżnienie. A lub gospodarza Rekord AAAA nie stanowi dowodu na funkcjonowanie usługi pocztowej.
Zachowaj oddzielnie błędy analizatora rekordów
Referencje: RFC 7208 §4.5, RFC 7208 §4.6, RFC 7208 §6.
Rekord uwierzytelniający może mieć nieprawidłowy mechanizm, sprzeczne rekordy lub nieobsługiwaną konstrukcję, dopóki jego nazwa właściciela DNS jest prawidłowa. To są problemy z interpretacją zapisów. Zduplikowany rekord SPF nie jest nieprawidłową etykietą domeny. I odwrotnie, poprawnie wyglądający SPF wartość nie może naprawić nielegalnej nazwy hosta używanej przez klienta. Postępuj zgodnie z parserem i specyfikacją konkretnego rekordu, zamiast używać ogólnego narzędzia do sprawdzania domeny jako ostatecznego autorytetu.
Zachowane urządzenie offline klasyfikuje mail.example .test jako prawidłowy w swojej wąskiej gramatyce nazwy hosta, zła_nazwa.example.test i - bad.example .test jako nieprawidłowe, a missing.example .test jako poprawne składniowo. Oddzielne syntetyczne mapowanie DNS oznacza brakującą nazwę NXDOMAIN , inną nazwę SERVFAIL i przykładową odpowiedź MX jako null MX . Nie jest wykonywane żadne publiczne zapytanie DNS ani korekta produkcyjna. Ćwiczenie pokazuje, dlaczego stany te nie powinny łączyć się w jeden czerwony wskaźnik.
Naprawiaj tylko potwierdzoną przyczynę
Referencje: RFC 5321 §4.2.
Jeśli chodzi o składnię, popraw aplikację generującą lub skonfigurowaną tożsamość. W przypadku istnienia DNS potwierdź własność i zamierzoną usługę przed dodaniem rekordu. W przypadku tymczasowych awarii DNS sprawdź dostępność modułu rozpoznawania nazw lub autorytatywnej. Aby zapoznać się z zasadami SMTP , przeczytaj pełną odpowiedź serwera i dokumentację bieżącego dostawcy. Nie zastępuj prawidłowej tożsamości niepowiązaną domeną, aby wyciszyć błąd.
Po zmianie powtórz tę samą transakcję lub zapytanie i zachowaj oba wyniki. Prawidłowy wynik składni, pomyślna odpowiedź DNS i zaakceptowane polecenie SMTP to oddzielne punkty kontrolne. Zamknij incydent tylko wtedy, gdy pierwotna operacja, która zakończyła się niepowodzeniem, działa zgodnie z zamierzonymi zasadami bezpieczeństwa i routingu.
Porównaj rzeczywiste wyniki analizatora SPF
Referencje: RFC 7208 §4.5, RFC 7208 §4.6, RFC 7208 §6.
Zachowany test analizatora składni z 7 listopada 2026 r. używa pyspf 2.0.14 zamiast oryginalnej białej listy tokenów. Jego hak wyszukiwania DNS dostarcza stałe odpowiedzi TXT dla parser.test i nie wykonuje wyszukiwania sieci. Pozytywny rekord z adnotacjami to v=spf1 ip4:127.0.0.2 -all : wersja wybiera SPF , ip4 autoryzuje kontrolowany adres pochodzenia, a -all zawodzi inne hosty. Parser zwraca hasło dla zapytania z adresu 127.0.0.2 .
Wymiana mechanizmu na fałszywe zwroty permerror ponieważ nieznany mechanizm nie jest ignorowany. Zwrócenie dwóch wybranych rekordów v=spf1 również zwraca permerror , niezależnie od tego, czy autoryzowano hosta. Dodanie future=abc do dodatniego rekordu zwrotów: jest to składniowo poprawny nieznany modyfikator, którego RFC 7208 sekcja 6, wymaga od oceniających ignorowania. Adnotacje do rekordów i dokładne dane wejściowe, oczekiwany wynik, rzeczywisty wynik i wyjaśnienie parsera są zachowywane dla wszystkich czterech przypadków. Zobacz RFC 7208 sekcje 4.5, 4.6 i 6.
Te obserwacje oddzielają nieprawidłowe mechanizmy, wiele wybranych rekordów i nieznanych modyfikatorów, zamiast zwijać je w jedną nieobsługiwaną etykietę. Są to testy parsera z kontrolowanym wejściem DNS , a nie publiczne obserwacje DNS lub wyczerpujący pakiet zgodności z SPF . Nie zmieniają również wyniku składni nazwy hosta: semantyka rekordu i nazwa domeny zawierająca rekord to odrębne warstwy. Oryginalna biała lista jest zachowywana jedynie jako oznaczona ilustracja podzbioru historycznego, a nie jako źródło wniosków opartych na standardach.