Ежемесячная проверка доставляемости почты с вашего сервера

MAATRIX

Сервер месяцами исправно отправляет письма: код подтверждения, сброс пароля, уведомление о заказе — SMTP отвечает 250 OK, в логах ни одной ошибки, всё выглядит рабочим. А потом приходит тикет от пользователя: «не пришло письмо с кодом, проверил и спам тоже». Или второй, третий — и только тогда выясняется, что часть писем неделями тихо оседает в папке «Спам» у Gmail или Mail.ru, а сервер об этом ничего не знает и знать не может. Репутация IP-адреса и домена отправки меняется постепенно и без единого сигнала со стороны вашей инфраструктуры — поэтому проверять доставляемость нужно регулярно, а не только когда кто-то уже пожаловался.

Почему доставляемость портится незаметно

Ключевая проблема в том, что успешная отправка и успешная доставка — это два разных события, и сервер отправителя видит только первое. Postfix или другой MTA получает от принимающего сервера код 250 и считает свою часть работы выполненной. Всё, что происходит дальше — попадёт ли письмо во «Входящие», в «Спам» или будет тихо отброшено после приёма (silent drop, без bounce) — решает алгоритм на стороне получателя, и это решение нигде не логируется на вашей стороне.

Репутация складывается из вещей, которые меняются без вашего участия:

• Поведение получателей. Несколько адресатов отметили ваше письмо как спам (даже по ошибке) — это сигнал для алгоритма, и он накапливается.
• Возраст и история IP. Если сервер арендован недавно, у IP-адреса может быть чужая история — предыдущий арендатор мог рассылать спам, и часть репутации наследуется.
• Изменение алгоритмов получателя. Gmail, Yandex и Mail.ru регулярно донастраивают спам-фильтры. То, что проходило полгода назад, может начать помечаться иначе без единого изменения в вашей конфигурации.
• Дрейф конфигурации. SPF-запись, в которую полгода назад добавили сервис и забыли про неё, DKIM-ключ, не обновлённый после миграции — сами записи не «ломаются», они просто перестают отражать реальность.

Ни одно из этих изменений не даёт ошибки в логе Postfix. Первый видимый симптом — жалоба пользователя, а к этому моменту проблема обычно копится уже недели. Ежемесячная проверка — способ увидеть деградацию раньше, чем её увидят ваши пользователи.

Тестовая отправка: куда слать и что проверять

Самая практичная часть проверки — не анализ конфигов, а живой тест: отправить письмо и посмотреть, куда оно реально попало. Раз в месяц отправляйте тестовое письмо (лучше — реальный шаблон из вашей транзакционной почты, а не абстрактный «тест») на несколько ящиков, которые вы контролируете, на основных сервисах, которыми пользуются ваши получатели: Gmail, Yandex, Mail.ru, Outlook/Hotmail.

Отправить письмо с сервера напрямую через SMTP удобно через swaks:

swaks --to your-test@gmail.com \
  --from noreply@yourdomain.com \
  --server 127.0.0.1 \
  --header "Subject: Проверка доставляемости — тест" \
  --body "Тестовое письмо для ежемесячной проверки доставляемости."

После отправки проверяйте не только факт «дошло / не дошло», но и папку: во «Входящих» без пометок, во «Входящих» с предупреждением («Похоже на спам») или в «Спаме» — это разные степени проблемы, и различать их важно.

