Для проверки Inbox Placement в Postmark используйте тот же Message Stream и способ подачи, что и у исследуемого письма. Отправьте оригинальное сообщение этим маршрутом на тестовые адреса LDM и посмотрите папки полученных копий. Успешный тест транзакционного чека не подтверждает работу рассылки, которая пойдёт через другой Broadcast-поток.
Легко сосредоточиться на видимом From и забыть о пути за ним. Два письма могут иметь одинаковый адрес отправителя, но формироваться разным кодом, использовать разные шаблоны и потоки. Полезная проверка фиксирует эти условия. Описанный процесс не предполагает, что LDM подключается к вашему аккаунту Postmark или выбирает stream за вас.
Контролируемое сравнение сужает гипотезу, но не доказывает универсальное исправление
Что определяет Message Stream
Postmark разделяет Transactional для сообщений вроде чеков, вызванных действиями пользователя, и Broadcast для отправки многим получателям, например подписных новостей. Руководство Message Streams также поясняет: исходный Transactional stream сервера остаётся потоком по умолчанию. Создание нового stream не заменяет этот default.
Выбирайте класс по назначению сообщения и настоящему процессу отправки. Сам факт автоматизации не решает вопрос: запланированная рассылка не становится чеком только потому, что её отправляет программа. Для неоднозначных случаев используйте рекомендации Transactional vs. Broadcast.
Тестовое сообщение должно оставаться в классе, соответствующем планируемому использованию. Эксперимент имеет смысл, когда проверяет маршрут, которым допустимо пользоваться для этого типа писем. Иначе можно получить результат, не относящийся к рабочей задаче.
API и SMTP выбирают поток по-разному
Для API Postmark документирует параметр MessageStream со значением Stream ID. Если его не указать, используется исходный Transactional stream сервера. При проверке другого потока передавайте нужный ID явно и смотрите фактический запрос. Название переменной в коде не подтверждает выбранный маршрут.
В SMTP важны и адрес сервера, и способ аутентификации. Postmark указывает smtp.postmarkapp.com для Transactional и smtp-broadcasts.postmarkapp.com для Broadcast. Справочник SMTP и токенов описывает два подхода: Server Token с заголовком выбора потока либо SMTP Token, привязанный к конкретному stream. Руководство называет заголовок X-PM-Message-Stream.
Если почтовая библиотека удаляет пользовательские заголовки, это требует отдельного внимания. Проверьте, что реально уходит из приложения. Там, где это подходит, используйте документированную аутентификацию SMTP конкретного потока, вместо предположения, что заголовок сохранился после обработки фреймворком.
Шесть шагов представительного теста
1. Определите сообщение
Выберите конкретную задачу: сброс пароля, чек, обновление продукта или newsletter. Установите подходящий поток и путь приложения, который отвечает за эту отправку. Не объединяйте разные типы сообщений в один вывод только из-за общего From.
Возьмите безопасные тестовые значения, формирующие окончательный вид письма. Сохраните тему, отправителя, обе версии тела, ссылки и вложения. Оставьте необходимые механизмы отписки. Удаление этих элементов создаст искусственно упрощённый образец вместо реального сообщения.
2. Зафиксируйте маршрут заранее
Запишите идентификатор сервера Postmark, Stream ID, способ подачи API или SMTP, редакцию приложения и шаблона. Для SMTP укажите host и метод аутентификации без самого токена. Для API сохраните эффективное значение MessageStream.
Отметьте значимые пользовательские заголовки и настройки трекинга. Такая короткая запись позволяет объяснить, почему ручное диагностическое письмо не всегда эквивалентно запланированной задаче приложения. Особенно полезно заранее обозначить условия, которые сознательно отличаются.
3. Подготовьте конечный набор адресатов
Создайте тест в Inbox Placement by LDM, указав настоящий адрес отправителя. Возьмите адреса текущей проверки и убедитесь, что аккаунт и рабочий процесс разрешают этот тест.
Не включайте получателей в постоянную аудиторию, прогрев или повторяющиеся автоматизации. Если приложению нужны временные записи, отделите их от обычной клиентской выборки. Они не должны запускать последующие сообщения. Не обходите suppression, чтобы принудительно добиться доставки.
4. Отправьте оригинал через выбранный поток
Используйте обычную логику формирования и подачи сообщения, заменив адресатов на ограниченный набор. Не пересылайте письмо из ящика сотрудника: пересылка добавляет другой контекст и маршрут обработки.
Непосредственно перед отправкой снова проверьте эффективные параметры. Для API — конкретное значение потока. Для SMTP — host и работающий механизм выбора stream. Все намеренные изменения конфигурации должны быть перечислены в записи эксперимента.
5. Установите, какой stream обработал письмо
Найдите доступную информацию об отправке именно тестового сообщения. Сопоставьте получателя, время и идентификатор с записью приложения. Затем подтвердите поток, связанный с этой отправкой.
Не считайте название шаблона или задания достаточным доказательством маршрута. Отдельно храните ошибки подачи, транспортные события и размещение. Если сообщение вообще не стало доступным для доставки, сначала исследуйте этот этап, а не предполагаемое решение фильтра получателя.
6. Прочитайте наблюдения осторожно
Используйте методологию LDM. Missing или unknown не означают Spam. Promotions и подобные категории относятся к полученным копиям, но отличаются от основной Inbox и Spam.
Окно 24 часа наблюдает ту же полученную копию без повторных отправок. Сохраняйте время вместе с папкой. Более поздняя неудача проверки не устанавливает новое положение письма и не отменяет уже подтверждённое наблюдение.
Условный пример: поток не указан
Инженер использует утилиту для тестирования чеков при подготовке продуктового объявления. Утилита не передаёт MessageStream, поэтому выбирается маршрут сервера по умолчанию. Копия оказывается в Inbox, и команда сначала считает проверенной будущую рассылку.
Это условная ошибка конфигурации, а не рекомендация отправлять объявления через Transactional. Наблюдение относится к реально использованному пути. Оно не подтверждает настройки планируемого Broadcast-потока.
Команда обнаруживает расхождение, явно выбирает правильный Broadcast stream и выполняет отдельную ограниченную отправку окончательного объявления. Различия результатов нужно описывать вместе с изменением маршрута. Другая папка сама по себе ещё не доказывает, что её причиной стал именно выбор stream.
Что сохранить в записи теста
Оставьте четыре связанные части: окончательный образец письма, фактическую маршрутизацию, события отправителя и наблюдения ящиков с временем. Нужны идентификаторы, которые позволяют соединить эти сведения. Секреты доступа и лишние персональные данные в такой записи не требуются.
При повторении после изменения шаблона или конфигурации перечислите изменения. Комплексная проверка новой системы может быть полезна, но не изолирует влияние одного элемента, если поменялись сразу несколько.
Результат по-прежнему ограничен наблюдаемыми получателями. Он не предсказывает правила, историю взаимодействия и будущую реакцию всей аудитории. Успешная аутентификация также не гарантирует Inbox.
Частые вопросы
Новый stream становится потоком по умолчанию?
Нет. Postmark сохраняет исходный Transactional default сервера. Другой поток выбирайте явно и проверяйте событие фактической отправки, а не порядок создания streams.
Достаточно успешного теста чека для проверки newsletter?
Нет. У рассылки другое содержимое, контекст и подходящий маршрут. Проверяйте именно этот процесс с итоговым сообщением и обязательной отпиской.
Что делать, если SMTP-клиент не добавляет нужный заголовок?
Изучите документированный SMTP Token конкретного потока и используйте правильный host. Проверьте, что клиент поддерживает полученную конфигурацию, прежде чем считать маршрут воспроизведённым.
Отсутствующая копия означает неправильный stream?
Нет. Поток устанавливается по конфигурации и событиям отправки. Неопределённость ящика не указывает причину и не превращается в Spam.
Можно сравнивать потоки постоянной отправкой на те же seeds?
Используйте ограниченные эксперименты с конкретным вопросом, подходящим классом сообщения и актуальными адресами. Не подключайте seeds к постоянной отправке или прогреву.
Проверьте поток вместе с письмом
Начните тест LDM для конкретного процесса Postmark. Сохраните оригинал и маршрут: тогда наблюдаемая папка будет относиться к понятной, проверяемой конфигурации.