Често срещани грешки

Модул 8: Преместване и подреждане на Вашия домейн · Време за четене: 13 минути

Учебна цел: След този урок ще можете да разпознавате дванайсетте най-често срещани грешки с имейл по техните симптоми, да обяснявате защо се случват и да ги отстранявате.

Основни понятия: дублиран SPF запис, твърде много SPF справки, DMARC твърде рано на reject, DKIM не е активиран при услуга за изпращане, пренасочване към Gmail, catch all, посетител като подател, изходящ сървър без удостоверяване, mail. име на сървър без подходящ сертификат, пълна пощенска кутия, забравен MX при преместване, POP3 на няколко устройства

Как да използвате този урок

Всяка грешка има една и съща структура: какво виждате (симптомът, както клиентът го съобщава), защо се получава грешка и как я отстранявате. Често симптомите си приличат ("моята поща не пристига"), докато причината е съвсем различна. Затова при всяка грешка е посочено и как да я потвърдите: какво доказателство търсите, преди да промените нещо. Не гадайте, първо измервайте (урок 6.3).

Номерата се използват в задачата.

Грешки в DNS

Грешка 1: два SPF записа.
Виждате: поща до Gmail и Outlook.com внезапно започва да попада в спам, откакто сте свързали нова услуга (Microsoft 365, бюлетин, счетоводен пакет). В кополовките стои spf=permerror.
Защо: услугата е казала "добавете този SPF запис" и сега има два TXT записа, които започват с v=spf1. Според RFC 7208 това е постоянна грешка: SPF вече изобщо не се брои.
Потвърдете: проверете TXT записите на Вашия домейн и пребройте записите v=spf1.
Решение: обединете всичко в един запис (урок 4.2).

Грешка 2: повече от десет SPF справки.
Виждате: същото, spf=permerror, но има само един запис. Често след добавяне на поредния include.
Защо: всеки include, a, mx, exists и redirect струва една DNS справка, включително тези вътре в includes. Над десет SPF става невалиден.
Потвърдете: направете рекурсивно преброяване на SPF (задача Z4.2).
Решение: премахнете услуги, които вече не използвате, заменете a и mx с ip4/ip6, ако адресите са постоянни, или оставете услуга да изпраща през собствен bounce поддомейн (урок 7.1).

Грешка 3: DMARC веднага на p=reject.
Виждате: откакто е зададен DMARC запис, фактури от счетоводния пакет или поща от уебсайта вече не пристигат. Получателите връщат 550 5.7.1 с препратка към DMARC.
Защо: не всички податели са били взети предвид. Всичко, което не минава през изравнени SPF или DKIM, сега се отхвърля.
Потвърдете: DMARC записа и отчетите (урок 4.5): кои източници се провалят?
Решение: върнете се към p=none с адрес за отчети, оправете всички податели, после стъпка по стъпка преминете към quarantine и reject (урок 4.4). Това е и препоръчителният подход в тази курс.

Грешка 4: DKIM не е настроен при услугата за изпращане.
Виждате: бюлетините все по-рядко стигат до входящата кутия при все повече получатели. В кополовките: dkim=pass header.d= домейна на услугата, dmarc=fail.
Защо: услугата подписва със собствения си домейн, затова DMARC не може да премине чрез DKIM, а SPF също не е изравнен.
Потвърдете: кополовки на тестов бюлетин (задача Z7.1).
Решение: удостоверете Вашия домейн при услугата (DKIM чрез CNAME, урок 7.1).

Грешки при пренасочване и адреси

Грешка 5: всичко се пренасочва към Gmail.
Виждате: поща от някои податели не пристига на Gmail адреса, към който пренасочвате служебната си поща, или попада в спам. Понякога подателите получават bounce от Gmail.
Защо: при пренасочване пощата пристига в Gmail от Вашия сървър, който не е в SPF записа на първоначалния подател. Без DKIM или при подател с p=reject, DMARC се проваля. Освен това за Gmail пренасочен спам изглежда като спам, който Вие изпращате, което вреди на Вашата репутация.
Потвърдете: bounce съобщението или кополовките в Gmail (spf=fail или softfail с Вашия сървър като източник).
Решение: не пренасочвайте, а добавете пощенската кутия в приложението Gmail на телефона си чрез IMAP (урок 2.4 и 3.3).

Грешка 6: catch all.
Виждате: много спам на адреси, които никога не са съществували (xyz123@example.com), и пълна пощенска кутия.
Защо: catch all приема поща за всеки възможен адрес. Спамерите изпробват произволни адреси и всички те пристигат. Ако освен това пренасочвате catch all към друго място, получавате грешка 5 в голям мащаб.
Потвърдете: проверете в пощенската кутия към кои адреси на получателя е отивал спамът.
Решение: изключете catch all и създайте псевдоним или пощенска кутия за всеки реално използван адрес (урок 3.3).

Грешка 7: адресът на посетителя като подател във формуляр.
Виждате: съобщенията през контактната форма понякога пристигат, понякога не, особено от посетители с адрес при голям доставчик.
Защо: Вашият уебсайт изпраща "от името на" домейна на посетителя. Ако този домейн има p=reject или p=quarantine, получателят отхвърля или филтрира пощата (урок 7.3).
Потвърдете: проверете какъв From използва формулярът.
Решение: собствен адрес в From, посетителят в Reply-To.

