SPF, DKIM и DMARC: как закрыть дыру, из-за которой письма подделывают под директора

Два месяца назад мне позвонила клиентка — главбух юрфирмы, голос дрожит. За час до этого чуть не ушло 340 000 рублей по письму «от директора»: оплатите срочно, реквизиты во вложении. Спасло только то, что бухгалтер на автомате перезвонила уточнить. Письмо пришло буквально с их же домена. Один в один. Вот про эту дыру и поговорим — и про то, как её закрыть раз и навсегда тремя записями в DNS.

Почему письмо «от директора» вообще можно подделать

Электронная почта придумана в семидесятых. Тогда никто не думал про мошенников — думали, как бы вообще письмо доехало. Протокол SMTP до сих пор устроен так, что поле «От кого» — это просто текст. Строка. Её пишет отправитель сам, и никто это не проверяет по умолчанию. Хочешь отправить письмо с виду от ivanov@vashafirma.ru — пожалуйста, никто не спросит пароль от этого ящика.

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

У одного клиента, производство мебели, бухгалтерия получила «письмо от директора» с просьбой срочно поменять реквизиты поставщика перед оплатой. Директор был в командировке, недоступен, стиль письма — точь-в-точь его, даже подпись скопирована из старой переписки. Спасло только правило «два звонка перед оплатой больше 100 тысяч». А если бы не спасло?

SPF — список серверов, которым разрешено писать от вашего имени

SPF — это простая TXT-запись в DNS вашего домена, где вы прямо перечисляете: вот эти серверы имеют право отправлять почту от нашего имени, остальным — нельзя. Выглядит примерно так: v=spf1 include:_spf.mail24x7.net include:amocrm.ru ~all. Если письмо пришло с сервера, которого нет в этом списке, принимающая сторона видит подделку.

Настраивается это через панель управления DNS вашего регистратора или хостинга — обычно там же, где A-записи сайта. Занимает минут пятнадцать, если знаешь, что писать. Загвоздка в другом: у компании часто НЕСКОЛЬКО источников почты. Основной почтовый сервер, рассылка через SendPulse или UniSender, уведомления из 1С, письма из amoCRM или Битрикс24. Каждого нужно вписать через include, иначе их письма начнут падать в спам после включения DMARC.

У меня был клиент — медицинская клиника, три ящика на mailcow плюс автоматические напоминания о приёме через отдельный сервис SMS-рассылок с email-дублем. Настроили SPF, забыли про этот сервис напоминаний — и через неделю пациенты перестали получать письма-подтверждения записи. Регистратура две недели гадала, почему звонки участились. Мелочь, а осадочек остался.

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

SPF проверяет, с какого сервера пришло письмо. DKIM идёт дальше — он подписывает содержимое письма криптографически, чтобы его нельзя было изменить в пути. Работает так: почтовый сервер генерирует пару ключей, приватным подписывает каждое исходящее письмо, публичный публикует в DNS в виде TXT-записи с длинным набором символов вида selector._domainkey.вашдомен.ru.

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

Важный нюанс: у каждого сервиса рассылки должен быть СВОЙ DKIM-селектор. Если вы отправляете счета через 1С, а маркетинговые письма через отдельный сервис — оба должны быть подписаны собственным ключом, иначе один из потоков будет постоянно проваливать проверку. У одного клиента из торговли ровно так и получилось: подписали основной домен, а рассылку с акциями через стороннюю платформу — забыли. В итоге все акционные письма месяц уходили в спам у половины клиентов.

DMARC — правило, которое решает, что делать с подделкой

SPF и DKIM сами по себе ничего не блокируют. Это просто проверки. А вот что делать с письмом, которое их не прошло — решает третья запись, DMARC. Она же говорит почтовым серверам получателей, куда слать отчёты о том, кто вообще пишет от имени вашего домена по всему миру. Запись тоже TXT, вида: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@вашдомен.ru.

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

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

Частые ошибки, из-за которых защита не работает

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

Вторая ошибка — резкий прыжок сразу в p=reject без периода наблюдения. Знаю компанию, где айтишник в пятницу вечером включил жёсткую политику, а в понедельник директор не мог получить письма от собственного бухгалтера — потому что бухгалтерия отправляла через старый забытый почтовый релей, который никто не внёс в SPF. Хорошо, что не сорвался важный платёж.

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

Как проверить, что всё реально работает

Не верьте на слово тому, кто настраивал — проверьте сами, это бесплатно и займёт пять минут. Отправьте письмо на mail-tester.com — сервис пришлёт обратно отчёт с оценкой из 10 и покажет отдельно статусы SPF, DKIM, DMARC. Есть похожий инструмент MXToolbox — он же покажет, если у вас случайно затесались две SPF-записи.

Второй способ — посмотреть заголовки любого входящего письма от себя самому себе. Там будет строка Authentication-Results, и в ней три статуса: spf=pass, dkim=pass, dmarc=pass. Если хоть один fail — идём разбираться, что не так.

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

Что это реально даёт бизнесу

Если коротко — это закрывает конкретную, очень дешёвую для мошенника атаку. Подделать письмо без SPF/DKIM/DMARC можно за пять минут и без единого рубля вложений. С правильно настроенной защитой почтовые системы получателей — Яндекс, Mail.ru, Gmail — сами отсекают такие письма ещё до того, как человек их увидит.

У клиента из бухгалтерского аутсорсинга после настройки за первый месяц DMARC-отчёты показали 47 попыток отправки писем от их домена с серверов, которые они никогда не использовали. Все отклонены автоматически. Раньше об этих попытках просто никто не знал — письма либо уходили в спам случайно, либо, что хуже, доходили.

Отдельный бонус — это ещё и репутация домена. Почтовые провайдеры сейчас всё жёстче относятся к доменам без DMARC, особенно с ноября 2023 года, когда Google и Yahoo ужесточили требования к массовым рассылкам. Без этой настройки ваши обычные счета и коммерческие предложения могут просто чаще улетать в спам — даже без всякого мошенничества.

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

Сколько по времени занимает настройка SPF, DKIM и DMARC?
Технически сами записи добавляются в DNS за час-полтора, если знать все источники отправки почты. Но правильный переход к жёсткой политике p=reject растягивается на три-четыре недели — нужно время понаблюдать за отчётами, чтобы не заблокировать свою же легитимную почту.

Это платно?
Сами TXT-записи в DNS ничего не стоят, это бесплатная часть протокола. Платить приходится за время специалиста, который разберётся, какие у вас реально есть источники исходящей почты, и не забудет ни один сервис рассылки. У нас такая настройка под ключ обычно укладывается в один рабочий день.

У нас рассылка через стороннюю CRM и отдельный сервис для email-маркетинга — это усложняет настройку?
Да, каждый такой сервис нужно явно прописать в SPF через include и, если возможно, настроить для него собственную DKIM-подпись. Забытый сервис — самая частая причина, почему легитимные письма после включения DMARC вдруг начинают падать в спам.

Значит теперь нас точно не взломают и не обманут?
Нет, это не панацея. SPF, DKIM и DMARC защищают только от подделки именно вашего домена в поле «От кого». Мошенники всё ещё могут зарегистрировать похожий домен вроде vashafirma-ru.com и писать оттуда — тут спасает уже не DNS, а обучение сотрудников и правило перепроверять платежи звонком.