Najczęściej popełniane błędy

Moduł 8: Przeprowadzka i porządkowanie domeny · Czas czytania: 13 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili rozpoznać dwanaście najczęściej popełnianych błędów związanych z pocztą e-mail na podstawie ich objawów, wyjaśnić, dlaczego do nich dochodzi, oraz je naprawić.

Kluczowe pojęcia: podwójny rekord SPF, zbyt wiele zapytań SPF, DMARC zbyt wcześnie ustawiony na reject, brak DKIM u usługi wysyłkowej, przekierowanie do Gmaila, catch-all, adres odwiedzającego jako nadawca, serwer wychodzący bez uwierzytelniania, nazwa serwera mail. bez pasującego certyfikatu, pełna skrzynka pocztowa, zapomniany MX przy przeprowadzce, POP3 na wielu urządzeniach

Jak korzystać z tej lekcji

Każdy błąd ma taką samą strukturę: co Państwo widzą (objaw, tak jak zgłasza go klient), dlaczego dochodzi do błędu oraz jak go naprawić. Objawy często wyglądają podobnie ("moja poczta nie dochodzi"), podczas gdy przyczyna jest zupełnie inna. Dlatego przy każdym błędzie podajemy też, jak go potwierdzić: jakiego dowodu szukać, zanim cokolwiek Państwo zmienią. Proszę nie zgadywać, tylko najpierw zmierzyć (lekcja 6.3).

Numery przydadzą się Państwu w zadaniu.

Błędy w DNS

Błąd 1: dwa rekordy SPF.
Widzą Państwo: poczta do Gmaila i Outlook.com nagle trafia do spamu, odkąd podłączyli Państwo nową usługę (Microsoft 365, newsletter, program księgowy). W nagłówkach widnieje spf=permerror.
Dlaczego: usługa poleciła "dodaj ten rekord SPF", a teraz istnieją dwa rekordy TXT zaczynające się od v=spf1. Zgodnie z RFC 7208 to błąd trwały: SPF w ogóle przestaje się liczyć.
Potwierdzenie: proszę sprawdzić rekordy TXT domeny i policzyć rekordy v=spf1.
Rozwiązanie: proszę połączyć wszystko w jeden rekord (lekcja 4.2).

Błąd 2: więcej niż dziesięć zapytań SPF.
Widzą Państwo: to samo, spf=permerror, ale jest tylko jeden rekord. Często pojawia się po dodaniu kolejnego include.
Dlaczego: każdy include, a, mx, exists i redirect kosztuje jedno zapytanie DNS, również wewnątrz innych include'ów. Powyżej dziesięciu SPF jest nieważny.
Potwierdzenie: proszę zlecić rekurencyjne policzenie zapytań SPF (zadanie Z4.2).
Rozwiązanie: proszę usunąć usługi, z których już Państwo nie korzystają, zastąpić a i mx przez ip4/ip6, jeśli są stałe, albo zlecić wysyłkę przez własną subdomenę bounce (lekcja 7.1).

Błąd 3: DMARC od razu ustawiony na p=reject.
Widzą Państwo: odkąd ustawiono rekord DMARC, faktury z programu księgowego lub poczta ze strony internetowej przestały docierać. Odbiorcy zwracają 550 5.7.1 z odniesieniem do DMARC.
Dlaczego: nie wszyscy nadawcy zostali uwzględnieni. To, co nie przechodzi przez dopasowany SPF lub DKIM, jest teraz odrzucane.
Potwierdzenie: rekord DMARC i raporty (lekcja 4.5): które źródła zawodzą?
Rozwiązanie: proszę wrócić do p=none z adresem do raportów, naprawić wszystkich nadawców, a następnie krok po kroku przejść do quarantine i reject (lekcja 4.4). Taka jest też zalecana ścieżka w tym kursie.

Błąd 4: DKIM nieskonfigurowany u usługi wysyłkowej.
Widzą Państwo: newslettery coraz częściej nie trafiają do skrzynki odbiorczej u coraz większej liczby odbiorców. W nagłówkach: dkim=pass header.d= domena usługi, dmarc=fail.
Dlaczego: usługa podpisuje własną domeną, więc DMARC nie może zostać zaliczony przez DKIM, a SPF również nie jest dopasowany.
Potwierdzenie: nagłówki testowego newslettera (zadanie Z7.1).
Rozwiązanie: proszę uwierzytelnić domenę u usługi (DKIM przez CNAME, lekcja 7.1).

Błędy związane z przekierowaniem i adresami

