Как защитить корпоративную почту от фишинга с подменой домена

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

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

🔍 Какие виды подмены встречаются на практике

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

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

Третий вариант связан с омоглифами. Это символы из другого алфавита, которые внешне напоминают латинские буквы. Человек воспринимает строку как знакомое название, хотя технически домен отличается. Наконец, фишинговая ссылка может вести на один ресурс, а затем автоматически перенаправлять пользователя на другой. В описанном на Хабре разборе письмо содержит ссылку на один домен, но JavaScript на странице быстро переводит посетителя на другой веб-ресурс.

🎯 Почему одного сертификата недостаточно

Наличие HTTPS и корректного сертификата не доказывает, что сайт принадлежит нужной компании. Сертификат шифрует соединение с тем доменом, который указан в адресной строке. Если мошенник зарегистрировал похожее имя и настроил на нём HTTPS, браузер может установить защищённое соединение с поддельным сайтом. Данные передаются по зашифрованному каналу, но получают их злоумышленники.

Поэтому сотрудник проверяет не только наличие значка замка, но и сам домен. Нужно смотреть на основное имя перед доменной зоной, а не на длинную строку слева от него. В адресе могут присутствовать дополнительные поддомены и убедительные слова, однако принадлежность сайта определяется зарегистрированным доменом. Письмо от настоящей компании не становится безопасным только потому, что ссылка начинается с HTTPS.

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

🛠️ Как работают SPF, DKIM и DMARC

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

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

DMARC объединяет результаты SPF и DKIM с проверкой выравнивания доменов. Система сопоставляет домен в видимом поле отправителя с доменом, который прошёл проверку SPF или DKIM. Это важно: письмо может пройти одну техническую проверку, но не пройти проверку соответствия доменов, которые видит получатель. DMARC также позволяет владельцу домена сообщить принимающим серверам, что делать с неподтверждёнными письмами, и получать отчёты.

🔐 Как внедрить DMARC без резких сбоев

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

На первом этапе организация использует политику p=none. Она не требует от получателя блокировать подозрительные сообщения, но позволяет анализировать отчёты DMARC и видеть источники отправки. Команда сопоставляет эти источники с известными сервисами, исправляет SPF и DKIM, проверяет выравнивание доменов и устраняет легитимные ошибки.

После анализа компания переводит отдельные потоки на p=quarantine. Неподтверждённые сообщения получают более осторожную обработку и могут попадать в карантин или папку нежелательной почты. Команда наблюдает за отчётами, проверяет обращения пользователей и убеждается, что рабочая переписка продолжает доставляться.

Зрелый этап — политика p=reject. Она просит принимающие системы отклонять сообщения, которые не проходят требуемую проверку. Переход выполняется после проверки всех законных отправителей. Политика не уничтожает весь фишинг: письмо с домена-двойника может пройти собственные проверки этого домена. Однако строгий DMARC заметно усложняет подделку корпоративного адреса в поле отправителя.

📊 Что именно проверять в почтовых журналах

Отчёты DMARC показывают, откуда приходят сообщения с использованием домена компании и как проходят проверки. Их анализ помогает обнаружить забытый сервис рассылок, неверную настройку подписи или массовую попытку подделки отправителя. Важно смотреть не только на итоговый процент успешных проверок, но и на новые источники, резкие изменения объёма и неизвестные адреса отправки.

Почтовый шлюз дополняет эту картину. В журналах полезно искать совпадения по теме письма, отображаемому имени отправителя, домену ссылки, результатам SPF, DKIM и DMARC, а также по действиям пользователя. Если несколько сотрудников получили одинаковое письмо, команда фиксирует время доставки, получателей, переходы по ссылкам и попытки ввода данных.

Для каждой легитимной платформы нужно понимать, какой домен она использует в поле отправителя и какой домен проходит DKIM. Отдельно проверяют пересылку и почтовые цепочки, поскольку она может изменять путь доставки и влиять на SPF. Результат анализа документируют в перечне разрешённых отправителей, который регулярно пересматривают.

