Email spoofing: как распознать подмену отправителя и защитить домен

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

Как работает email spoofing

У электронного письма несколько идентификаторов отправителя. Пользователь обычно видит имя и адрес из поля From, но при передаче сообщения почтовые серверы также работают с техническим адресом возврата — адресом из SMTP-команды MAIL FROM. После доставки этот адрес обычно указывается в заголовке Return-Path. Видимый и технический адреса могут различаться.

Злоумышленник формирует письмо с поддельным полем From, например billing@company.ru, и отправляет его через посторонний сервер. Если домен компании не защищён политикой DMARC или почтовый сервис получателя недостаточно строго обрабатывает результаты аутентификации, сообщение может попасть в ящик с визуально достоверным адресом отправителя.

Есть несколько распространённых вариантов подмены:

• Подделка домена. В поле From указан настоящий домен компании, но письмо отправлено через неразрешённую инфраструктуру.
  
  
• Подмена отображаемого имени. Получатель видит название бренда или имя руководителя, хотя полный адрес относится к стороннему домену: Генеральный директор <fraud@example.net>.
  
  
• Похожий домен. Мошенник регистрирует адрес с опечаткой, дополнительным словом или символом другого алфавита: cornpany.ru вместо company.ru.
  
  
• Подмена адреса для ответа. Поле From выглядит достоверно, но ответы направляются на посторонний адрес из Reply-To.

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

На примерах видно, какие сведения подменяют злоумышленники:

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

Email spoofing и фишинг часто встречаются в одной атаке, но обозначают разные вещи.

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

Чем email spoofing опасен для бизнеса

Поддельные письма затрагивают компанию, даже если атака направлена на её клиентов или партнёров:

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

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

Как SPF, DKIM и DMARC защищают домен

Эти механизмы выполняют разные задачи и работают в связке.

SPF публикуется в DNS и определяет серверы, которым разрешено использовать домен в MAIL FROM. Для каждого такого домена должна существовать одна SPF-запись, учитывающая все разрешённые источники отправки. Если корпоративная почта, CRM и сервис массовых рассылок используют разные домены в MAIL FROM, SPF настраивают для каждого из этих доменов отдельно.

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

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

• p=none — не запрашивать специальную обработку таких писем (эту политику обычно используют для мониторинга и сбора отчётов);
  
  
• p=quarantine — рекомендовать получающему серверу поместить такие сообщения в карантин, например в спам;
  
  
• p=reject — рекомендовать получающему серверу отклонять такие сообщения.

Окончательное решение о доставке, помещении в спам или отклонении письма принимает сервер получателя с учётом своей локальной политики.

DMARC стоит внедрять поэтапно. Сначала компания включает режим мониторинга, собирает агрегированные отчёты и выявляет все легитимные сервисы отправки. Политику quarantine или reject устанавливают после устранения ошибок, иначе настоящие письма могут не пройти DMARC. Требования к согласованию доменов и обработке результатов описаны в RFC 9989, опубликованном в мае 2026 года взамен RFC 7489.

Какие атаки остаются возможными

Успешные SPF, DKIM и DMARC не означают, что письмо безопасно. Они подтверждают разрешённое использование домена, но не оценивают намерения отправителя и содержание коммуникации.

Почтовая аутентификация не блокирует:

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

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

Как защитить домен компании

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

Далее необходимо:

1. Настроить SPF. Для каждого домена, используемого в MAIL FROM, добавить все разрешённые источники в единственную SPF-запись. При подключении нового сервиса дополняют существующую запись, а не создают вторую.
   
   
2. Подписывать письма с помощью DKIM. Для каждого сервиса можно использовать отдельный селектор. Приватный ключ хранится на стороне отправщика, публичный размещается в DNS.
   
   
3. Включить DMARC и сбор отчётов. На первом этапе отчёты покажут неизвестные или неправильно настроенные источники отправки.
   
   
4. Перейти к строгой политике. После проверки легитимных потоков установить quarantine или reject в зависимости от выбранной стратегии.
   
   
5. Проверять тестовые письма. Для прямой отправки желательно получить результаты spf=pass, dkim=pass и dmarc=pass, а также убедиться, что домены SPF или DKIM согласованы с доменом в From.
   
   
6. Контролировать новые сервисы. Любая система, которая начинает отправлять письма от домена компании, должна быть включена в схему аутентификации.
   
   
7. Следить за похожими доменами. Важные для бренда варианты написания можно зарегистрировать заранее, а подозрительные адреса — отслеживать и передавать регистраторам для проверки.

Что проверить при отправке через Altcraft

В Altcraft from-домен определяется по адресу в поле «Email отправителя», которое задаётся в ресурсе, шаблоне или рассылке. Для прохождения DMARC домен DKIM-подписи или домен в MAIL FROM должен быть согласован с этим from-доменом.

Для Altcraft Cloud в SPF-запись разрешённого домена включают include:spf.akmta.net, где опубликован список IP-адресов отправляющей инфраструктуры платформы. Если SPF-запись уже существует, механизм include добавляют в неё: создавать вторую запись v=spf1 нельзя. Для DKIM облачные клиенты используют селектор akru2022.

Для согласования SPF в Altcraft Cloud также настраивают отдельный поддомен возврата: его CNAME-запись направляют на akmta.net, после чего этот поддомен используется в Return-Path. Конкретное имя поддомена необходимо сверить с конфигурацией отправителя.

После настройки нужно отправить тестовое письмо и проверить результаты аутентификации и согласование доменов в его заголовках. Порядок настройки SPF, DKIM, DMARC и домена возврата описан в документации по собственному from-домену.

Планируете отправлять email через собственный домен? Зарегистрируйтесь в Altcraft Platform, чтобы настроить отправителя и проверить SPF, DKIM и DMARC перед массовой рассылкой.

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

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

• адрес не соответствует отображаемому имени;
  
  
• домен содержит заменённую букву, дефис или дополнительное слово;
  
  
• Reply-To ведёт на другой адрес;
  
  
• письмо требует срочно перевести деньги, открыть файл или сообщить код;
  
  
• ссылка ведёт на домен, который не принадлежит указанной компании;
  
  
• стиль, подпись или реквизиты отличаются от предыдущей переписки.

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

Заключение

Email spoofing — подмена отправителя, из-за которой мошенническое письмо выглядит как сообщение от знакомой компании или сотрудника. Для защиты домена от прямой подделки используют SPF, DKIM и DMARC: они проверяют право сервера использовать технический домен отправителя, цифровую подпись и согласование подтверждённого домена с видимым адресом.

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

Читайте по теме

• Требования почтовых провайдеров к новым отправителям: чек-лист перед первой рассылкой
  
  
• Что делать, если письма попадают в спам: план диагностики и восстановления доставляемости
  
  
• Доставляемость email-рассылок в B2B: проблемы и решения