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

Привет! Я Евгений Семёнов, директор ITFresh. Сегодня расскажу вам кое-что поучительное. В 2025 году у нас был клиент – оптовая компания электротоваров, 24 сотрудника. Они столкнулись с классикой жанра: BEC-инцидент. Что случилось? Мошенник подделал директора, отправил их контрагентам письма с новыми реквизитами. В итоге? Два клиента перевели 1.4 миллиона рублей! Самое интересное: ни одного из этих трёх писем не было в их логах. Злоумышленник просто подменил поле From, без всякой аутентификации. А DMARC, как это часто бывает, у клиента был не настроен. Хотите узнать, как всего три DNS-записи спасут ваш бизнес от таких атак? И бонусом — навсегда решат проблему с тем, что «наши письма улетают в спам».

Зачем нужны все три — SPF, DKIM и DMARC

Эти три записи – не просто набор символов. Каждая выполняет свою важную роль. По отдельности? Ну, так себе защита. А вот вместе они образуют по-настоящему мощный щит.

Что происходит без DMARC? Любой, кто арендовал IP на хостинге, может отправить письмо «От: директор@example.ru». SPF/DKIM его даже не заметят, а получатели часто пропускают такие сообщения. А с DMARC, да еще и при настроенном aligned=strict? Такие письма сразу отправляются в карантин или отклоняются. Никаких шансов для мошенников.

SPF — основа основ

SPF-запись — это, по сути, обычная TXT-запись в DNS. Туда мы заносим всех, кому разрешено отправлять письма от имени вашего домена. Хотите пример? Вот как выглядит стандартная запись, которую мы делаем для наших клиентов:

example.ru.  IN  TXT  "v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 \
  include:_spf.mailgun.org include:amazonses.com -all"

Что это означает:

• ip4:203.0.113.10 — ваш собственный почтовый сервер.
• ip4:203.0.113.20 — резервный почтовый (если есть).
• include:_spf.mailgun.org — добавить все IP сервиса Mailgun (транзакционные письма).
• include:amazonses.com — добавить Amazon SES (маркетинг).
• -all — всё остальное отклонять (hardfail).

Важные принципы:

• Запомните главное: на домен должна быть ТОЛЬКО ОДНА SPF-запись. Иначе столкнётесь с ошибкой permerror.
• Знаете, что важно? Уложиться в строгий лимит — не более 10 DNS-запросов при раскрытии include-записей в SPF. Это так называемый counting-limit. Не уверены, что у вас всё в порядке? Обязательно проверьте через Kitterman SPF-checker, иначе письма могут просто не дойти до адресатов!
• Для subdomains — отдельные SPF.

DKIM — подпись криптоключом

DKIM – это как цифровая подпись для ваших писем. Публичный ключ хранится в DNS, приватный – на вашем почтовом сервере. Сервер подписывает все исходящие сообщения, а получатель проверяет эту подпись. Так мы удостоверяемся, что письмо пришло именно от вас, а не от кого-то еще.

Генерация ключа на Linux:

# OpenDKIM
opendkim-genkey -b 2048 -d example.ru -s mail -v
# Создаст mail.private (приватный) и mail.txt (публичный для DNS)

# Добавить в DNS-зону:
mail._domainkey.example.ru.  IN  TXT  "v=DKIM1; k=rsa; \
  p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7Xr..."

# Подключение в Postfix через rspamd / opendkim
# После этого все исходящие получают заголовок
# DKIM-Signature: v=1; a=rsa-sha256; d=example.ru; s=mail; ...

Selector (mail) в записи позволяет иметь несколько ключей — можно ротировать их без простоя. Я рекомендую 2048 бит минимум (1024 уже считается слабым) и ротацию раз в 6 месяцев.

Проверить DKIM на живом письме — посмотрите заголовки через View Raw в любом клиенте, должно быть Authentication-Results: ...dkim=pass header.i=@example.ru.

DMARC — политика и отчёты

DMARC-запись – это дирижёр оркестра. Она собирает все правила воедино: какую политику применять к подозрительным письмам и куда отправлять отчёты о них. Вот пример стандартной записи, которую мы настраиваем:

_dmarc.example.ru.  IN  TXT  \
  "v=DMARC1; p=quarantine; sp=quarantine; adkim=s; aspf=s; \
   pct=100; \
   rua=mailto:dmarc-reports@example.ru; \
   ruf=mailto:dmarc-failures@example.ru; \
   fo=1"

Что означает:

