SPF, DKIM, DMARC: три записи DNS, без которых ваш домен рано или поздно подделают

Раз в пару месяцев мне звонит очередной директор в панике: «Наши клиенты получают письма якобы от нас с левыми реквизитами для оплаты». Открываю заголовки письма — а там домен подделан в лоб, потому что три строчки в DNS никто никогда не прописывал. За 12 лет в IT-аутсорсинге я настроил эту связку сотни раз, и сейчас разложу по полочкам, что это такое и почему без неё в 2026 году просто нельзя.

Зачем вообще этим заниматься

Смотрите, как устроена электронная почта. Протокол SMTP, на котором она работает, придумали в начале 80-х. Тогда никто и не думал о мошенниках — интернет был десятком университетов, которые друг другу доверяли. Поле «От кого» можно вписать любое. Хоть directorbank@sberbank.ru, хоть bухгалтерия@vash-postavshik.ru с подменённой буквой. Технически ничто не мешает.

Отсюда два разных, но связанных удара по бизнесу. Первый — ваши письма (счета, коммерческие предложения, рассылки) начинают падать в спам у получателей, потому что почтовые сервисы Mail.ru, Яндекс и Gmail видят: домен без цифровой подписи, доверия ноль. Второй, куда неприятнее — кто-то регистрирует похожий домен или вообще подделывает ваш прямо в заголовке письма и разводит ваших же клиентов на предоплату. У меня был клиент, юрфирма на 30 человек, которому именно так «увели» 340 тысяч рублей — контрагент оплатил счёт мошенникам, поверив письму «от директора».

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

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

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

Выглядит запись примерно так: v=spf1 ip4:93.95.100.215 include:_spf.mailcow.ru include:spf.yandex.net ~all. Читается как «разрешаю писать с этого IP, разрешаю сервисам из этих include, а всё остальное — мягко подозрительно, но не блокировать насмерть» (это как раз означает тильда перед all). Если поставить дефис перед all — это жёсткий запрет, письма с чужих серверов будут отбрасываться сразу.

Тут все обычно спотыкаются об одну вещь: сколько у компании реально сервисов шлют почту от её имени? Свой почтовый сервер — раз. CRM, которая отправляет уведомления клиентам — два. Сервис рассылок вроде UniSender или SendPulse — три. 1С, если из неё уходят счета на e-mail — четыре. Бухгалтерский сервис. Сайт с формой обратной связи. Я насчитывал у клиентов и по 6-7 источников. Забыли один include — и письма именно из этого сервиса начнут биться в спам ровно в тот день, когда вы включите строгую DMARC-политику. Поэтому первый шаг у меня всегда один: собрать полный список «кто шлёт почту от домена», а не полагаться на память бухгалтера.

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

SPF проверяет только IP отправителя, а вот содержимое письма никак не защищает. Письмо в пути может пройти через несколько серверов — и в теории кто-то мог бы его подправить. Тут в игру вступает DKIM, DomainKeys Identified Mail. Это криптографическая подпись: почтовый сервер при отправке письма подписывает его закрытым ключом, а в DNS публикуется открытый ключ для проверки.

Работает это так. У вас генерируется пара ключей — приватный остаётся на почтовом сервере (у меня обычно это Postfix с модулем OpenDKIM или встроенный DKIM в mailcow, который я разворачиваю клиентам чаще всего), публичный кладётся в DNS в виде TXT-записи вида selector._domainkey.вашдомен.ru. Каждое исходящее письмо получает заголовок DKIM-Signature с хэшем содержимого. Получатель берёт открытый ключ из DNS, проверяет подпись — если хоть байт в письме поменяли по дороге, подпись не сойдётся, и сервер это увидит.

Практический нюанс, с которым сталкивался раз десять: если вы меняете почтовый сервер (переезжаете, скажем, с Exchange на mailcow, я как раз недавно переводил клиента с 21 доменом именно на mailcow), старый DKIM-ключ остаётся в DNS мусором, а новый нужно прописать под новым селектором. Селектор — это просто префикс, mail2026._domainkey вместо default._domainkey, например. Их может быть несколько одновременно, это нормально, старые потом просто чистятся.

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

SPF и DKIM сами по себе — это только проверки. Они говорят получающему серверу «вот факты», но не диктуют, что с этими фактами делать. Один почтовик решит отправить в спам, другой пропустит с пометкой, третий вообще проигнорирует. DMARC — это как раз политика: вы прямым текстом говорите всем почтовым серверам мира, что делать с письмами от вашего домена, которые не прошли SPF или DKIM.

Запись выглядит так: v=DMARC1; p=reject; rua=mailto:dmarc-reports@вашдомен.ru; pct=100. Параметр p — это и есть политика. none — просто наблюдать и присылать отчёты, ничего не блокировать. quarantine — подозрительные письма в спам. reject — отклонять полностью, сервер получателя даже не примет такое письмо в очередь. Я всегда веду клиента через все три ступени по очереди, а не сразу на reject — иначе рискуете заблокировать собственную легитимную почту, если забыли какой-то source в SPF.

