Что такое спуфинг и как защитить домен от подделки писем

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

Как работает спуфинг и почему это вообще возможно

Протокол SMTP, на котором строится вся электронная почта, изначально не проверял, действительно ли отправитель имеет право указывать тот или иной адрес в поле «От кого». Технически отправить письмо с полем From: director@vashakompaniya.ru может кто угодно — сервер получателя видит только то, что написано в заголовке, если нет дополнительных механизмов проверки.

Это используется для нескольких видов атак: BEC (Business Email Compromise) — письмо якобы от руководителя с просьбой срочно перевести деньги или изменить платёжные реквизиты; фишинг от имени известного бренда — поддельное письмо «от банка» или «от известного поставщика» с целью выманить данные; и просто дискредитация домена — злоумышленник рассылает спам от имени вашей компании, чтобы получатели считали спамером именно вас.

Важно отличать спуфинг от похожего, но другого типа атаки — тайпсквоттинга, когда регистрируется похожий домен (например, company-ru.com вместо company.ru). Спуфинг не требует регистрации домена вообще: злоумышленник просто вписывает существующий чужой адрес в заголовок письма.

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

SPF: кто имеет право слать от имени домена

SPF (Sender Policy Framework) — DNS-запись, в которой владелец домена перечисляет IP-адреса и сервисы, которым разрешено отправлять почту от его имени. Принимающий сервер при получении письма сверяет IP отправляющего сервера с этим списком: если IP в списке — проверка пройдена, если нет — письмо помечается как подозрительное.

SPF закрывает только часть проблемы: он проверяет технический путь письма (по какому серверу оно пришло), но не защищает от подделки, если злоумышленник отправляет письмо через собственный сервер, а в заголовке From указывает чужой домен без прохождения через официальный почтовый маршрут — здесь в игру вступает DKIM.

DKIM: криптографическая подпись письма

DKIM (DomainKeys Identified Mail) добавляет к каждому исходящему письму криптографическую подпись, сгенерированную приватным ключом на стороне отправляющего сервера. Публичный ключ для проверки этой подписи публикуется в DNS-записи домена. Принимающий сервер берёт публичный ключ, проверяет подпись — и если она совпадает, значит письмо действительно отправлено с сервера, у которого есть приватный ключ домена, и не было изменено по пути.

DKIM решает задачу, которую не решает SPF: подтверждает целостность и подлинность конкретного письма независимо от маршрута доставки. Комбинация SPF и DKIM закрывает большинство сценариев прямой подделки, но полноценный контроль появляется только с третьим элементом — DMARC.

DMARC: что делать с письмом, которое не прошло проверку

SPF и DKIM сами по себе только дают принимающему серверу информацию для проверки — они не указывают, что делать с письмом, если проверка провалилась. DMARC (Domain-based Message Authentication, Reporting and Conformance) закрывает этот пробел: DNS-запись домена явно говорит, как поступать с письмами, не прошедшими SPF или DKIM — пропускать (p=none), отправлять в спам (p=quarantine) или отклонять полностью (p=reject).

Без опубликованной DMARC-политики с уровнем quarantine или reject поддельные письма от имени вашего домена вполне могут дойти до адресата — даже если SPF и DKIM настроены, но политика стоит на none или вовсе отсутствует, принимающие серверы просто логируют несовпадение, но не блокируют доставку.

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

Есть ещё один параметр DMARC, о котором часто забывают, — выравнивание (alignment) между доменом в заголовке From и доменом, который прошёл проверку SPF или DKIM. По умолчанию выравнивание строгое: домены должны совпадать точно, а не просто относиться к одной организации. Это важно учитывать, если письма отправляются через сторонний сервис с поддоменом — несовпадение доменов даже у легитимного отправителя может привести к тому, что DMARC-проверка не пройдёт.

Пошаговое внедрение защиты домена

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

• Составить полный список всех сервисов, которые легитимно шлют почту от имени домена: корпоративная почта, CRM, транзакционные письма, маркетинговые платформы
• Настроить SPF-запись с включением всех этих сервисов
• Включить DKIM для каждого сервиса отправки отдельно — у каждого свой набор ключей
• Опубликовать DMARC с политикой p=none и включённой отчётностью — на этом этапе цель только собрать данные, ничего не блокируя
• Через 2–4 недели проанализировать отчёты DMARC: найти легитимные источники, которые не проходят проверку, и добавить их в SPF/DKIM
• Постепенно повысить политику до p=quarantine, а затем до p=reject, когда отчёты подтвердят, что вся легитимная почта проходит проверку

Почему это важно и для доставляемости, а не только для защиты от подделки

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

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

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

Как это учтено в LDM

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

Вопросы и ответы