• p=quarantine — неаутентифицированные → в спам. Альтернативы: none (только мониторинг), reject (отклонить).
• sp=quarantine — такая же политика для sub-доменов.
• adkim=s — strict alignment DKIM: From и DKIM-домен должны совпадать точно (не sub).
• aspf=s — strict для SPF.
• pct=100 — применять к 100% писем (можно начать с 10% для плавного rollout).
• rua= — адрес для aggregate-отчётов (суммарно от провайдеров).
• ruf= — адрес для failure-отчётов (конкретные письма, которые не прошли).
• fo=1 — слать failure-отчёт при любом failure.

Поэтапное внедрение — обязательно

Главный совет: никогда не ставьте сразу p=reject на боевом домене. Порядок:

1. Неделя 0: настраиваете SPF + DKIM. Записи должны проходить mail-tester на 9-10/10.
2. Неделя 1: ставите DMARC p=none. Собираете aggregate-отчёты в течение 2 недель.
3. Неделя 3: анализируете отчёты — видите, кто отправляет от имени вашего домена. Легитимные добавляете в SPF/DKIM, нелегитимные изучаете (может, это ваши старые сервисы, о которых забыли).
4. Неделя 4: p=quarantine, pct=10 (10% неправильных писем в спам).
5. Неделя 5-6: pct=50.
6. Неделя 7-8: pct=100.
7. Неделя 9: p=reject, pct=100 (если нет ошибок).

Анализ DMARC-отчётов через parsedmarc

Отчёты, приходящие на rua-адрес? Ох, это тонны XML-файлов от всех крупных провайдеров: Mail.ru, Gmail, Yahoo, Microsoft. Вручную их читать? Да это же просто кошмар! Кто так работает? Никто. Поэтому мы настраиваем связку из parsedmarc, Elasticsearch и Kibana. Тогда все становится прозрачно и наглядно:

# docker-compose.yml
services:
  parsedmarc:
    image: jwillmer/parsedmarc
    volumes:
      - ./config:/etc/parsedmarc
    environment:
      - IMAP_HOST=mail.example.ru
      - IMAP_USER=dmarc-reports@example.ru
      - ELASTICSEARCH_HOSTS=elasticsearch:9200
  elasticsearch:
    image: elasticsearch:8.15.0
  kibana:
    image: kibana:8.15.0
    ports: ["5601:5601"]

В Kibana вы получаете готовый дашборд: какие IP отправляют письма от вашего домена, какие из них проходят SPF/DKIM, а какие нет. Видите объём почты каждый месяц. И самое главное – вы сразу обнаружите любые фишинговые домены, которые пытаются притвориться вашими. Это же просто спасение!

Типовые источники, о которых забывают

Кстати, часто забывают про вот эти системы, а ведь они тоже шлют письма от имени вашего домена. Смотрите список:

• Возьмем, к примеру, 1С:Предприятие. Если оно отправляет письма через SMTP-сервер — будь то счета клиентам или важные уведомления — нужно быть уверенным, что эти письма всегда доходят.
• Или, скажем, вы используете Bitrix24 или amoCRM. Эти системы шлют критически важные транзакционные письма вашим клиентам, верно? Подтверждения заказов, изменения статусов – без них никак, а значит, доставка должна быть идеальной.
• Что насчет ваших систем мониторинга? Когда Zabbix или Prometheus кричат об аварии, их алерты обязательно должны приходить на support@ и admin@. Иначе кто узнает о проблеме вовремя?
• В командах разработчиков незаменимы GitLab, Jira, Confluence. Все эти платформы генерируют массу уведомлений для сотрудников. С ними работа идет как по маслу, если, конечно, все письма доходят до адресатов.
• У вас корпоративный сайт на WordPress или Bitrix? Тогда вы точно получаете уведомления с контактных форм. Ведь это прямые заявки от потенциальных клиентов, и их потеря недопустима!
• И, конечно, не забываем про email-маркетинг. Независимо от того, пользуетесь ли вы Unisender, SendPulse или MailChimp, ваши рассылки — это лицо компании. Они обязаны достигать адресатов, а не попадать в спам.
• Или представьте: онлайн-касса или банк-клиент отправляют чеки и выписки. Это же не просто бумажки, это финансовые документы! Их своевременное получение критически важно и для вас, и для ваших клиентов.

Важно: каждый источник должен быть прописан в SPF либо напрямую, либо через include. И для каждого требуется свой DKIM-селектор. Не пропустите!

Кейс с 1.4 млн руб — продолжение

