Подделывают письма с вашего домена: как это закрыть через DMARC

1. Как понять, что письма с домена подделывают

Подделка (spoofing) почти всегда обнаруживается косвенно, потому что письма уходят не с вашей инфраструктуры и вы их не видите. Типичные сигналы: жалобы от людей, которых нет в вашей базе; возвраты (bounce) на адреса, которым вы никогда не писали; упоминание вашего домена в письмах, которые получатели пересылают вам с вопросом, что это за рассылка.

Отдельный сигнал: так называемое обратное рассеивание (backscatter). Когда спамер рассылает письма с поддельным From, серверы получателей генерируют отказы, и эти отказы приходят на ваш реальный адрес. Если вы получаете десятки bounce-сообщений о недоставке писем, которых не отправляли, с высокой вероятностью домен подделывают.

Третий источник данных: DMARC-отчеты. Если у домена настроена запись с адресом rua, приемные системы присылают агрегированные XML-отчеты, где видны все IP, от которых приходила почта с вашим доменом в From. Неизвестные источники с результатом fail и заметным объемом в этих отчетах и есть спуфинг, зафиксированный документально.

Перед тем как ужесточать политику, важно исключить альтернативу: возможно, это не чужие серверы, а ваш собственный сервис (новый ESP, CRM, тикет-система), который отправляет от имени домена без настроенной DKIM-подписи. С точки зрения DMARC такие письма тоже fail, но лечится это настройкой, а не запретом.

2. Дерево диагностики: спуфинг, легитимный источник или взлом

Один и тот же симптом (письма от моего имени, которые я не отправлял) имеет три разные причины с тремя разными решениями. Таблица помогает быстро сузить круг.

Практический вывод из таблицы: DMARC-политика reject решает только первые две строки. Если проблема в строках три и четыре, ужесточение политики сломает вашу собственную почту или не решит проблему вовсе.

3. Проверка DNS: что должно быть на месте

DMARC работает только поверх SPF и DKIM. Логика проверки приемной стороной по действующему стандарту DMARC (RFC 9989, заменившему RFC 7489) такая: письмо должно пройти SPF или DKIM, и при этом домен в результате проверки должен совпадать (выравнивание, alignment) с доменом в заголовке From. Если совпадения нет, DMARC считается проваленным.

Проверьте три записи командами dig или nslookup:

dig TXT example.com - ищите запись вида v=spf1. Запись должна быть одна, несколько SPF-записей на одном домене ломают проверку целиком.

dig TXT selector._domainkey.example.com - проверка DKIM-публичного ключа, где selector это селектор s= из подписи ваших писем (смотрите его в заголовке DKIM-Signature).

dig TXT _dmarc.example.com - сама DMARC-запись. Пример рабочей записи:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; fo=1

Здесь p=reject запрещает прием поддельных писем от основного домена, sp=reject распространяет запрет на поддомены, rua задает адрес для агрегированных отчетов, fo=1 включает отчеты об ошибках, если провалена хотя бы одна из проверок (SPF или DKIM). Быстрый способ проверить текущее состояние без командной строки: прогнать домен через [DMARC проверку](/tools/dmarc-check), а SPF и DKIM отдельно через [SPF проверку](/tools/spf-check) и [DKIM проверку](/tools/dkim-check).

4. Почему p=none не защищает, и как перейти на reject

Частая ситуация: DMARC-запись есть, но подделки продолжаются. Причина почти всегда одна: политика p=none. По действующему стандарту DMARC (RFC 9989) политика none означает только мониторинг: приемная сторона считает результат DMARC и шлет отчеты, но ничего не делает с проваленными письмами. Формально запись есть, фактически запрета на отправку от имени домена нет.

Запрещающие политики две: quarantine (письма с провалом DMARC уходят в спам) и reject (письма отклоняются на приеме). Для задачи "запретить отправку от имени домена" конечная цель именно reject.

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

Шаг 1. Опубликуйте или приведите в порядок запись с p=none и рабочим адресом rua, собирайте отчеты минимум несколько недель.

Шаг 2. Разберите все источники из отчетов: для каждого легитимного сервиса настройте DKIM-подпись доменом из From (это самый надежный способ пройти выравнивание) и проверьте SPF. Детальный процесс разобран в статье [DMARC внедрение](/blog/nastroit-dmarc-bez-poteri-pisem).

