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

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

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

Каждая из этих трёх записей выполняет свою важную функцию. По отдельности они, конечно, не очень эффективны, но вместе — это просто отличная защита.

Без DMARC любой злоумышленник с арендованным IP у хостинга может отправить письмо «От: директор@example.ru» — SPF/DKIM его не трогают, получатели часто пропускают. С DMARC при aligned=strict такие письма падают в quarantine/reject.

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 (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, какие нет, какой объём каждый месяц. Плюс вы сразу увидите фишинговые домены, которые пытаются прикинуться вашим доменом.

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

Кстати, вот вам список систем, которые очень часто отправляют письма от имени вашего домена, но о которых почему-то забывают при настройке SPF/DKIM:

• 1С:Предприятие — если отправляет письма через SMTP-сервер (счета, уведомления).
• Bitrix24 / amoCRM — транзакционные письма клиентам.
• Zabbix / Prometheus alerts — на support@ и admin@.
• GitLab / Jira / Confluence — уведомления для команды.
• WordPress / Bitrix сайт компании — contact-form notifications.
• 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 на отдельной VM, настроили rua/ruf на отдельный ящик.
4. Через 2 недели наблюдения нашли 3 попытки подделки (один из них был именно тот мошенник, который украл 1.4 млн — ещё раз попытался). В reports видно его IP и полный header.
5. Через 4 недели — p=quarantine pct=100, через 6 недель 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 тыс руб.