Помните того клиента, с которого я начал историю? После BEC-инцидента мы, конечно, пришли разбираться.

Что обнаружили:

• SPF стоял, но с ~all (softfail) вместо -all (hardfail). Mail.ru пропускает такие письма в inbox.
• DKIM не было вообще.
• DMARC не было вообще.
• В логах нашего почтового сервера не было ни малейшего упоминания о подделанных письмах. Почему? Очень просто: они ушли к клиентам напрямую, с сервера злоумышленника, минуя наш. Наш сервер их просто не "видел".

Что сделали за 3 рабочих дня:

1. Мы провели тщательный аудит: искали все системы, которые рассылают письма от имени домена. И что вы думаете? Нашли целых 6 таких источников! Конечно, мы тут же внесли их все в SPF-запись.
2. Настроили SPF с -all, DKIM 2048-бит, DMARC p=none для warmup.
3. Чтобы контролировать ситуацию, мы развернули parsedmarc на отдельной виртуальной машине. Затем аккуратно настроили отправку отчетов RUA и RUF на выделенный почтовый ящик. Так мы собираем всю важную информацию о доставке.
4. Всего через две недели наблюдения мы выявили целых три попытки подделки наших писем. Представляете, один из этих наглецов оказался тем самым мошенником, который ранее украл 1,4 миллиона рублей! Он снова попытался. Но теперь-то мы видим всё: в отчетах четко отображается его IP-адрес и полный заголовок письма. Наша система работает!
5. Наши меры дают результат. Всего через четыре недели мы смогли установить политику p=quarantine со 100% охватом, а ещё через две недели, то есть на шестой неделе, перешли уже на p=reject. Это значит, что поддельные письма теперь просто отбрасываются почтовыми серверами, не доходя до получателей.
6. И, конечно, мы не забыли о людях. Параллельно с техническими работами провели обязательный инструктаж сотрудников: получили письмо с новыми реквизитами? Немедленно звоните отправителю! Только "голосом" можно убедиться, что это не мошенники. Это наше золотое правило безопасности.

Что было дальше? Мы перевели их на политику p=reject. Теперь все попытки подделки блокируются на уровне Mail.ru и Google, ещё до того, как письмо могло бы попасть к адресату. С тех пор инцидентов, к счастью, больше не было. Кстати, стоимость этого проекта составила 44 тысячи рублей – согласитесь, это совсем немного, чтобы избежать таких потерь!

Дополнительно: BIMI и MTA-STS

Если DMARC уже работает на p=reject и всё стабильно, есть ещё пара штрихов, которые можно добавить:

• BIMI — показывает логотип вашей компании рядом с письмом у получателя (сейчас в Gmail, Yahoo; в 2026 обещают в Mail.ru). Повышает узнаваемость бренда.
• MTA-STS — защита TLS-соединения между почтовыми серверами от даунгрейда. Ставится через DNS + HTTPS-файл.
• TLSRPT — отчёты о проблемах TLS при доставке.

FAQ — DMARC/DKIM/SPF

Что такое SPF простыми словами?

SPF (Sender Policy Framework) — список IP-адресов, которым разрешено отправлять письма от имени вашего домена. Получатель проверяет: если письмо от example.ru пришло с IP, которого нет в SPF-записи, оно помечается как подозрительное. Защита от простого спуфинга адреса отправителя.

Чем DKIM лучше SPF?

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

Что такое DMARC и зачем он?

DMARC (Domain-based Message Authentication) — политика, которая говорит получателям: 'если SPF или DKIM моего домена не проходят, делай quarantine или reject'. И ещё — присылай отчёты о нарушениях на указанный email. Это защита от подмены домена в фишинге и одновременно аналитика.

Какую политику DMARC выставить — none, quarantine или reject?

Поэтапно: начинать с p=none (только мониторинг, отчёты собираем, анализируем). Через 2-4 недели, если все легитимные отправители аутентифицированы, переход на p=quarantine (в спам). Через ещё 2-4 недели — p=reject (полное отклонение). Резкий старт с reject блокирует маркетинговую рассылку и транзакционные письма.

Сколько стоит настройка DMARC под ключ?

Для компании с одним основным доменом и 1-3 отправителями (почта + CRM + маркетинг) — от 28 тыс руб: аудит текущих DNS-записей, настройка SPF/DKIM/DMARC, подключение parsedmarc для аналитики, недельное наблюдение. Для компаний с 5+ источниками отправки (several brands, dept-level domains) — от 60 тыс руб.