Błąd 5: przekierowanie wszystkiego do Gmaila.
Widzą Państwo: poczta od niektórych nadawców nie dociera na adres Gmail, na który przekierowują Państwo pocztę firmową, albo trafia do spamu. Czasami nadawcy otrzymują zwrotkę (bounce) z Gmaila.
Dlaczego: przy przekierowaniu poczta trafia do Gmaila z Państwa serwera, który nie znajduje się w SPF oryginalnego nadawcy. Bez DKIM lub przy nadawcy z p=reject DMARC zawodzi. Dodatkowo przekierowany spam wygląda z perspektywy Gmaila jak spam, który wysyłają Państwo, co szkodzi Państwa reputacji.
Potwierdzenie: zwrotka (bounce) lub nagłówki w Gmailu (spf=fail albo softfail ze wskazaniem Państwa serwera jako źródła).
Rozwiązanie: zamiast przekierowania proszę dodać skrzynkę pocztową w aplikacji Gmail na telefonie przez IMAP (lekcja 2.4 i 3.3).

Błąd 6: catch-all.
Widzą Państwo: dużo spamu na adresy, które nigdy nie istniały (xyz123@example.com), oraz pełną skrzynkę pocztową.
Dlaczego: catch-all przyjmuje pocztę na każdy możliwy adres. Spamerzy próbują losowych adresów i wszystkie one trafiają na skrzynkę. Jeśli catch-all jest dodatkowo przekierowywany na zewnątrz, powstaje błąd 5 w wersji masowej.
Potwierdzenie: proszę sprawdzić w skrzynce, na jakie adresy odbiorców trafiał spam.
Rozwiązanie: proszę wyłączyć catch-all i dla każdego faktycznie używanego adresu utworzyć alias lub skrzynkę pocztową (lekcja 3.3).

Błąd 7: adres odwiedzającego jako nadawca w formularzu.
Widzą Państwo: wiadomości z formularza kontaktowego czasem docierają, a czasem nie, zwłaszcza od odwiedzających z adresem u dużego dostawcy.
Dlaczego: Państwa strona internetowa wysyła wiadomość "w imieniu" domeny odwiedzającego. Jeśli ta domena ma p=reject lub p=quarantine, odbiorca odrzuca lub filtruje wiadomość (lekcja 7.3).
Potwierdzenie: proszę sprawdzić, jakiego pola From używa formularz.
Rozwiązanie: własny adres w polu From, adres odwiedzającego w Reply-To.

Błędy przy konfiguracji

Błąd 8: serwer wychodzący bez uwierzytelniania.
Widzą Państwo: odbieranie działa, wysyłanie nie. Komunikat typu "relay access denied", "authentication required" lub 550 5.7.1. Na iPhonie często: pola przy serwerze wychodzącym pozostawione puste ("opcjonalne").
Dlaczego: serwer wychodzący przekazuje pocztę dalej tylko dla tych, którzy się zalogują. W przeciwnym razie każdy mógłby go wykorzystać jako działo spamowe.
Potwierdzenie: ustawienia serwera wychodzącego w programie pocztowym.
Rozwiązanie: proszę włączyć uwierzytelnianie, podając pełny adres e-mail i hasło, port 587 z STARTTLS lub 465 z SSL/TLS (lekcja 1.4 i 2.3).

Błąd 9: mail.<domena> jako nazwa serwera bez pasującego certyfikatu.
Widzą Państwo: komunikat o nieprawidłowym certyfikacie lub "nie można zweryfikować tożsamości serwera", albo połączenie w ogóle się nie udaje.
Dlaczego: program sprawdza, czy nazwa serwera znajduje się w certyfikacie. mail.example.com może wskazywać na serwer, ale nie figurować w certyfikacie. Albo nazwa po przeprowadzce wciąż wskazuje na starego dostawcę.
Potwierdzenie: proszę zlecić sprawdzenie portów pocztowych wraz z nazwą serwera (zadanie Z2.1 i Z8.4).
Rozwiązanie: proszę używać nazwy serwera podanej przez dostawcę i nigdy nie klikać bezrefleksyjnie "mimo to kontynuuj" (lekcja 2.1).

