Как мы восстановили работу заблокированной корпоративной почты

В один день у клиента полностью перестала работать корпоративная почта на mail.ru. Письма не доходили до получателей, а в ответ клиент получал автоматическое уведомление «Ваше письмо не доставлено. Mail failure». 

Как появилась проблема

По нашей просьбе клиент прислал изображение с ошибкой. Оно выглядело следующим образом:

Клиент первым проявил инициативу и написал в техподдержку mail.ru. Из поддержки ему прислали следующий ответ:

Здравствуйте.
Пожалуйста, поясните, что за письма рассылаются с domen.ru? Какова их тематика? Каким образом вы получаете адреса, на которые отправляете письма, и как/где заручаетесь согласием на них? Фиксируем рассылку писем с domen.ru с рекламой банковских предложений. Это ваши письма?

Если так - уточните, кому и на каком основании они отправляются? Если нет - примите меры по блокировке спама с вашего домена. Как минимум для него отсутствует политика DMARC, защищающая домен от рассылки поддельных писем с него. Рекомендуем использовать политику p=reject, чтобы чётко дать понять почтовым провайдерам, что подобные подставные письма стоит блокировать.
Более подробно о политике DMARC можно прочесть здесь:
habrahabr.ru/company/mailru/blog/
Отметим, что для корректной работы DMARC письма должны иметь SPF и DKIM, поэтому рекомендуем убедиться в их наличии и корректной работе (прохождение их на валидность во всех письмах, отправляемых с домена).

Клиенту удалось выяснить, что в нерабочее время (воскресенье) с почты privet@domen.ru отправлялись рассылки рекламного характера, к которым клиент не имел никакого отношения. На самом деле с почты privet@domen.ru  должны отправляться рассылки статей из сервиса getresponse.ru. Они шли раз в неделю по запланированному графику. Мы авторизовались в сервисе рассылок, посмотрели на статьи, которые рассылал клиент, и не увидели ничего подозрительного. За исключением одного момента:

На скриншоте выделено число доставленных рассылок по статье. Видно, у что первых трех статей (самых свежих) количество доставленных рассылок практически в 2 раза меньше. То есть почти половина подписчиков не получила рассылку по статье.

Мы попробовали оставить свою gmail-почту в форме подписки статьи и стали дожидаться уведомления. Оно пришло. Было проделано то же самое с yandex-почтой — уведомление тоже пришло. А вот когда оставили mail-почту, уведомление НЕ пришло. Из чего мы сделали вывод, что подписчики с mail-почтой никаких рассылок не получают.

В сухом остатке у нас оказались две проблемы:

1. У клиента не работает корпоративная почта на mail.ru. Любая попытка отправить письмо с корпоративной почты (у любого сотрудника) заканчивалась ошибкой в виде автоматического уведомления от mail.ru.
2. Почти половина подписчиков в getresponse.ru не получают рассылки, поскольку их почта работает на mail.ru

С этой информацией на руках мы двинулись дальше.

Решение проблемы

Для начала решили проверить наличие SPF-записи у домена клиента. 

SPF позволяет владельцу домена указать в TXT-записи домена строку, указывающую список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене.

В результате были обнаружены две SPF-записи:

• domen.ru. 600 IN TXT "v=spf1 redirect= nicmail.ru "
• domen.ru. 600 IN TXT "v=spf1 redirect=_ spf.mail.ru "

По сути, в соответствии с документацией mail.ru, они были прописаны правильно. Но было непонятно, для чего в записях прописывался redirect.

Поскольку у нас рассылки идут с Getresponce, то SPF-запись нужна и для него, а изначально она отсутствовала. Мы решили переписать SPF записи на стандартный вид и заодно прописать для Getresponce:

Все записи прописывались в настройках DNS-хостинга (в данном случае nic.ru).

Внимание! При внесении изменений в настройки домена не забудьте выгрузить зону.

После выгрузки зоны мы подождали 15 минут и проверили результат в postmaster.mail.ru/security. Получили следующий результат:

SPF-запись обновлена и мы наивно подумали, что этого будет достаточно для восстановления работы почты и рассылок, но техподдержка mail.ru настаивала на настройке DKIM (электронная подпись) и DMARC (политика).

DKIM обеспечивает проверку авторства сообщения или принадлежности его отправителя определенному домену с помощью технологий цифровой подписи.

DMARC задает политику как проверять приходящую почту в определенном домене и что делать если письма не проходят аутентификацию SPF или DKIM

Для этого поставили задачу разработчику на составление соответствующих записей и внесли DKIM-запись и DMARC-запись в настройки DNS-хостинга (nic.ru).

После внесения записей снова проверили результаты в postmaster.mail.ru/security/:

Потом обратились в техподдержку mail.ru и спустя сутки получили положительный ответ о разблокировке почты.

Корпоративная почта клиента начала работать штатно. Рассылки с Getresponce стали доходить до всех подписчиков. Обе проблемы оказались решены.