Шаг 3. Когда все свои источники стабильно проходят DMARC, переключитесь на p=quarantine, проследите отчеты еще несколько недель, затем на p=reject.

Microsoft в своей документации по настройке DMARC рекомендует тот же поэтапный путь от none к reject для доменов отправителей. Дополнительный аргумент не откладывать: Google требует наличия DMARC-записи у отправителей с объемом от 5000 писем в день на адреса Gmail, и для массовой почты отсутствие записи уже является фактором риска доставки.

5. Что DMARC не закрывает

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

Первое: look-alike домены. Если злоумышленник регистрирует похожий домен (другая буква, транслит, лишний дефис) и шлет с него, ваш DMARC никак не участвует, потому что From содержит чужой домен. Здесь работают жалобы регистратору и хостингу через abuse-контакты, а не DNS-записи.

Второе: подмена отображаемого имени. Письмо может идти с левого адреса вида support@random-domain.com, но показывать получателю имя вашей компании. DMARC проверяет домен, а не имя, такое письмо пройдет все проверки честно.

Третье: компрометация легитимного ящика или учетной записи ESP. Если письма уходят через вашу реальную инфраструктуру с правильными SPF и DKIM, DMARC для них проходит. Лечится доступами: пароли, двухфакторная аутентификация, ротация API-ключей, аудит форм на сайте.

Четвертое: переадресация. При форвардинге SPF ломается технически, и строгая политика может привести к отказам для пересланной почты. Это не спуфинг, но учитывайте эффект при переходе на reject: механизм ARC и практика приемных систем смягчают проблему, полностью ее не убирают. Подробности в статье [Переадресация и ARC](/blog/forwarding-spf-dkim-arc).

6. Как проверить, что защита работает

Проверка результата держится на трех наблюдениях. Первое: в DMARC-отчетах доля fail от неизвестных источников перестает конвертироваться в доставку. Сами попытки отправки никуда не денутся, спамеры продолжат слать, но поле результата применения политики в отчетах покажет reject вместо none.

Второе: заголовки писем. Если получатель пересылает вам подозрительное письмо как вложение или вы ловите тестовую подделку сами, смотрите строки Authentication-Results: там должно быть dmarc=fail с указанием примененного действия. Разобрать заголовки удобно через [анализатор заголовков письма](/tools/email-header-analyzer), он показывает результат SPF, DKIM и DMARC по каждому письму.

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

7. Почему это нужно мониторить постоянно

Спуфинг не одноразовая история: волны подделок возвращаются, а собственная инфраструктура меняется. Новый сервис рассылок, смена ESP, перенос корпоративной почты: каждое изменение способно сломать выравнивание, и на строгой политике reject это превращается в потерю писем.

Есть и вторая причина следить за ситуацией: пока запрет не включен, поддельные письма продолжают доходить до чужих ящиков и генерировать обратное рассеивание на ваш адрес, а часть получателей жалуется на спам напрямую отправителю их почтового сервиса. Google Postmaster Tools считает репутацию и долю жалоб по почте, аутентифицированной именно вашим доменом (SPF Return-Path или DKIM d=), поэтому чисто поддельные письма без вашей подписи сами по себе не обязаны портить эти метрики домена. Аргумент за reject в первую очередь другой: он останавливает доставку подделок и обратное рассеивание, а не спасает репутацию задним числом. Отдельно от темы подделок держите в уме пороги жалоб на собственную легитимную рассылку: у Mail.ru от 1,1% для малых объемов до 0,3% при объеме свыше 50 миллионов писем в месяц, у Gmail 0,1% как цель и 0,3% как граница, за которой начинаются проблемы с доставкой.

PostmastersTool закрывает оба контура: сервис принимает DMARC-отчеты и показывает источники по домену, проверяет DNS (SPF, DKIM, DMARC, MX, черные списки), собирает данные Google Postmaster Tools и Mail.ru Postmaster по дням и присылает уведомления в Telegram или на почту, когда метрики пересекают пороги. Если в отчетах появляется новый неизвестный источник или растет доля fail, вы узнаете об этом в день события, а не после жалобы руководителю.