Как отслеживать MX-записи и состояние почтового сервера

Почтовая инфраструктура — одна из самых хрупких и наименее контролируемых частей типичного веб-сервиса. MX-записи изменяются во время миграции на нового провайдера и никогда не проверяются. SPF-записи растут, пока не превысят лимит в 10 запросов, и молча отказывают. DKIM-ключи ротируют, а публичный ключ в DNS никогда не обновляется. В результате получается перемежающийся или полный отказ в доставке, который не выявит никакой мониторинг на уровне приложения. Это руководство охватывает, что отслеживать на уровнях DNS и SMTP, чтобы разрывы выявлялись до того, как их заметит клиент.

Что может пойти не так с MX-записями

MX-запись указывает отправителям на почтовый сервер, который принимает письма для вашего домена. Неправильные MX-записи означают, что ничего не приходит.

Типичные режимы отказа: MX-запись была обновлена во время смены провайдера, но старая запись не была удалена, что создало конкурирующие серверы. Опечатка в имени хоста MX (mailserver.example.com вместо mailservers.example.com) молча направляет всё на несуществующий сервер. MX-запись указывает на имя хоста, у которого нет A-записи. Каждый из этих случаев вызывает частичный или полный отказ в доставке, который выявит тест на стороне почтового ящика, но не выявит проверка только DNS.

Четыре DNS-записи, которые стоит отслеживать

Четыре DNS-записи вместе охватывают конфигурационную сторону здоровья почты. Отслеживайте все четыре для каждого домена, с которого вы отправляете письма.

• MX: сами почтовые серверы. Настройте алерт при неожиданном изменении записи или если имя хоста не имеет A-записи.
• SPF (TXT в корне): какие серверы авторизованы для отправки. Настройте алерт при изменениях и при записях с более чем 10 вложенными DNS-запросами (убийца доставляемости).
• DKIM (TXT в ._domainkey): публичный ключ, который проверяет исходящие подписи. Настройте алерт при изменениях; отсутствие DKIM означает, что большинство провайдеров снижают доверие.
• DMARC (TXT в _dmarc): политика обработки отказов SPF и DKIM. Настройте алерт при изменениях и при излишне мягких политиках (p=none в production).

Проверки на уровне SMTP за пределами DNS

Мониторинг на уровне DNS выявляет неправильную конфигурацию. Мониторинг на уровне SMTP выявляет почтовый сервер, который правильно настроен, но фактически не работает. Оба необходимы.

Проверка: откройте TCP-соединение с почтовым сервером на порту 25 или 587. Прочитайте SMTP-баннер (220 mail.example.com ESMTP). Закройте соединение правильно. Запускайте почасово. Проверка легкая и поймает сбой, когда сервер упал, но DNS все еще на него указывает. Добавьте проверку TLS на порту 587, если вы используете STARTTLS; большинство современных почтовых серверов это используют.

Мониторинг доставки от конца до конца

Проверки DNS и SMTP говорят вам, что инфраструктура работает. Сквозные проверки говорят вам, что почта действительно доставляется. Два шаблона охватывают распространенные случаи.

• Тест туда и обратно: отправьте тестовое письмо из вашего приложения на почтовый ящик, который вы контролируете (адрес Gmail, папку входящих Mailosaur, внутренний адрес). Убедитесь, что оно приходит в течение нескольких минут.
• Внешний инструмент: такие сервисы как GlockApps, MXToolbox Inbox Insight и Mail-Tester оценивают доставляемость по поставщикам почты. Стоит запускать ежемесячно, если электронная почта - это важный источник трафика.
• Обратная связь от клиентов: подпишите выделенный адрес на свой собственный список рассылки. Если тестовый адрес перестает получать вашу почту, то же самое верно и для клиентов.

Выявление ошибок SPF с 10 запросами

SPF-записи, которые включают более 10 DNS-запросов (подсчет всех включений, перенаправлений и механизмов a/mx), молча отклоняются принимающими почтовыми серверами. Классический режим сбоя: каждый новый SaaS, который вы авторизуете для отправки от вашего имени (Mailchimp, Customer.io, Sendgrid), добавляется в ваши SPF-включения. После одиннадцатого, доставляемость молча падает.

Отслеживайте количество SPF-запросов, а не только содержимое записи. Инструменты, такие как dmarcian и SPF-тестер Postmark, сообщают количество. Предупреждайте при 8, чтобы дать себе место для маневра. Сгладьте запись (замените директивы include: их разрешенными IP), если вы близко к лимиту. Поддерживайте сглаженную версию с автоматизацией; ручное сглаживание расходится.

Стек мониторинга для почтовой инфраструктуры

Минимально полезная настройка: монитор MX на доменном имени вершины, монитор SPF (содержимое записи TXT + количество запросов), монитор DKIM на используемом вами селекторе, монитор DMARC на _dmarc, монитор SMTP-баннера на основном почтовом сервере на порту 587. Добавьте сквозный тест один раз в день на почтовый ящик, который вы действительно проверяете. Итого: шесть мониторов. Общее покрытие: большая часть поверхности отказа электронной почты. Общая ежемесячная стоимость на уровне Pro: намного меньше, чем вы тратите на кофе.