Спуфинг email: как подделывают отправителя и как защитить домен рассылки

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

Как технически работает спуфинг

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

Для получателя такое письмо выглядит легитимно: имя отправителя и домен в адресной строке совпадают с вашими. Единственный способ отличить подделку — проверка на уровне протоколов аутентификации, которую делает не человек, а принимающий почтовый сервер до того, как письмо вообще попадёт во «Входящие» или в «Спам».

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

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

SPF: список серверов, которым разрешено отправлять

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

Ограничение SPF в том, что он проверяет только технический путь письма (заголовок Return-Path), а не видимый получателю адрес «От» — теоретически письмо может пройти SPF-проверку и при этом иметь подделанное отображаемое имя отправителя. Поэтому SPF — необходимое, но не достаточное условие защиты.

Практический момент для холодного аутрича: если рассылка идёт через несколько сервисов или инструментов одновременно (например, свой SMTP плюс сторонний сервис для part of кампаний), в SPF-записи должны быть перечислены все они. Забытый сервис в записи — частая причина, по которой легитимные письма начинают проваливать проверку.

DKIM: цифровая подпись письма

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

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

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

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

SPF и DKIM сами по себе не указывают почтовому серверу, что делать с письмом, которое их не прошло — отправить в спам, отклонить или пропустить как есть. Именно это решает DMARC (Domain-based Message Authentication, Reporting and Conformance): DNS-запись, которая связывает результаты SPF и DKIM с видимым доменом в поле «От» и явно говорит принимающим серверам, какую политику применять.

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

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

• p=none — режим наблюдения, письма проходят как обычно, но приходят отчёты
• p=quarantine — письма, не прошедшие проверку, помечаются или уходят в спам
• p=reject — письма, не прошедшие проверку, отклоняются на уровне сервера
• rua/ruf — адреса, куда приходят агрегированные и подробные отчёты о проверках

Что проверить прямо сейчас, если домен используется для рассылок

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

• SPF-запись включает все реальные источники отправки, включая сторонние сервисы
• DKIM настроен и подпись проходит проверку в спам-чекерах
• DMARC опубликован хотя бы в режиме наблюдения, отчёты приходят и просматриваются
• Регулярный просмотр DMARC-отчётов на предмет чужой отправки от имени домена
• План поэтапного перехода от наблюдения к карантину и отклонению

Дополнительные меры защиты домена

Помимо базовой триады SPF, DKIM и DMARC, есть смежные меры, которые снижают риск спуфинга и связанных с ним проблем именно для домена, активно используемого в холодных рассылках. Одна из них — BIMI (Brand Indicators for Message Identification), запись, позволяющая показать логотип компании рядом с письмом в поддерживающих её почтовых клиентах, если домен уже прошёл строгую DMARC-проверку. Это не защита от спуфинга напрямую, но дополнительный визуальный сигнал легитимности для получателя.

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

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

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