Сотрудник отправил письмо коллеге внутри компании — всё пришло во Входящие. Затем сайт с похожим адресом отправителя создал уведомление, и оно оказалось в Спаме того же сотрудника. Из первого результата часто делают вывод, что домен настроен правильно и проблема только в тексте. Но внутренняя переписка и внешнее уведомление могут проходить разные системы и проверки.
Гипотеза для расследования: команда использует внутреннее письмо как неподходящий контроль внешнего маршрута. Проверка должна установить, откуда реально пришла каждая копия и какие условия к ней применились. Это особенно важно, когда сайт, CRM и рабочая почта используют одно отображаемое имя компании, но разные отправляющие сервисы.
Одинаковый From не делает путь одинаковым
Внутренний адрес компании может отправлять через её штатную почтовую систему, а уведомление сайта — через отдельный SMTP-провайдер. Даже при одинаковом видимом From различаются технический адрес возвратов, подпись и сервер передачи. Нельзя переносить результаты аутентификации одной копии на другую только по доменной части адреса.
Корпоративные платформы позволяют задавать разные условия обработки сообщений. Например, документация Exchange Online о правилах потока описывает критерии и исключения для различных сообщений. Конкретное различие политики вашей организации нужно подтвердить у администратора; существование такой возможности не доказывает её применение в вашем случае.
Составьте карту двух отправок
Для внутреннего письма и внешнего уведомления запишите приложение-источник, From, получателя, время, Message-ID и доступные почтовые переходы. Отдельно укажите, куда вы смотрели: пользовательскую папку или статус в журнале. Сохраните полученные оригиналы для администратора, скрыв постороннюю переписку и секретные данные.
Не считайте IP входящего MX автоматически исходящим IP сайта. MX показывает направление приёма почты домена, а отправка может идти через другую инфраструктуру. Если исходящий сервер не установлен, так и напишите. Ошибочная привязка IP способна направить команду к настройкам, которые вообще не участвовали в проблемном сообщении.
Воспроизведите внешний источник
Создайте собственный тестовый аккаунт или тестовое событие в той системе, которая выпускает уведомления. Используйте безопасные данные и принадлежащий вам корпоративный адрес с согласованным доступом к диагностике. Отправьте сообщение штатным рабочим путём. Не заменяйте его копированием текста во внутреннюю почту: это снова проверит только уже успешный маршрут.
Сохраните журнал отправки и идентификатор. Через десять минут владелец ящика смотрит папки, а администратор проверяет принятые события и применённые условия. Через час повторите наблюдение. Если копия удержана в карантине, отметьте это отдельно от Спама. Если её нет в доступных данных, не объявляйте внутренний фильтр виновным без подтверждения.
В качестве дополнительного контроля направьте сопоставимую внешнюю копию на собственный адрес другого провайдера. Успешное получение там покажет только судьбу той копии. Оно не доказывает, что корпоративный шлюз обязан принять сообщение, но помогает отделить общий сбой отправки от наблюдаемого различия принимающих систем.
Меняйте подтверждённый участок
Если заголовки внешней копии показывают техническую ошибку подписи или разрешений отправки, исправьте её в реальном источнике. Не меняйте внутренний почтовый сервер только потому, что он использует тот же домен. Если подтверждено конкретное корпоративное правило, его область и назначение оценивает администратор получателя, а не внешний отправитель.
После одной согласованной правки повторите внешнее событие с новым идентификатором. Сохраните прежние From, шаблон и тип уведомления, если они не являются предметом изменения. Сравните новые технические результаты и папку с исходной копией. Если аутентификация улучшилась, а Спам остался, это два отдельных факта, а не противоречие.
Как сформулировать результат
Корректный вывод называет путь: «Внешнее уведомление сайта прошло такую проверку и найдено в такой папке». Формулировка «внутри компании всё хорошо, значит DNS правильный» слишком широка. В разборе успешной аутентификации при Спаме объясняется, почему даже подтверждённые технические проверки не равны гарантии Входящих.
Если сайт отправляет сообщения от нескольких подразделений, выбирайте именно тот сценарий, на который поступила жалоба. Уведомление формы, счёт и сообщение поддержки могут иметь разные настройки даже внутри одного приложения. Зафиксируйте название события и используемый отправляющий профиль. Успешное письмо другого типа не закрывает исходную проблему. После исправления полезно проверить этот конкретный сценарий ещё раз, сохранив его связь с журналом, вместо общей фразы о проверенном сайте.
Для независимого наблюдения отправьте рабочее внешнее письмо в Check на доступные контрольные адреса. Методология отделяет фактические папки от общих обещаний доставки. Контроль помогает проверить именно внешний источник, но не воспроизводит закрытые правила компании и не заменяет журнал её принимающей системы.
Видео-памятка: что проверить
Видео без звука, 24 секунды. Текстовая версия краткого плана:
- Внутренняя доставка может обходиться без внешнего пути приёма.
- Сравнивайте маршруты по журналам, а не только по виду письма.
- Проверка должна повторять фактический внешний источник уведомления.