Что изменилось к 2026 году и почему «DMARC: none» больше не стратегия
Если вы админ, DevOps или вебмастер, то DMARC для домена — это уже не «опция для крупных», а базовая настройка, без которой репутация домена постепенно деградирует. В 2026 многие получатели (крупные почтовики, корпоративные шлюзы, антиспам) стали жёстче относиться к доменам, у которых нет согласованной связки SPF + DKIM + DMARC или она настроена формально.
Исторически p=none воспринимался как «режим наблюдения»: собираем отчёты, смотрим, кто отправляет, потом ужесточаем. Проблема в том, что многие на этом и застряли: годами стоит none, домен подделывают, а отчёты никто не читает.
Второй сдвиг — рост значимости alignment (согласования доменов в идентичностях письма). Даже если SPF и DKIM «pass», но не выровнены с доменом в From:, DMARC будет fail. А дальше в зависимости от политики и антиспам-профиля получателя — карантин, спам или отклонение.
DMARC — это не «ещё одна TXT-запись». Это политика, которая реально защищает домен только при корректном alignment и учёте всех легитимных источников отправки.
Базовые сущности: SPF, DKIM, DMARC и где именно ломается alignment
SPF: проверка «кто имеет право отправлять»
SPF — это TXT-запись, где вы задаёте разрешённые источники исходящей почты. SPF проверяется по домену из MAIL FROM (envelope-from, bounce-домен), а не по «красивому» From:, который видит пользователь.
Частая ошибка: SPF «pass» на одном домене (например, bounces.vendor.example), а From: — другой (example.com). Формально SPF работает, но для DMARC важен alignment.
DKIM: криптографическая подпись содержимого
DKIM подписывает письмо ключом, соответствующим публичному ключу в DNS. В DNS это выглядит как TXT-запись вида selector._domainkey.example.com. Проверка DKIM привязана к домену в теге d= (в заголовке DKIM-Signature).
Критический момент: домен d= должен быть выровнен с доменом в From: по правилам DMARC (strict/relaxed), иначе DMARC не засчитает DKIM как подтверждение домена отправителя.
DMARC: политика плюс требования к alignment
DMARC отвечает на вопрос: «Если письмо заявляет From: user@example.com, совпадает ли домен в From с доменом, прошедшим SPF и/или DKIM, и что делать при несовпадении?»
DMARC успешен (pass), если выполняется одно из условий:
- DKIM = pass и домен
d=выровнен с доменом From, или - SPF = pass и домен в envelope-from выровнен с доменом From.
Именно alignment определяет, сможете ли вы безопасно включить политику quarantine/reject без «самострела» по легитимной почте.
Relaxed и Strict: что означает alignment (adkim/aspf) на практике
В DMARC есть два переключателя:
adkim— режим выравнивания DKIM-доменаd=с доменом From;aspf— режим выравнивания SPF-домена (envelope-from) с доменом From.
Значения:
r(relaxed) — достаточно совпадения «организационного домена» (обычно eTLD+1). То естьmail.example.comсчитается выровненным сexample.com.s(strict) — требуется точное совпадение домена.mail.example.comуже не выровнен сexample.com.
Для большинства доменов практичный дефолт — adkim=r и aspf=r. Strict имеет смысл, когда вы сознательно разделяете домены/поддомены под разные потоки и уверены, что все отправители способны отправлять и подписывать строго с нужного домена.
Как выглядит рабочая связка DNS-записей (шаблоны) и где чаще ошибаются
SPF-запись: минимум и типовые ловушки
Пример «скелета» SPF (подставьте свои источники):
example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.mailvendor.tld -all"Типовые проблемы в проде:
- несколько SPF TXT на одном домене (должна быть одна запись);
- превышение лимита 10 DNS-lookup (часто из-за цепочек include);
- слишком мягкий финал
~allтам, где вы уже контролируете все источники; - SPF настроен, но отправка идёт через другой bounce-домен, и SPF alignment не выполняется.
DKIM: запись в DNS и селекторы
DKIM в DNS (пример):
mx1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."Нормальная картина в 2026: один домен обслуживают несколько систем (CRM, helpdesk, рассылки, транзакционные письма, почта сотрудников). Значит, будет несколько селекторов (mx1, mta, vendor1), и это нормально, если все они подписывают письма доменом, выровненным с From.
Ошибки, которые чаще всего ломают переход к reject:
- сервис подписывает письма доменом провайдера (
d=vendor.tld) вместо вашего домена; - публичный ключ «ломается» пробелами/кавычками/переносами из-за особенностей DNS-панели;
- селектор опубликован, но на отправителе включён другой селектор;
- ротация сделана без учёта TTL: старый ключ выключили раньше, чем он вышел из кешей.
DMARC: политика и отчёты rua/ruf
Минимальная DMARC-запись для наблюдения:
_dmarc.example.com. TXT "v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:dmarc-rua@example.com; fo=1"Что здесь важно:
p— политика:none,quarantine,reject;rua— агрегированные отчёты (обычно раз в сутки в XML);ruf— форенсик-отчёты (в 2026 поддерживаются не везде и часто ограничены приватностью);fo— условия дополнительных сигналов о фейлах (полезно на этапе внедрения).
Для управляемого перехода к reject вам достаточно RUA и дисциплины по разбору агрегатов. Если отчётов много и их нужно разбирать системно, дальше логично настроить парсинг и дешборды: см. материал про разбор DMARC-отчётов и контроль доставляемости.
Пошаговый план: перейти от none к reject без сюрпризов
Ниже — сценарий, который обычно работает в смешанной инфраструктуре: свои MTA, сторонние рассыльщики, сервисные письма из приложений.
Шаг 1. Инвентаризация отправителей (до изменения политики)
Составьте список всех источников исходящей почты от домена:
- почтовый сервер сотрудников (если есть);
- CMS/сайт (формы, уведомления);
- CRM/рассыльщики;
- helpdesk/тикет-системы;
- мониторинг/алерты;
- любые интеграции, которые шлют «как будто от домена».
Цель простая: каждый источник должен обеспечивать либо DKIM alignment, либо SPF alignment (лучше — оба).
Шаг 2. Привести From в порядок (домен, поддомены, отдельные потоки)
Практика, которая упрощает жизнь: разделяйте потоки по поддоменам, если у вас разные сервисы и разные риски. Например:
news.example.com— маркетинговые рассылки;notify.example.com— транзакционные уведомления;example.com— переписка людей.
Но помните: если вы оставляете From: @example.com для всего, то все сервисы должны уметь подписывать DKIM вашим доменом (или отправлять с выровненным envelope-from). Иначе ужесточение DMARC сломает часть писем.
Шаг 3. Настроить DKIM так, чтобы alignment точно проходил
Самый надёжный путь к DMARC pass — DKIM с d=example.com (или с поддоменом при relaxed). Для сторонних сервисов это обычно включается в настройках домена-отправителя и требует публикации TXT-записи, которую сервис выдаёт.
Проверьте на реальных письмах, что в заголовке DKIM-Signature домен d= — ваш, а не домен провайдера. Если у вас есть пересылки и списки рассылок, дополнительно учитывайте, что они могут ломать подпись: полезно ознакомиться с подходами уровня ARC на примере стека MTA/антиспам в статье про ARC и пересылки, которые ломают DMARC.
Шаг 4. Включить отчётность и собрать статистику (p=none)
Оставьте p=none на 7–14 дней, но с задачей реально разобрать RUA. Вам нужно понять:
- какие источники дают DMARC pass;
- какие дают fail и почему (SPF fail, DKIM fail, нет alignment);
- какие IP/ASN внезапно «отправляют от вашего домена» (часто это подделка).
На этом этапе часто всплывает «наследие»: старый сайт шлёт почту напрямую с IP хостинга без DKIM, или мониторинг подставляет From домена, но отправляет через чужой relay без выровненного envelope-from.
Шаг 5. Переход к quarantine через pct (мягкое ужесточение)
Когда большая часть легитимного трафика даёт DMARC pass, переходите на карантин по доле:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@example.com"Дальше каждые несколько дней поднимайте pct: 25 → 50 → 75 → 100. Если начинает «сыпаться» важная почта — вернитесь на предыдущую ступень и чините конкретный источник (обычно это DKIM alignment или неправильно настроенный bounce-домен).
Шаг 6. Финальная политика: p=reject
Когда карантин на 100% не вызывает инцидентов, ставьте:
_dmarc.example.com. TXT "v=DMARC1; p=reject; adkim=r; aspf=r; rua=mailto:dmarc-rua@example.com"p=reject — это не «запрет на отправку», а запрет на доставку поддельных писем, которые не смогли пройти DMARC с alignment. При корректно настроенной инфраструктуре легитимная почта продолжает ходить, и часто даже стабильнее (меньше спуфинга, меньше жалоб, предсказуемее репутация).
rua и ruf: что реально собирать и как не утонуть в отчётах
RUA (агрегаты) — основной источник правды. Даже без сложного пайплайна минимально полезно:
- завести отдельный ящик для
rua; - хранить отчёты хотя бы 30–60 дней (чтобы видеть сезонность и редкие отправки);
- закрепить процесс: кто и как реагирует на всплески DMARC fail.
RUF (форенсика) в 2026 часто даёт меньше пользы, чем ожидается: часть провайдеров не отправляет, часть редактирует контент, часть компаний не хочет принимать такие данные из-за чувствительных сведений. Если хотите попробовать, начните с отдельного адреса и оцените реальный поток и полезность.
Частые «ломатели» DMARC в проде и как их диагностировать
1) Пересылки и списки рассылок (forwarding)
После пересылки SPF почти всегда ломается (IP меняется), а DKIM может сломаться, если письмо модифицировали (футер, MIME, «антивирусное» перепаковывание). В итоге DMARC fail. Со стороны домена-отправителя базовая задача — чтобы исходные письма были корректно подписаны DKIM и имели шанс пережить пересылку (минимизировать модификации, аккуратнее с футерами/перепаковкой).
2) Отправка «с сайта» через локальный sendmail без DKIM
Если приложение шлёт напрямую, а вы не подписываете DKIM на исходящем MTA, то при p=reject письма начнут отваливаться у части получателей. Два рабочих пути: включить DKIM-подпись на исходящем сервере или перевести отправку на SMTP-шлюз, который подпишет письма вашим доменом и обеспечит корректный alignment. Если сайт живёт на виртуальном хостинге или на VDS, заранее проверьте, какой компонент реально отправляет почту (локальный MTA, relay провайдера, внешний SMTP) и где именно должна появляться DKIM-подпись.
3) Неправильный From в стороннем сервисе
Сервис может позволять указать From: @example.com, но по умолчанию подписывать своим доменом. Снаружи кажется «всё настроено», но DMARC будет fail по DKIM alignment. Проверка простая: смотрите сырые заголовки, ищите Authentication-Results, домен d= и домен envelope-from.
4) Поддомены и забытый sp
Если у вас отправка идёт с поддоменов и вы хотите управлять ими отдельно, используйте sp= в DMARC. Если не используете, помните: политика родительского домена применяется к поддоменам, если у поддомена нет собственной записи _dmarc. «Забытый» поддомен с тестовой отправкой — частая причина неожиданного фейла при ужесточении.
Рекомендуемые DMARC-конфигурации для типовых сценариев
1) «Мы только начинаем, хотим наблюдать»
_dmarc.example.com. TXT "v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:dmarc-rua@example.com; fo=1"Нормально на старте, но поставьте дедлайн, когда перейдёте на quarantine.
2) «Мы почти уверены, хотим мягко закручивать гайки»
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; adkim=r; aspf=r; rua=mailto:dmarc-rua@example.com"3) «Домен под контролем, нужна защита от спуфинга»
_dmarc.example.com. TXT "v=DMARC1; p=reject; adkim=r; aspf=r; rua=mailto:dmarc-rua@example.com"
Чек-лист перед включением reject
Все легитимные источники отправки известны и задокументированы.
Для каждого источника есть DKIM-подпись с выровненным
d=(предпочтительно) или гарантированный SPF alignment.SPF не превышает лимиты и не содержит «мусорных» include от старых сервисов.
RUA собирается и реально просматривается хотя бы раз в неделю.
Политика ужесточалась ступенями через
pct, а не прыжком изnoneвreject.
Итог
В 2026 успешная доставка — это не «настроили SPF и забыли». Работает связка SPF + DKIM + DMARC, где DMARC подтверждает домен в From: через корректный alignment. Начинайте с отчётов, чините источники, поднимайте политику ступенями — и спокойно приходите к p=reject, получая реальную защиту домена от спуфинга и более предсказуемую доставляемость.
Дальше обычно имеет смысл закрепить дисциплину по поддоменам и настроить плановую ротацию DKIM-ключей с учётом TTL, чтобы изменения не превращались в инциденты.