Отдельно откройте письмо в почтовом клиенте получателя и посмотрите на технические заголовки — в Gmail это пункт меню «Показать оригинал». Интересует блок Authentication-Results:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=default;
       spf=pass (google.com: domain of noreply@yourdomain.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=yourdomain.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=yourdomain.com

Все три строки должны читаться как pass. neutral, softfail или fail в любой из них — повод разбираться, даже если письмо в итоге дошло: сегодня фильтр пропустил его с предупреждением, завтра может не пропустить вовсе.

Для более формализованной проверки удобны сторонние сервисы вроде mail-tester.com — отправляете письмо на выданный ими адрес и получаете отчёт по SPF/DKIM/DMARC, заголовкам и присутствию в чёрных списках в одном месте. Если основной поток получателей — Gmail и объём писем заметный, отдельно стоит подключить Google Postmaster Tools: он показывает репутацию домена и IP с точки зрения Google, включая долю жалоб на спам — данные, которые иначе не получить. Если Gmail отклоняет письма даже после проверки заголовков — отдельно разобрано в статье почему Gmail не принимает письма.

SPF, DKIM и DMARC: проверка не факта наличия, а актуальности

Если SPF, DKIM и DMARC настроены — это даёт базовую защиту, но не гарантирует, что записи остаются корректными спустя месяцы. Первоначальная настройка этих трёх стандартов подробно разобрана в статье как настроить SPF, DKIM и DMARC на VPS — здесь речь именно про ежемесячную проверку того, что уже настроено, не разъехалось с реальностью.

SPF. Самая частая проблема — запись, которая перестала отражать реальный список отправителей. Добавили новый транзакционный сервис (например, стороннюю платформу для писем или CRM) и забыли внести её в SPF, либо, наоборот, вывели из эксплуатации старый сервер, а его IP так и остался в записи. Проверка:

dig +short TXT yourdomain.com | grep spf1

Отдельно стоит считать количество DNS-lookup'ов, которое порождает запись — у SPF жёсткий лимит в 10 lookup'ов (include, a, mx, exists, redirect), после которого запись превращается в permerror, и получатели начинают игнорировать её целиком, как будто SPF не настроен вовсе. Если запись обросла несколькими include от разных сервисов — легко незаметно упереться в этот лимит, особенно когда include ссылаются друг на друга. Проще раз в месяц прогнать запись через публичный SPF-валидатор, чем разбирать вложенные include вручную.

DKIM. Проверка на актуальность здесь — сверить, что ключ в DNS реально совпадает с приватным ключом на сервере:

dig +short TXT default._domainkey.yourdomain.com

Расхождение возникает чаще, чем кажется: после восстановления из старого бэкапа, после миграции почты на новый хост с перегенерацией ключей, или если селектор поменяли в конфиге MTA, но забыли обновить в DNS. Результат — DKIM молча перестаёт проходить: подпись формируется исправно, но получатель не может её проверить. Разбор похожей ситуации — в статье DKIM подписывал ключом, которого нет в DNS.

DMARC. Здесь ежемесячная проверка — это не столько DNS-запись (она меняется редко), сколько чтение агрегированных отчётов (RUA), которые приходят на адрес, указанный в rua=. Раз в месяц стоит открыть накопившиеся XML и посмотреть, все ли реальные источники отправки от имени домена проходят выравнивание SPF/DKIM. Разбор того, как читать эти XML и что в них искать — в статье отчёты DMARC: что делать с этими XML. Отдельно стоит зафиксировать текущую политику (p=none/quarantine/reject) и не давать ей «протухнуть» на none годами — запись без реального применения не защищает домен от подделки, а только собирает отчёты, которые никто не читает.

Мониторинг репутации IP и домена

Присутствие в чёрных списках (RBL) — самая грубая, но и самая быстрая проверка: письмо может формально проходить SPF/DKIM/DMARC и всё равно отклоняться, если IP отправителя числится в одном из популярных списков. Проверить конкретный список вручную можно через DNS-запрос к зеркалу Spamhaus (IP указывается в обратном порядке октетов):

dig +short 10.113.0.203.zen.spamhaus.org

Пустой ответ — IP чист для этого списка. Ответ вида 127.0.0.x — IP в списке, код в последнем октете обычно указывает причину (открытый релей, спам-источник, динамический пул — расшифровка есть на сайте конкретного списка). Проверять вручную десяток списков неудобно — быстрее раз в месяц прогнать IP и домен через агрегатор вроде mxtoolbox.com, который проверяет сразу по нескольким RBL одним запросом.

Второй источник данных, который стоит просматривать ежемесячно — сам почтовый лог сервера на предмет отказов принимающей стороны с формулировками про репутацию:

grep -iE "blocked|blacklist|reputation|spam" /var/log/mail.log | tail -50

Принимающие серверы часто прямо пишут причину отказа в SMTP-ответе (550 5.7.1 ... reputation ... или ссылку на конкретный список) — это быстрее, чем гадать, и не требует сторонних сервисов.

Отдельно стоит понимать, что репутация бывает и на уровне домена, а не только IP — особенно при выравнивании DMARC (aligned). Если тот же домен используется и для транзакционной почты с сервера, и для маркетинговых рассылок через стороннюю платформу — плохая гигиена списков в маркетинговом канале может потянуть вниз репутацию домена в целом, даже если ваш сервер настроен идеально. Это стоит держать в голове при нескольких каналах отправки от одного домена.

Чек-лист на 30 минут и как встроить его в регламент

Практика показывает, что проверка доставляемости работает только тогда, когда у неё есть фиксированное место в календаре, а не «сделаю, когда вспомню». Разумно привязать её к дню месяца, а не к дню недели — например, первое число или последняя пятница месяца, если у вас уже есть еженедельный регламент обслуживания (о нём — в статье еженедельный регламент обслуживания сервера за 40 минут), удобно раз в месяц просто добавить к нему этот блок.

Минимальный набор шагов на 25-30 минут:

1. Отправить тестовое письмо на Gmail, Yandex, Mail.ru — проверить папку и заголовки Authentication-Results (10 минут).
2. Прогнать домен через mail-tester.com или аналогичный сервис — сохранить отчёт (5 минут).
3. Проверить SPF на актуальность списка отправителей и на лимит lookup'ов (5 минут).
4. Свериться, что DKIM-запись в DNS совпадает с ключом на сервере (3 минуты).
5. Открыть накопившиеся DMARC-отчёты за месяц, посмотреть на новые/неавторизованные источники (5 минут).
6. Проверить IP по агрегатору чёрных списков (2 минуты).

Смысл появляется не от разового прогона, а от накопленной истории — заведите простую таблицу и заполняйте её каждый месяц одной строкой:

Числа в таблице — иллюстративный пример, у вас будут свои. Ценность именно в тренде: если оценка mail-tester стабильно падает три месяца подряд при неизменной конфигурации — это сигнал разбираться раньше, чем оценка упадёт настолько, что письма реально начнут теряться, а не после того, как накопится десяток жалоб пользователей.

Частые грабли, которые всплывают на такой проверке

SPF-запись перезаписана вместо дополнения. Классическая ошибка — при подключении нового сервиса рассылок в его панели создаётся новая TXT-запись v=spf1 ..., которая заменяет существующую в DNS, а не дополняет её. В результате все прежние легитимные отправители домена разом перестают проходить SPF. Обнаруживается это обычно не сразу, а на ежемесячной проверке — первые дни часть провайдеров ещё «прощает» несовпадение, полагаясь на историю домена, а затем отказы нарастают. Похожий случай с ценой в неделю простоя рассылки разобран в статье одна опечатка в SPF положила рассылку на неделю.

DMARC на p=none годами. Политика none полезна на старте — она включает сбор отчётов без риска блокировки легитимной почты. Но если оставить её так навсегда, домен остаётся без реальной защиты от подделки (спуфинга) — отчёты копятся, а p=none означает получателю «делай со спорными письмами что хочешь по умолчанию». Двигаться к quarantine, а затем к reject стоит постепенно и только после того, как отчёты за несколько месяцев подтвердили, что все легитимные источники проходят выравнивание — иначе есть риск случайно отрезать от домена легитимный сервис, о котором забыли.

Отсутствующая или неверная PTR-запись (обратный DNS). После миграции на новый сервер или смены IP-адреса легко забыть попросить провайдера настроить обратную запись (rDNS) для нового IP на имя, соответствующее домену отправки. Многие принимающие серверы требуют совпадения PTR с HELO/EHLO именем как минимальное условие приёма почты — без этого письма могут отклоняться ещё на этапе SMTP-диалога, до всякой проверки SPF/DKIM.

Истёкший TLS-сертификат на порту отправки (submission/STARTTLS). Если сертификат для Postfix/Dovecot истёк, а автопродление (certbot и подобные) незаметно перестало срабатывать, часть принимающих серверов начинает либо принудительно понижать соединение до незашифрованного (с потерей части баллов доставляемости), либо отклонять письмо вовсе — при этом сама отправка «работает», просто с деградацией.

Частые вопросы