Мониторинг доставляемости почты: 15 минут каждую неделю

SMTP-сервер ответил 250 OK. Значит, письмо доставлено?

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

Без наблюдения некоторые проблемы остаются незаметными. Вы не обязательно получаете сведения о каждой жалобе на спам, а ограничения отправки часто нужно искать в ответах SMTP. Исторические примеры цен платформ вроде Return Path или Validity составляют $2,000-$5,000 в месяц; текущие предложения следует проверять. В феврале 2024 Google и Yahoo усилили требования к отправителям. Неудачная кампания может повредить репутации отправителя в течение 24 часов, но фиксированного сценария нет. Начать можно с повторяемого процесса и доступных бесплатных инструментов.

Что такое мониторинг доставляемости почты?

Мониторинг доставляемости почты отслеживает результаты аутентификации, жалобы, ошибки SMTP и списки блокировки. Он помогает локализовать проблемы, но не обнаруживает каждое незаметное решение фильтра. Google Postmaster Tools, MXToolbox и запросы DNS дают дополняющие друг друга сведения; учитывайте условия доступа и ограничения.

1. Результаты аутентификации как основа

Проверяйте фактический успех SPF, DKIM и DMARC и необходимое согласование доменов, а не только наличие записей. Ошибки аутентификации могут способствовать отказу или фильтрации в зависимости от политики получателя.

A. SPF: ограничение в 10 условий

SPF проверяет право отправки для SMTP-идентичности. RFC 7208 ограничивает вызывающие обращения к DNS условия, включая рекурсивную обработку, числом 10, а не считает все пакеты DNS. Учитываются include, a, mx, ptr, exists, redirect. Не учитываются ip4, ip6, all.

Google Workspace, Mailchimp, HubSpot и CRM вместе могут превысить лимит 10. Конфигурация, подходившая шесть месяцев назад, может перестать подходить после добавления сервисов или изменения вложенных записей. PermError означает ошибку вычисления; дальнейшая обработка зависит от получателя. Подробнее о структуре в руководстве по записям SPF для почты.

B. DKIM: длина ключа и смена селектора

В применимых требованиях к отправке на личные адреса Gmail Google требует ключ DKIM длиной не менее 1024 бит и рекомендует 2048 бит. Старые ключи 512 бит небезопасны и могут стать причиной отказа. После смены провайдера проверьте используемый селектор, опубликованный ключ и криптографическую проверку подписи. Исчезновение прежнего селектора затронет письма, которые все еще его используют, а не обязательно все исходящие потоки.

C. DMARC: важно согласование доменов

Для DMARC нужен успешный SPF или DKIM с доменом, согласованным с видимым From. Особенно важно проверить это при отправке сторонними сервисами.

Пример: вы отправляете через Mailchimp. Домен адреса Return-Path равен bounce.mailchimp.com, From равен team@yourcompany.com. SPF может пройти для идентичности сервиса, но согласование SPF отсутствует. Тогда DMARC может пройти благодаря подходящей подписи DKIM. Если и этот путь не работает, политика получателя может предусматривать фильтрацию или отказ.

p=none может использоваться для изучения разрешенных потоков; 30 дней являются примером планирования, а не обязательным сроком. Длительное p=none не означает полное отсутствие защиты, но не требует отказа на основании DMARC. Прежде чем переходить к p=quarantine, проверьте все разрешенные потоки.

Бесплатная проверка DNS из терминала

Запросы из терминала дают дополнительную возможность проверки, но используемый резолвер тоже может кэшировать результаты. Учитывайте TTL, выбранный резолвер и ответы авторитетных серверов.

# Check SPF record
dig txt yourdomain.com +short

# Check DMARC policy
dig txt _dmarc.yourdomain.com +short

# Check DKIM (replace "google" with your actual selector)
dig txt google._domainkey.yourdomain.com +short

В Windows:

nslookup -type=txt yourdomain.com
nslookup -type=txt _dmarc.yourdomain.com