🌐 Как контролировать доменную зону и регистратора

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

Организация включает уведомления обо всех изменениях DNS-записей, делегирования, серверов имён и параметров домена. Уведомление должно быстро попадать ответственным сотрудникам, чтобы несанкционированное изменение не оставалось незамеченным. Для критичных операций полезно разделять права просмотра и изменения, а также хранить историю согласований.

Контроль охватывает записи, связанные с почтой и веб-сервисами. Неожиданное изменение MX-записи может повлиять на доставку почты, а изменение адреса веб-сервиса — направить пользователей на чужую инфраструктуру. DNS-мониторинг не заменяет защиту учётных записей, но помогает обнаружить последствия компрометации и ошибки администрирования.

🧭 Как искать домены-двойники

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

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

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

⚠️ Как сотруднику распознать подозрительное письмо

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

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

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

🎓 Как обучать сотрудников без формального теста

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

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

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

🚨 Что делать после получения фишингового письма

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

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

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

Если подозрение связано с доменом-двойником, организация фиксирует адрес, копию страницы и другие признаки, не взаимодействуя с сайтом больше необходимого. Эти данные используют для блокировки, уведомления регистратора и предупреждения клиентов. Внутреннее сообщение должно содержать точный домен и понятное объяснение, почему он не является официальным.

✅ Практический план защиты компании

Работу удобно разделить на несколько потоков. ИТ-команда отвечает за почтовую аутентификацию, DNS и регистрацию доменов. Отдел информационной безопасности анализирует отчёты и кампании. Руководители подразделений поддерживают обучение и проверку критичных запросов. Финансовая функция участвует в контроле платежей и смены реквизитов.

• Составить перечень доменов компании и всех законных отправителей.
• Настроить SPF для разрешённых серверов и исключить неиспользуемые источники.
• Включить DKIM для корпоративной почты и сервисов рассылок.
• Настроить DMARC с постепенным переходом от p=none к p=quarantine и затем к p=reject.
• Проверить выравнивание домена в поле отправителя с доменом SPF или DKIM.
• Защитить регистратора и DNS многофакторной аутентификацией и ограничить права.
• Включить уведомления об изменениях доменной зоны и хранить историю операций.
• Организовать мониторинг похожих доменов, омоглифов, сертификатов и копий страниц.
• Настроить почтовый шлюз для проверки ссылок, вложений и технических результатов аутентификации.
• Проводить обучение и безопасные учебные кампании с разбором ошибок.
• Регулярно анализировать журналы шлюза и отчёты DMARC.
• Проверять сценарий реагирования на письмо с подменой домена.

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

🔒 Как оценивать результат защиты

Эффективность измеряют не количеством проведённых инструктажей, а изменениями в процессах. Компания отслеживает долю легитимной почты, проходящей SPF, DKIM и DMARC, число неизвестных источников отправки, количество обнаруженных похожих доменов и время от регистрации подозрительного домена до реакции.

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

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

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

📚 Читайте также

• Промпт-инъекции: как нейросети становятся инструментом фишинга
• Спам-фильтры на ИИ: как старый трюк со скрытым текстом их обманывает
• Социальная инженерия и фишинг: защита от психологических атак в 2026
• Анализ электронной почты: как выявлять фишинг до того, как письмо открыто
• Дипфейки против корпоративной защиты: взлом через фейковый звонок

📖 Термины

DNS · MFA · Персональные данные · Социальная инженерия · Фишинг

🔗 Источники

• Lookalike-домены и защита от них(2026-08-14 ✓)
• Атаки lookalike и защита от доменов-двойников(2026-08-14 ✓)
• Фишинг с подменой URI: или как один хитрый редирект может угнать ваши пароли(2026-08-14 ✓)
• Фишинг через похожие домены: как мошенники обманывают пользователей и как защитить свой бизнес(2026-08-14 ✓)