Грешки при настройване

Грешка 8: изходящ сървър без удостоверяване.
Виждате: получаването работи, изпращането не. Съобщение от рода на "relay access denied", "authentication required" или 550 5.7.1. При iPhone често: полетата за изходящия сървър оставени празни ("по избор").
Защо: изходящ сървър препраща поща само за този, който влезе с логин. Иначе всеки би могъл да го използва като спам оръдие.
Потвърдете: настройките на изходящия сървър в пощенската програма.
Решение: включете удостоверяване с пълния имейл адрес и парола, порт 587 със STARTTLS или 465 със SSL/TLS (урок 1.4 и 2.3).

Грешка 9: mail.<домейн> като име на сървъра без подходящ сертификат.
Виждате: съобщение за невалиден сертификат или "не може да се провери самоличността на сървъра", или връзката изобщо не се осъществява.
Защо: програмата проверява дали името на сървъра присъства в сертификата. mail.example.com може да сочи към сървъра, но да не е посочено в сертификата. Или името все още сочи към стария доставчик след преместване.
Потвърдете: проверете пощенските портове с името на сървъра (задача Z2.1 и Z8.4).
Решение: използвайте името на сървъра, посочено от доставчика, и никога не натискайте просто "продължи въпреки това" (урок 2.1).

Грешка 10: пълна пощенска кутия.
Виждате: подателите получават bounce с 452 4.2.2 или 552 5.2.2 (пощенската кутия е пълна). Вие не забелязвате нищо, или само че не пристига нова поща.
Защо: пощенската кутия е достигнала квотата си. Често заради годините приложени файлове, или заради папки Sent и Trash, които никога не се изпразват.
Потвърдете: използването на пощенската кутия в панела или уеб пощата.
Решение: разчистете, архивирайте или увеличете квотата (урок 3.2).

Грешки при преместване

Грешка 11: забравен MX при преместване.
Виждате: след преместване на уебсайта или домейна вече не пристига поща, или пристига на място, което никой не проверява. Или обратното: преместили сте пощата при нов доставчик, но MX все още сочи към стария.
Защо: при смяна на nameserver се мести цялата зона. Ако MX записите на пощенския доставчик не присъстват в новата зона, пощата Ви сочи към новия уебсървър. Или MX никога не е бил променен.
Потвърдете: проверете MX при упълномощения nameserver (задача Z8.2).
Решение: задайте правилните MX записи в зоната, която реално е активна, а след това копирайте пощата още веднъж (урок 8.2).

Грешка 12: POP3 на няколко устройства.
Виждате: поща има на лаптопа, но не и на телефона, или обратното. След смяна на лаптопа години поща липсват.
Защо: POP3 изтегля пощата от сървъра на едно устройство и често я изтрива там (урок 1.3).
Потвърдете: типа акаунт в пощенската програма.
Решение: преминете към IMAP; първо преместете поща, която е само локална, в IMAP пощенската кутия.

Какво общо имат грешките

Прегледайте списъка още веднъж. Почти всяка грешка възниква, защото някой е следвал отделна инструкция ("добавете този запис", "включете пренасочване"), без да вижда цялата картина. Общата нишка на този курс:

• знайте кой изпраща поща от името на Вашия домейн (инвентаризация, урок 4.2 и 8.1);
• променяйте едно нещо наведнъж и проверявайте след това;
• четете доказателството: bounce съобщението (урок 6.1), кополовките (урок 1.5), DMARC отчета (урок 4.5) и DNS при упълномощения сървър.

Обобщение

• DNS грешки: два SPF записа, твърде много справки, DMARC твърде рано на reject, DKIM не е активиран при услуга за изпращане.
• Адресни грешки: пренасочване към Gmail, catch all, адресът на посетителя като From.
• Грешки при настройване: липса на удостоверяване при изходящата поща, име на сървър, което не присъства в сертификата, пълна пощенска кутия.
• Грешки при преместване: забравен MX, POP3 на няколко устройства.
• Винаги потвърждавайте причината с доказателство, преди да промените нещо.

Тест

Задача

Задача Z8.3: Коя грешка е? Получавате осем кратки казуса, всеки със симптом и малко доказателство (кополовка, bounce съобщение, DNS отговор или настройка). За всеки казус изберете номера на грешката (от 1 до 12). Програмата проверява по фиксиран ключ и при грешен отговор показва кое доказателство сте пропуснали.

За допълнително четене

Стъпките в тези статии важат за панелите на WebOké; при други доставчици процесът е сходен.

• Ръководство за DirectAdmin 18.9: Вече не получавам имейли
• Ръководство за DirectAdmin 18.10: Не мога да изпращам имейли
• Вече не получавате имейли: ето как да откриете причината
• Не мога да изпращам имейли (получаването работи)
• Пренасочване на имейл към друг адрес (forwarders, catch-all не се препоръчва)
• Безплатен курс по DNS 8.4: Често срещани грешки