Повод для проверки: более 10 вызывающих обращения к DNS условий SPF, политика p=none, которую не пересмотрели после запланированных 30 дней, или необходимая запись DKIM, возвращающая NXDOMAIN. Наличие записи не заменяет проверку подписи реального письма.

2. Жалобы на спам: следить за порогом 0.3%

Жалобы являются важным сигналом. Метрика Google для личного Gmail и собственная метрика Yahoo имеют разные определения. 0.3% арифметически соответствует 3 жалобам на 1,000 рассматриваемых сообщений, но это не делает все отправленные письма знаменателем Google. Для Gmail рекомендована величина ниже 0.1%. Эти значения не являются универсальной долей успешной доставки или доказательством необратимого ущерба.

Статус массового отправителя сохраняет значение

При отправке примерно 5,000 сообщений личным аккаунтам Gmail за 24 часа применяется текущая классификация Google для массовых отправителей. Последующее снижение объема по нынешним правилам не снимает этот статус. Соблюдайте действующие требования к аутентификации и отписке; это не обещание неизменности правил навсегда.

Учитывать ограничения видимости

Gmail не предоставляет обычные отчеты FBL с указанием конкретного пожаловавшегося пользователя. Google Postmaster Tools может показывать агрегированные данные пользователям с соответствующими правами. Добавьте домен, подтвердите контроль записью DNS TXT и проверяйте доступные показатели, например еженедельно. Они дополняют журналы SMTP, но не доказывают доставку каждого письма.

При отправке менее ~100 писем в день в Gmail данных, например, может не быть; это не фиксированный порог публикации. Тестовые адреса дают отдельные наблюдения, а открытия искажаются защитой приватности и автоматической загрузкой изображений. Ни один из этих сигналов не доказывает доставку во все входящие.

3. Диагностика по ошибкам доставки

Считайте журналы SMTP диагностическими данными. Они помогают найти причины, которых не видно в отчетах о жалобах. Читайте код вместе с полным ответом, названием провайдера и этапом обмена; сам код не всегда раскрывает точную причину.

Важные коды в журналах

550 5.1.1: неизвестный получатель. Проверьте полный ответ и адрес. Более 2% может быть внутренним сигналом риска, но не доказывает автоматическую оценку любого провайдера. Изучите происхождение списка и согласия. ZeroBounce или Bouncer могут дополнить проверку; учитывайте приватность и ограничения инструментов.

550 5.7.1 / 550 5.7.515 (Microsoft). Первый код общий и требует полного текста. Второй связан с требованиями Outlook.com к отправителям большого объема: должны проходить и SPF, и DKIM, а DMARC должен проходить благодаря хотя бы одному согласованному механизму. Проверьте аутентификацию и конкретный список блокировки, если он действительно указан.

421 RP-001 / 451 4.7.500 (Microsoft). Возможны временные ограничения или отсрочки; новый IP не является обязательной причиной. Изучите полный ответ и практику отправки. Для BYO SMTP, например Amazon SES с выделенным IP, 4-6 недель могут служить планом постепенного увеличения нагрузки, но не гарантированным сроком восстановления. Соблюдайте правила сервиса и ограничения повторных попыток.

4. Списки блокировки: Tier 1 и фактическое влияние

Учитывайте список, причину, конкретный IP или домен и получателей, использующих эти данные. Tier 3 и Tier 1 здесь обозначают ориентиры, а не универсальный стандарт. Ограничивайте затронутые или вредоносные потоки, не останавливая автоматически всю законную переписку.

Примерно еженедельно проверяйте домен и исходящий IP доступными функциями MXToolbox. 90 секунд могут быть планом короткой проверки, но расследование причины может занять дольше.

5. Еженедельная проверка на 15 минут

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

