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

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

Что такое спуфинг и почему это не абстрактная угроза

Спуфинг домена — это когда злоумышленник отправляет письмо, в поле «От кого» которого стоит адрес на вашем домене (например, bухгалтерия@company.ru), хотя реально письмо ушло с совершенно другого сервера, никак не связанного с компанией. Почтовый протокол SMTP по умолчанию не проверяет, имеет ли отправитель право использовать указанный домен — это фундаментальная уязвимость, которую и закрывают SPF, DKIM и DMARC.

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

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

Три уровня защиты: SPF, DKIM, DMARC

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

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

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

• SPF — список серверов, которым разрешено отправлять почту от имени домена
• DKIM — криптографическая подпись, подтверждающая, что письмо не изменено и подписано владельцем домена
• DMARC — политика действий при несовпадении SPF/DKIM плюс отчёты о попытках спуфинга
• BIMI (опционально) — отображение логотипа компании в письме, требует настроенного DMARC как предпосылку
• Регулярная проверка DNS-записей после смены хостинга почты или добавления нового домена-сателлита

Как настроить защиту на практике

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

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

DMARC стоит внедрять поэтапно: сначала политика p=none, которая только собирает отчёты о нарушениях без блокировки писем, чтобы увидеть реальную картину и не сломать легитимные каналы по ошибке. Через несколько недель мониторинга, когда все легитимные источники учтены в SPF и DKIM, политику ужесточают до p=quarantine, а затем до p=reject.

Как это связано с аутрич-кампаниями

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

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

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

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

Что делать, если домен уже подделывают

Первый признак — жалобы от партнёров или клиентов о письмах, которые они не отправляли, или DMARC-отчёты, показывающие массовые попытки отправки с неизвестных IP от имени домена. В этой ситуации нужно как можно быстрее ужесточить DMARC-политику до quarantine или reject, если она ещё не была на этом уровне.

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

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

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

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