Inbox Placement Test: как проверить, Email попал во «Входящие», «Промоакции» или спам

Рассмотрим процесс в CRM: менеджер переводит сделку в следующий статус, система отправляет коммерческое предложение, журнал фиксирует успешную отправку. Клиент при этом сообщает, что письма не видел.

Для проверки доставляемости email необходимо различать принятие сообщения сервером, его размещение в почтовом ящике и прочтение получателем.

Ниже рассматриваются деловая переписка, транзакционные уведомления и рассылки по подписке.

Что подтверждает успешная отправка

Ответ SMTP 250 после завершения передачи сообщения означает, что принимающий сервер взял на себя ответственность за его доставку или дальнейшую передачу. Папку назначения этот ответ не сообщает. В общем случае неудачная доставка после принятия требует уведомления отправителя, однако RFC 5321 допускает исключения: отбрасывание без уведомления при высокой уверенности в мошенническом или ином недопустимом характере сообщения. Поэтому отсутствие уведомления о недоставке — bounce — само по себе не подтверждает попадание во «Входящие» [1].

Inbox Placement Test — проверка размещения контрольных копий письма в почтовых ящиках выбранных провайдеров. Измеряется состояние конкретной копии в момент наблюдения: папка или категория, в которой она обнаружена [6].

Здесь важно терминологическое различие. В Gmail «Промоакции» — категория внутри «Входящих», а не разновидность спама. Основная категория называется Primary, в русской локализации — «Несортированные». Попадание в «Промоакции» не означает недоставку; для рекламного сообщения такая классификация соответствует назначению категории [2].

Почему деловое письмо может попасть в спам

Предыдущая переписка с клиентом не исключает последующей фильтрации. Google указывает на значение аутентификации, репутации домена и IP-адреса, жалоб получателей и характеристик отправки. При использовании общего исходящего IP действия других отправителей влияют на его репутацию. Поэтому условия доставки могут измениться, даже если компания не меняла свой шаблон [3].

Дополнительный фактор — списки блокировки, в том числе DNSBL: списки IP-адресов или доменов, доступные через DNS. Они могут использоваться для отклонения соединения либо как один из признаков при оценке сообщения. Проверяться могут также домены ссылок в письме. Значение конкретного списка зависит от конфигурации принимающей системы, включая самостоятельно администрируемые почтовые серверы [4].

Отдельное ограничение относится к массовой отправке. Если контрольное письмо и кампания используют разные исходящие IP или пулы, условия проверки неэквивалентны. Даже при одинаковом IP единичный тест не воспроизводит скорость, объём и жалобы получателей реальной рассылки. Google прямо рекомендует избегать резких всплесков отправки и наблюдать за ответами серверов и репутацией по мере увеличения объёма [3].

Может ли размещение измениться после доставки

Да, такие механизмы документированы. Например, Zero-hour Auto Purge в Exchange Online повторно оценивает уже доставленные сообщения. Непрочитанное письмо, позднее признанное спамом, может быть перемещено в Junk Email или карантин в зависимости от политики [5].

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

Как интерпретировать контрольную отправку

Для проверки рабочего процесса контрольную копию следует отправлять из той же CRM, системы уведомлений или сервиса рассылок. Сохраняются отправитель, шаблон, ссылки, механизмы отслеживания и тип вложений. Конфиденциальные данные заменяются тестовыми; такую замену нужно учитывать при интерпретации результата. Отправка похожего текста из личного ящика проверяет другую конфигурацию.

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

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

Во-первых, контрольные ящики не являются случайной выборкой клиентской базы. Они не воспроизводят историю переписки, настройки и поведение каждого получателя. Gmail, например, учитывает пользовательские действия при дальнейшей категоризации [2]. Поэтому девять успешных результатов из десяти нельзя интерпретировать как доказанные 90% попаданий во «Входящие» у клиентов.

Во-вторых, «не обнаружено за время теста» не означает доказанное отклонение или отбрасывание сообщения без уведомления. Причину следует устанавливать отдельно, сопоставляя результат с журналами отправки. Недоступность самого контрольного ящика также должна учитываться отдельно [6].

Реализация: проверка писем и мониторинг домена

Для этой задачи я разработал Inbox Placement Test. Пользователь получает контрольные адреса, отправляет письмо из своей системы и видит размещение копий у доступных провайдеров, включая Gmail, Outlook, Yahoo, Mail.ru и Яндекс. Бесплатный веб-режим предусматривает до трёх тестов на адрес отправителя и десяти на IP в сутки [6].

Для взаимодействия доступен Telegram-бот @InboxPlacementBot. REST API и MCP позволяют включать проверки в автоматизированные процессы; программный доступ требует ключа и имеет квоты [8].

Отдельно доступен бесплатный мониторинг домена: проверки SPF, DMARC, MX и доступных настроек TLS примерно раз в шесть часов, с уведомлениями об изменениях [6, 7]. Проверки обратного DNS и списков блокировки охватывают ограниченную выборку IP входящих MX-серверов. Они не идентифицируют все исходящие IP и не проверяют DKIM-подпись реального письма [7].

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

Вывод

Inbox Placement Test даёт наблюдение о размещении определённого письма в определённых контрольных ящиках. Он не подтверждает прочтение, не гарантирует доставку каждому клиенту и не устанавливает причину фильтрации без дополнительных данных. Его практическая ценность — возможность замечать изменения при повторных проверках и сопоставлять их с конфигурацией, журналами отправки и условиями рассылки.

Источники

1. Klensin J. RFC 5321: Simple Mail Transfer Protocol, 2008. Разделы 4.2.5, 6.1–6.2.

2. Google. Как сортировать письма по категориям.

3. Google. Email sender guidelines.

4. Levine J. RFC 5782: DNS Blacklists and Whitelists, 2010. Разделы 1, 6–7. Информационный RFC, не стандарт требований к доставке.

5. Microsoft. Zero-hour auto purge in Microsoft Defender for Office 365. Раздел Zero-hour auto purge (ZAP) for spam.

6. Live Direct Marketing. Inbox Placement Test: функции, лимиты и ограничения.

7. Live Direct Marketing. Domain Watch: состав проверок и ограничения.

8. Live Direct Marketing. REST API и MCP.

Документация и условия сервиса проверены 18 сентября 2026 года. Описание реализации приведено автором сервиса; сравнительные измерения эффективности в статье не представлены.