Błąd 10: pełna skrzynka pocztowa.
Widzą Państwo: nadawcy otrzymują zwrotkę (bounce) z kodem 452 4.2.2 lub 552 5.2.2 (skrzynka pełna). Państwo niczego nie zauważają albo jedynie to, że nowa poczta przestała przychodzić.
Dlaczego: skrzynka osiągnęła swój limit (quotę). Często z powodu wieloletnich załączników albo folderów Wysłane i Kosz, które nigdy nie są opróżniane.
Potwierdzenie: wykorzystanie skrzynki w panelu lub w poczcie internetowej (webmail).
Rozwiązanie: uporządkowanie, archiwizacja albo zwiększenie limitu (lekcja 3.2).

Błędy przy przeprowadzce

Błąd 11: zapomniany MX przy przeprowadzce.
Widzą Państwo: po przeniesieniu strony internetowej lub domeny poczta przestaje docierać, albo trafia tam, gdzie nikt nie zagląda. Lub odwrotnie: przenieśli Państwo pocztę do nowego dostawcy, ale MX nadal wskazuje na starego.
Dlaczego: przy zmianie serwerów nazw cała strefa przenosi się razem z domeną. Jeśli rekordy MX dostawcy poczty nie znajdują się w nowej strefie, Państwa poczta kieruje się do nowego serwera WWW. Albo MX nigdy nie został zmieniony.
Potwierdzenie: zapytanie o MX u autorytatywnego serwera nazw (zadanie Z8.2).
Rozwiązanie: proszę ustawić prawidłowe rekordy MX w strefie, która jest faktycznie aktywna, a następnie jeszcze raz skopiować pocztę (lekcja 8.2).

Błąd 12: POP3 na wielu urządzeniach.
Widzą Państwo: poczta jest na laptopie, ale nie na telefonie, albo odwrotnie. Po wymianie laptopa znika wieloletnia poczta.
Dlaczego: POP3 pobiera pocztę z serwera na jedno urządzenie i często ją tam usuwa (lekcja 1.3).
Potwierdzenie: typ konta w programie pocztowym.
Rozwiązanie: przejście na IMAP; pocztę znajdującą się tylko lokalnie proszę najpierw przenieść do skrzynki IMAP.

Co łączy te błędy

Proszę jeszcze raz spojrzeć na tę listę. Niemal każdy błąd powstaje, gdy ktoś zastosował się do pojedynczej instrukcji ("dodaj ten rekord", "włącz przekierowanie"), nie widząc całości. Myśl przewodnia tego kursu:

• proszę wiedzieć, kto wysyła wiadomości w imieniu Państwa domeny (inwentaryzacja, lekcja 4.2 i 8.1);
• proszę zmieniać jedną rzecz naraz i następnie to sprawdzać;
• proszę czytać dowody: zwrotkę (bounce) (lekcja 6.1), nagłówki (lekcja 1.5), raport DMARC (lekcja 4.5) oraz DNS na autorytatywnym serwerze.

Podsumowanie

• Błędy w DNS: dwa rekordy SPF, zbyt wiele zapytań, DMARC zbyt wcześnie ustawiony na reject, brak DKIM u usługi wysyłkowej.
• Błędy związane z adresami: przekierowanie do Gmaila, catch-all, adres odwiedzającego jako From.
• Błędy konfiguracyjne: brak uwierzytelniania wychodzącego, nazwa serwera niewystępująca w certyfikacie, pełna skrzynka pocztowa.
• Błędy przy przeprowadzce: zapomniany MX, POP3 na wielu urządzeniach.
• Przyczynę zawsze należy potwierdzić dowodem, zanim cokolwiek Państwo zmienią.

Quiz

Zadanie

Zadanie Z8.3: Który to błąd? Otrzymają Państwo osiem krótkich przypadków, każdy z opisem objawu i fragmentem dowodu (nagłówek, zwrotka (bounce), odpowiedź DNS lub ustawienie). Proszę wybrać dla każdego przypadku numer błędu (od 1 do 12). Program sprawdza odpowiedzi według stałego klucza i przy błędnej odpowiedzi pokazuje, jaki dowód Państwo pominęli.

Dalsza lektura

Kroki opisane w tych artykułach dotyczą paneli WebOké; u innych dostawców działa to w podobny sposób.

• Instrukcja DirectAdmin 18.9: Nie otrzymuję już wiadomości e-mail
• Instrukcja DirectAdmin 18.10: Nie mogę wysłać wiadomości e-mail
• Nie otrzymuję już żadnych wiadomości e-mail: jak znaleźć przyczynę
• Nie mogę wysyłać wiadomości e-mail (odbieranie działa poprawnie)
• Przekierowywanie wiadomości e-mail na inny adres (forwardery, catch-all odradzamy)
• Bezpłatny kurs DNS 8.4: Najczęściej popełniane błędy