Три ситуации, которые выглядят похоже
Мошенник может указать знакомое имя, использовать другой похожий домен или подделать адрес вашего домена. Другой сценарий: сообщение действительно отправлено через разрешенную систему, но доступ к ней получил посторонний. Получатель может видеть похожую картину, хотя меры защиты нужны разные. Поэтому сначала собирают исходное сообщение, адреса и время, а затем проверяют технический маршрут.
Отсутствие письма в папке отправленных не является окончательным доказательством подмены: отправка могла происходить через CRM, внешний сервис или другой доступ. И наоборот, наличие вашего адреса в From не доказывает вход в ящик. Нужны проверяемые сведения из почтовой системы и доверенной стороны приема. Не вводите пароль на странице из подозрительного сообщения ради такой проверки.
Владелец может начать с безопасной фиксации: кто получил письмо, какой адрес виден, какие действия просит отправитель и есть ли независимое подтверждение запроса. Для передачи материалов выбирайте согласованный канал и убирайте лишние персональные данные. Полные заголовки могут содержать техническую информацию, которая не должна автоматически становиться публичной.
Выбирайте действие по наблюдаемому признаку
Таблица ниже помогает задать направление проверки, но не устанавливает причину по одному признаку. Несколько сценариев могут сочетаться: например, похожий домен используется вместе с захваченной перепиской. Если затронуты платежи или клиентские данные, параллельно назначьте уполномоченного владельца решения и ограничьте опасный процесс в согласованном объеме.
| Что видно | Чего это не доказывает | Что проверить |
|---|---|---|
| Знакомое имя, другой адрес | Что использован ваш домен | Полный адрес и независимое подтверждение личности |
| Похожий, но другой домен | Что SPF вашего домена сломан | Написание домена и контекст переписки |
| Ваш домен в From | Что кто-то вошел в ящик | Исходные заголовки и аутентификацию у получателя |
| Письмо из разрешенной системы | Что действие санкционировано человеком | Доступы, журналы и владельца отправляющей системы |
| Ответы на неизвестные письма | Как именно возникла отправка | Исходное письмо и реальные маршруты бизнеса |
Что говорят заголовки и аутентификация
Принимающая почтовая система может записывать результаты SPF, DKIM и DMARC. Их интерпретируют с учетом доверенного узла, доменов проверки и возможной пересылки. SPF относится к определенной SMTP-идентичности, DKIM к домену подписи. Для DMARC по RFC 9989 нужен прошедший SPF или DKIM, согласованный с доменом в видимом From. Отдельные слова pass без контекста недостаточны.
Не следует слепо доверять любой строке Authentication-Results: важно, кем и где она добавлена. Скриншот части заголовков может скрывать нужную информацию, а сообщение после пересылки отражать изменившийся маршрут. Результат разбора лучше формулировать точно: какие идентичности и проверки установлены, чего не удалось проверить и какие следующие действия нужны.
Когда отдельно проверять доступ к настоящему ящику
Необычные входы, неизвестные правила пересылки, изменения способов восстановления или подтвержденная отправка через рабочий сервис требуют разбора доступов. Изменение DNS само по себе не завершает такой разбор. Уполномоченный администратор проверяет доступные журналы, сеансы, делегирование и связанные приложения с учетом фактической платформы и разрешения владельца.
Если требуется смена учетных данных, учитывайте доверенность устройства и сохранение материалов. Один новый пароль не является универсальным подтверждением завершения всех сеансов и доступа приложений. Согласуйте действия по конкретным механизмам и проверьте результат. В международной команде фиксируйте время с часовым поясом и получателя эскалации, чтобы технические изменения были согласованы.
- Сохранить ограниченные сведения об исходном сообщении.
- Отделить домен, видимое имя и реальную отправляющую систему.
- Разобрать доверенные результаты аутентификации.
- При признаках компрометации проверить доступы и разрешенные приложения.
- Согласовать исправления домена или учетной записи и подтвердить результат.
Что делать с просьбой изменить платежные реквизиты
Не подтверждайте перевод только ответом на то же письмо. Свяжитесь с известным представителем другим заранее известным способом и проверьте полномочия. Технически аутентифицированное сообщение может исходить из захваченного законного ящика. Поэтому DMARC pass не заменяет бизнес-проверку изменения реквизитов или разрешения на оплату.
Если деньги уже отправлены, действуйте через установленную финансовую цепочку и соответствующих провайдеров без ожидания завершения технического анализа. Не обещайте возврат и не публикуйте непроверенное обвинение. Сохраните доступные сведения о запросе и операции для уполномоченных участников. Конкретные обязанности и порядок уведомлений зависят от организации и юрисдикции.
Как снизить риск повторения
Для своего домена полезно знать отправляющие системы и согласованно настраивать SPF, DKIM и DMARC. Текущий RFC 9989 опубликован в мае 2026 года; политика не является обещанием, что все получатели отфильтруют любую подделку. Требования Gmail относятся к его сервису и определенным категориям отправителей. Проверка домена и защита учетных записей дополняют друг друга, но не заменяют бизнес-процедуры.
CyberFixCrew применяет практические израильские знания в защите почты и цифровой инфраструктуры для русскоязычного бизнеса по всему миру. В запросе укажите домен, провайдера, признаки и время. Не присылайте пароль или полный архив переписки. Сначала определим нужный объем: почтовый маршрут, записи домена, учетную запись или несколько связанных участков.
