Всё Протоколы TLS DNS РФ Списки Dev Сеть Хостинги VPN proxy Ядра Транспорты Панели Клиенты Безопасность 🔍 поиск

DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) — надстройка над SPF и DKIM. Определяет политику: что делать если проверки не прошли, и отчёты: кто должен слать сводки о попытках подделки. Основной механизм защиты домена от spoofing и phishing.

Что решает

SPF и DKIM работают, но:

DMARC добавляет:

  1. Alignment. SPF или DKIM должны совпадать с From: заголовком.
  2. Policy. Что делать: none / quarantine / reject.
  3. Reporting. Отправлять отчёты об успехах и провалах на email домена.

Запись

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; sp=reject; adkim=s; aspf=s; pct=100"

Теги

ТегЗначенияСмысл
vDMARC1Обязательно
pnone / quarantine / rejectОсновная политика
spnone / quarantine / rejectПолитика для поддоменов
pct0-100Применять политику к N% почты. Для постепенного rollout
ruamailto:...Куда слать агрегированные отчёты (XML, каждые 24 часа)
rufmailto:...Куда слать failure-отчёты (по каждому провалу)
adkimr / sDKIM alignment: relaxed (subdomain OK) или strict (точное совпадение)
aspfr / sАналогично для SPF
fo0/1/d/sУсловия отправки forensic-отчётов

Alignment

Ключевая концепция. DMARC говорит: «SPF или DKIM должны aligned с From:»:

From: alice@example.com

SPF alignment:
    envelope-from  bounce@mail.example.com  → domain "mail.example.com"
    From domain    example.com

    Strict:  должно совпадать полностью → не aligned (subdomain)
    Relaxed: organizational domain одинаковое → aligned ✅

DKIM alignment:
    DKIM d=example.com
    From domain example.com
    → aligned ✅

DMARC pass = (SPF pass AND SPF aligned) OR (DKIM pass AND DKIM aligned).

Политики

p=Что делает получательКогда использовать
noneНичего, только шлёт отчётыПервые 1-3 месяца после публикации. Monitoring mode
quarantineКладёт в спамПромежуточный шаг. Ловим ошибки конфига
rejectОтклоняет на SMTP-уровнеФинальная цель

Roll-out plan

  1. Месяц 1-2: p=none; pct=100; rua=.... Собираем отчёты, видим кто шлёт от имени домена.
  2. Месяц 3: Настроить SPF/DKIM для всех легитимных источников (Google, Mailchimp, свой сервер).
  3. Месяц 4: p=quarantine; pct=10. Начинаем.
  4. Месяц 5-6: p=quarantine; pct=50 → 100.
  5. Месяц 7: p=reject; pct=10 → 100.
  6. Готово. Никто больше не может спуфить твой домен.

Aggregate reports (RUA)

Каждые 24 часа получатели (Google, Microsoft, Mail.ru, Yahoo) шлют XML-отчёт:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1700000000</begin>
      <end>1700086400</end>
    </date_range>
  </report_metadata>
  <record>
    <row>
      <source_ip>1.2.3.4</source_ip>
      <count>150</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
  </record>
</feedback>

Failure reports (RUF)

Отдельные отчёты по каждому провалу. Содержат заголовки и тело письма — приватность!. Многие крупные получатели не шлют RUF, потому что нарушает конфиденциальность отправителя.

Инструменты анализа

XML-отчёты неудобно читать. Есть сервисы-агрегаторы:

DMARCbis

Продолжение стандарта — draft-ietf-dmarc-dmarcbis (в процессе). Ключевые изменения:

Что делать при mailing-list

Проблема: рассылки (Google Groups, mailman) переписывают тело письма (добавляют footer). DKIM ломается, SPF не совпадает → DMARC reject.

Решения:

См. также