И вот тут самая важная часть, которую 90% статей в интернете упускают: rua-адрес. Это ящик, куда DMARC-совместимые сервера (Gmail, Яндекс, Mail.ru) присылают ежедневные XML-отчёты — кто и откуда пытался слать почту от вашего домена. Именно через эти отчёты я один раз обнаружил у клиента, что кто-то в Нигерии третью неделю пытается рассылать фишинг от его имени, — просто увидел в отчёте левый IP с провалом всех проверок. Без reject-политики эти письма бы доходили до получателей. С ней — отваливались на этапе конверта, даже не долетев.

Как это выглядит на практике: три записи в панели DNS

Технически всё сводится к тому, чтобы зайти в панель управления DNS вашего домена — это может быть reg.ru, Nic.ru, Cloudflare, панель хостинга — и добавить три TXT-записи. SPF и DMARC добавляются на сам домен (или @, в зависимости от интерфейса регистратора), DKIM — на поддомен с селектором. Никакого простоя, письма продолжают ходить как ходили, пока вы не переключите DMARC на строгий режим.

Проверить, что всё встало корректно, можно за пять минут без всякого софта — просто отправить письмо на mail-tester.com или воспользоваться dmarcian.com, они разложат по полочкам, что прошло, что нет, и почему. Я всегда после настройки делаю контрольный прогон именно так, а не полагаюсь на «ну вроде записалось».

Отдельно скажу про КриптоПро и подобные штуки — часто путают с DKIM, но это разные вещи. КриптоПро и квалифицированная электронная подпись — это про юридическую значимость документа внутри письма (например, для ЭДО с контрагентами или отчётности в налоговую). DKIM — это про то, что письмо технически пришло именно с вашего сервера и не изменено в пути. Одно другое не заменяет, они решают разные задачи, и путать их не стоит, хотя оба слова со словом «подпись» связаны.

Частые ошибки, на которых я ловил клиентов

Самая частая — несколько SPF-записей на одном домене. DNS-стандарт разрешает публиковать только одну SPF TXT-запись, если их две — сервер получателя не поймёт, какую использовать, и завернёт вообще всё. Такое бывает, когда сначала настраивал один подрядчик, потом другой добавил свою запись поверх, не удалив старую. Проверяется одной командой dig txt вашдомен.ru — если видите два v=spf1, это баг, который нужно чинить сегодня же.

Вторая ошибка — ставят DMARC сразу на reject, не посмотрев отчёты хотя бы пару недель на none. У одного клиента, торговая компания с 1С и десятком менеджеров, которые шлют счета через личные аккаунты на Yandex-почте (да, так тоже делают, хотя я и отговариваю), включение reject мгновенно обрушило доставку этих писем клиентам. Пришлось откатывать и разбираться, откуда вообще идёт почта от домена компании.

Третья история, самая обидная — настроили и забыли. DNS-записи не протухают сами, но инфраструктура меняется: сменили провайдера рассылок, подключили новую CRM, а IP старого почтового сервера при переезде хостинга остался в SPF висеть мёртвым грузом. Раз в полгода стоит свериться со списком реальных источников почты. Я обычно делаю это клиентам заодно с ежеквартальным аудитом инфраструктуры — благо, проверка занимает минут пятнадцать, а не делать её вообще — значит рано или поздно словить именно ту ситуацию с юрфирмой и 340 тысячами, о которой я писал в начале.

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

Сколько стоит настройка SPF, DKIM, DMARC?
Сами записи бесплатны — это встроенная возможность DNS, никаких лицензий покупать не нужно. Платите вы только за работу специалиста, который всё корректно пропишет и протестирует: обычно это несколько часов разовой работы, у нас в АйТи-Фреш такая задача укладывается в стандартный тариф техподдержки без доплат.

Может ли настройка сломать текущую почту?
Если делать через none и постепенно повышать строгость DMARC — риск почти нулевой. Проблемы бывают, если сразу поставить reject, не собрав полный список сервисов, которые шлют почту от домена. Поэтому я всегда сначала неделю-две смотрю отчёты, и только потом закручиваю гайки.

У нас почта на Яндекс 360 или Mail.ru для бизнеса — это тоже касается?
Да, ровно так же. Даже на облачной почте домен принадлежит вам, и записи SPF/DKIM/DMARC вы настраиваете в DNS своего домена, а не внутри интерфейса почтового сервиса. Яндекс и Mail.ru дают инструкции и готовые include-строки для SPF — их просто нужно правильно собрать в одну запись.

Как понять, что домен уже подделывают?
Самый надёжный способ — включить DMARC хотя бы в режиме none и подписаться на отчёты (rua). Через несколько дней вы увидите в XML-отчётах все IP-адреса, которые пытались слать почту от вашего домена, включая нелегитимные. Без DMARC вы об этом просто не узнаете, пока не позвонит обманутый клиент.