SPF, DKIM и DMARC: как я закрывал почтовый домен клиента от мошенников

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

Как вообще получается, что письмо «от вас» пишет не ваш сервер

Электронная почта устроена на честном слове. Протокол SMTP, которому уже больше сорока лет, при отправке письма не спрашивает никаких доказательств. Поле «От кого» — это просто текст. Написать туда можно что угодно: buhgalteria@vashafirma.ru, director@сбербанк.рф, да хоть santa@northpole.com. Никакой сервер по умолчанию это не проверяет.

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

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

SPF: список «кому разрешено говорить от моего имени»

SPF, Sender Policy Framework, — это первая и самая простая линия обороны. По сути одна текстовая запись в DNS вашего домена, где вы перечисляете: вот эти серверы имеют право отправлять почту от имени moyafirma.ru, всем остальным — не верить. Выглядит она примерно так: v=spf1 include:_spf.mail24x7.net ip4:93.95.100.215 -all.

Проблема в том, что SPF почти никогда не настроен полностью. Компания меняет почтовый сервис, подключает CRM с рассылками, добавляет сервис для отправки счетов из 1С — и каждый раз забывает дописать нового отправителя в SPF-запись. У одной юридической фирмы, которую мы вели, в SPF было аж пять include, и три из них указывали на сервисы, которыми компания не пользовалась года с 2022-го. Мёртвый груз, который только увеличивает риск ошибки и, кстати, может сломать саму проверку — у SPF есть жёсткий лимит в 10 DNS-запросов на просмотр.

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

DKIM: цифровая подпись, которую нельзя подделать

DKIM работает иначе и честнее. При отправке письма ваш сервер подписывает его закрытым ключом — считает контрольную сумму заголовков и части тела письма и вставляет эту подпись в скрытый заголовок. Получатель берёт открытый ключ из вашего DNS (тоже TXT-запись, обычно вида selector._domainkey.moyafirma.ru) и проверяет: письмо действительно отправлено с сервера, у которого есть закрытый ключ, и по дороге его не меняли ни на байт.

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

Мы настраиваем DKIM клиентам через Rspamd на mailcow или через встроенные механизмы Exchange Online — там это буквально один переключатель и пара DNS-записей, минут 20 работы. Но, опять же, сам по себе DKIM ничего не запрещает. Он только даёт получателю технический факт: подписано или нет. А вот что делать с неподписанными письмами — решает уже третий механизм.

DMARC: рубильник, который наконец говорит «не пропускать»

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

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

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

Кейс: как мы за три дня закрыли дыру, которой уже месяц пользовались мошенники

Возвращаясь к той бухгалтерской фирме. Первым делом мы подняли DMARC в режиме мониторинга — p=none — просто чтобы увидеть картину, не трогая ничего боевого. Отчёты пришли уже через сутки, и картина была неприятной: помимо легитимного сервера компании, письма от их домена слали ещё пять IP-адресов, три из них — из дата-центров в Нидерландах и Индии.

Дальше проверили SPF — он у клиента был настроен ещё в 2019 году и с тех пор не трогался, «мягкий» механизм (~all вместо -all), который фактически говорит: если сервер не из списка — пометьте письмо подозрительным, но не отклоняйте. Мы заменили на жёсткий -all и дописали актуальный почтовый сервис. DKIM у них вообще не был настроен — редкость в 2026 году, но у небольших компаний с самопальной почтой на старом cPanel-хостинге такое встречается сплошь и рядом.

На четвёртый день, после накопления недели чистых отчётов, мы перевели DMARC на p=quarantine, а через две недели — на p=reject. С этого момента все письма, которые не проходят и SPF, и DKIM одновременно, автоматически летят в спам получателя или отклоняются вовсе. Спуферские рассылки от имени клиента прекратились за один день — не потому что мошенники сдались, а потому что их письма перестали доходить хоть куда-то. Технически подделать домен по-прежнему можно, но получателю такое письмо уже никогда не покажут как «настоящее».

Что реально нужно сделать и сколько на это уходит времени

Практика для директора без технических знаний. Шаг первый — проверить, есть ли у вас вообще эти записи. Открываете любой бесплатный сервис проверки DMARC (mxtoolbox, dmarcian и десятки аналогов), вбиваете свой домен — и через пять секунд видите правду. У процентов 60 компаний до 50 сотрудников, с которыми мы работали, DMARC не было вообще никогда.

Шаг второй — если у вас своя почта на выделенном сервере (Postfix, Exim, mailcow) — это работа для системного администратора часа на два-три вместе с проверкой. Если вы на Яндекс 360, VK WorkMail или Microsoft 365 — там ещё проще, у провайдера обычно есть готовый мастер настройки SPF и DKIM, DMARC добавляется отдельной TXT-записью в панели вашего DNS-регистратора.

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

Почему это не разовая настройка, а процесс

Тут есть неприятный нюанс, который выясняется через полгода-год после настройки: SPF и DKIM ломаются каждый раз, когда компания подключает новый сервис отправки. Завели рассылку через SendPulse, подключили новую CRM с email-уведомлениями, перешли на другого провайдера ЭДО — и если забыли добавить их в SPF или настроить DKIM для нового отправителя, письма начинают либо не доходить, либо, что хуже, снова открывают лазейку для подделки.

Поэтому DMARC-отчёты стоит смотреть не разово, а хотя бы раз в квартал. Мы у клиентов на обслуживании ставим это отдельной задачей в регламент — 20 минут раз в три месяца посмотреть сводный отчёт, кто слал письма от домена клиента. Звучит скучно, но именно так мы в марте поймали у другого клиента, торговой компании, забытый сервис email-подтверждений на сайте, который слал письма с истёкшим DKIM-ключом уже два месяца — просто никто не заметил, потому что письма до этого доходили нормально, только без подписи.

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

Частые вопросы

Если я настрою DMARC на жёсткую блокировку сразу, что-то сломается?
Почти наверняка да, если пропустить этап мониторинга. Любой легитимный сервис, который отправляет письма от вашего домена — CRM, 1С, сервис счетов, — но не настроен под SPF и DKIM, начнёт отклоняться наравне с мошенниками. Всегда начинайте с p=none, смотрите отчёты две-три недели и только потом ужесточайте политику.

У нас маленькая компания на 12 человек, вся почта на Яндексе. Нам это вообще актуально?
Актуально даже больше, чем крупным. Мошенники специально выбирают в качестве жертв малый бизнес — там реже занимаются техническими деталями почты, а доверия к письму от знакомого поставщика или бухгалтера ровно столько же. У Яндекс 360 и большинства облачных почтовых сервисов настройка SPF и DKIM занимает 15-20 минут через готовый мастер в панели управления.

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

Сколько стоит вся эта настройка, если заказывать у подрядчика?
Для компании на своей почте с одним доменом это обычно 3-6 тысяч рублей разовой работы плюс месяц сопровождения на этапе перехода к жёсткой политике. Если почта на облачном провайдере вроде Microsoft 365 или Яндекс 360, дешевле в разы — там большая часть настроек делается через готовые мастера, и работа сводится к паре часов консультации и проверки.