1. Google Postmaster Tools. Ниже ли 0.1% соответствующая доля спама? Какая репутация домена показана? При превышении 0.1% проверьте кампании и доступные данные, не полагаясь лишь на общий статус.
2. Списки блокировки. Проверьте домен и IP в MXToolbox. Запись Tier 1, например Spamhaus, требует своевременно оценить причину, охват и затронутую отправку.
3. Журналы SMTP. Изучите доступные журналы своего сервиса, например TrekMail, SES или SendGrid. Для 5.7.x нужен полный ответ; ответы 421 Microsoft могут означать временные ограничения.
4. Тестовые адреса. Отправьте письма собственным личным аккаунтам Gmail и Outlook. Проверьте, куда попал тест. Promotions не обязательно означает ошибку; спам требует расследования.

6. План реакции на ухудшение показателей

Определите ответственных, сохраняемые данные и действия. Следующие три сценария являются примерами, а не полным рейтингом или универсальной инструкцией.

Сценарий A: доля спама достигает 0.2%

Изучите кампании и при необходимости приостановите необязательную рекламу. Транзакционный поддомен вроде alerts.yourdomain.com помогает разделять управление, но не гарантирует независимую репутацию или бесперебойную доставку. На следующие две недели можно использовать подтвержденное согласие и недавнюю активность как критерии аудитории. Одних открытий за последние 30 дней недостаточно из-за неточности измерения. Полезная желательная переписка не заменяет исправления причины.

Сценарий B: Microsoft отклоняет письма (550 5.7.515)

Проверьте конкретные требования Outlook.com: успешные SPF и DKIM, а также DMARC с хотя бы одним согласованным механизмом. Изучите изменение объема, но не объясняйте отказ аутентификации только ограничением скорости. Передайте соответствующей поддержке Microsoft IP, полный ответ и коды ошибки.

Сценарий C: запись в Spamhaus

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

Как включить TrekMail в процесс мониторинга

Ручные проверки могут подходить для одного или двух доменов. При 20, 50 или 200 клиентских доменах помогают ответственные, единые процедуры и доступные сводные представления.

Для небольших компаний: состояние DNS

TrekMail может проверять записи DNS и их состояние. Превышение лимита SPF 10 или отсутствие селектора DKIM требуют расследования. Проверка записей не подтверждает успешную проверку подписи реального письма, согласование DMARC или доставку во входящие. Периодические уведомления зависят от конкретной функции, повторных ошибок и настроек; раннее предупреждение до обращения клиента не гарантировано.

Исторические данные называют Starter от $3.50 в месяц и бесплатный вариант до 10 доменов без карты. Проверьте сегодняшние лимиты, функции и условия. В описанной Nano BYO-модели для всех исходящих писем и ответов нужен собственный SMTP-сервис.

→ Проверьте бесплатный вариант TrekMail и включите доступные проверки DNS в свой процесс.

Для агентств: управление 1,000+ доменами

Для клиентского портфеля важно единое наблюдение, а не отдельный запрос. Исторически Agency описан для 1,000+ доменов с общей емкостью хранения. Проверьте текущие права и квоты: сбой или злоупотребление на общей инфраструктуре может затронуть нескольких клиентов.

BYO SMTP в поддерживаемой конфигурации позволяет использовать Amazon SES, SendGrid или Mailgun, сохраняя IMAP-ящики и хранение у хостинг-провайдера. Смена SMTP может требовать правок DNS, клиентов и проверки; отсутствие простоя или миграции нельзя обещать без учета системы. Раздельные маршруты не обеспечивают автоматическую изоляцию репутации домена.

→ Условия на trekmail.net/pricing: исторический пример Agency называет $23.25 в месяц для 1,000+ доменов, а не обязательные сегодняшние лимиты.

Итог

Начать можно с четырех регулярных проверок: доступные данные Google Postmaster Tools, записи списков блокировки в MXToolbox, ошибки в журналах SMTP и отдельные размещения тестовых писем. Вместе они дают ориентиры, но не доказывают полную исправность или причину каждого сбоя.

Важно не только финансирование, но и повторяемый процесс проверки и реакции. Не считайте 250 OK доказательством окончательной доставки и сделайте мониторинг частью эксплуатации.