DMARC: настройка защиты домена от спуфинга и фишинга

Определение простыми словами

SPF и DKIM по отдельности отвечают только за технические детали: один проверяет IP-адрес отправителя, другой — цифровую подпись письма. DMARC надстраивается сверху и связывает результаты этих проверок с заголовком From: (видимым адресом). Если SPF/DKIM прошли, но домен в From не совпадает с проверенным — DMARC сработает.

Без DMARC любой может отправить письмо «от вашего имени», и почтовый сервер получателя примет его без вопросов. С DMARC = reject подделка просто отклоняется на этапе SMTP, а отчёт о попытке прилетает админу.

Сравнение: SPF vs DKIM vs DMARC

Стандарт	Что проверяет	Где хранится	Решает спуфинг?
SPF	IP-адрес отправителя в DNS	TXT-запись домена	Частично (envelope-from)
DKIM	Цифровая подпись тела письма	TXT-запись селектора	Частично (любой домен)
DMARC	Соответствие SPF/DKIM с From:	TXT _dmarc.domain	Да
BIMI	Логотип в Gmail/Yahoo	TXT default._bimi	Нет (поверх DMARC)

Кейсы использования

Защита бренда: банки и e-commerce ставят p=reject, чтобы фишинг от их имени не доходил до клиентов.
Транзакционная почта: SaaS-сервисы (Mailgun, SendGrid) требуют валидный DMARC для лучшей доставляемости в Gmail и Microsoft.
Compliance: с февраля 2024 Google и Yahoo требуют DMARC для отправителей >5000 писем в день.
Negative-сценарий: установили p=reject без подготовки → транзакционные письма от легитимных сервисов (старая CRM, трекер задач) начали отклоняться, заявки не доходят.
RUA-отчёты раскрывают теневые сервисы, которые отправляют почту с домена компании без ведома IT.

Технические детали

# DNS-запись DMARC: фаза мониторинга
# _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100"
dig +short TXT _dmarc.example.com

# Проверка DMARC через checktool
curl -s "https://dmarcian.com/dmarc-inspector/example.com" 

# Финальная политика: жёсткая блокировка
# _dmarc.example.com TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;
#                         rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com;
#                         fo=1; pct=100"

# Парсинг RUA-отчётов (XML в .gz) скриптом
pip install parsedmarc
parsedmarc --imap-host imap.example.com --imap-user dmarc 
  --imap-pass <password> --imap-folder DMARC -e elastic.local:9200

Правильная последовательность: сначала p=none + сбор RUA на 4–8 недель, разбор отчётов, добавление всех легитимных отправителей в SPF/DKIM. Потом p=quarantine с pct=10 и постепенным наращиванием. Только потом p=reject. Любая попытка прыгнуть сразу к reject ломает легитимную доставку.

🔥 Где это применяется

📧

Почтовый VPS Серверы под Postfix/Exim с правильной настройкой SPF, DKIM и DMARC

→

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

С какой политики начинать DMARC?

Только с p=none и активным сбором RUA-отчётов. 4–8 недель мониторинга, потом quarantine с pct=10, потом reject. Прыжок сразу в reject гарантированно ломает легитимную доставку.

Зачем DMARC, если уже есть SPF и DKIM?

SPF и DKIM проверяют технические заголовки, но не From: (то, что видит человек). DMARC связывает их с видимым доменом отправителя и закрывает дыру для спуфинга.

Что такое RUA и RUF?

RUA — агрегированные XML-отчёты от почтовых провайдеров о попытках отправки от вашего домена (раз в сутки). RUF — отчёты по конкретным сбойным письмам, сейчас почти не поддерживаются.

DMARC