Ошибка DMARC при пересылке: как найти причину

Ошибка DMARC нередко появляется, когда сложная часть настройки кажется завершенной. SPF опубликован. DKIM работает. Политика DMARC наконец установлена на p=quarantine или p=reject. Но затем настоящее письмо пересылают, и оно не приходит. Письмо могло быть легитимным, однако маршрут доставки оказался не учтен в конфигурации.

Так выглядит распространенная проблема с ошибкой DMARC при пересылке. Сообщение настоящее, но промежуточный узел меняет контекст доставки или содержимое, и принимающая сторона больше не получает достаточного результата аутентификации. Если воспринимать SPF и DKIM лишь как галочки в настройках, поведение кажется случайным. Часто у него есть понятная причина, которую можно установить и исправить.

Для базовой настройки сначала изучите почту для бизнеса. Если пересылка уже используется, дополнительно прочитайте материал о пересылке почты.

Что на самом деле означает ошибка DMARC

Ошибка DMARC означает, что для видимого домена From не получен ни успешный выровненный SPF, ни действительная выровненная подпись DKIM. Успешной аутентификации самой по себе недостаточно. DMARC учитывает соответствие проверенного домена тому, который видит получатель.

DMARC опирается на SPF и DKIM. Базовый принцип, описанный в исторической спецификации RFC 7489, состоит в том, что достаточно выполнения хотя бы одного условия:

SPF успешен и выровнен с доменом Header From.
DKIM успешен и выровнен с доменом Header From.

На словах все просто. На практике ошибка DMARC возникает, когда путают три разных вопроса:

Аутентификация: прошел ли SPF или DKIM?
Выравнивание: соответствует ли успешный домен домену Header From?
Сохранность при пересылке: остались ли действительными подписанные части сообщения?

SPF может пройти, а ошибка DMARC все равно возникнет. DKIM тоже может пройти одновременно с ошибкой DMARC. Если успешно проверенный домен не выровнена с нужным доменом, ее результата недостаточно.

Почему пересылка часто вызывает ошибку DMARC

Пересылка способна вызвать ошибку DMARC, поскольку меняет маршрут, а иногда и содержимое. SPF зависит от маршрута, DKIM от подписанных данных. Пересланное сообщение может потерять успешный результат одного метода; неудачные изменения способны затронуть оба.

Типичный маршрут:

Отправитель передает письмо от sender.com.
Промежуточный ящик или шлюз принимает его.
Система автоматически пересылает сообщение в Gmail, Outlook или другой конечный ящик.

После этого принимающий сервер видит в качестве SMTP-клиента уже не исходный IP отправителя, а IP пересылающего сервера.

Именно здесь может возникнуть причина ошибки DMARC.

SPF может перестать проходить первым

SPF определен в RFC 7208. Он проверяет, разрешено ли подключившемуся IP отправлять почту для домена конверта.

При пересылке подключается другой сервер, поэтому SPF может не пройти. SRS переписывает отправителя конверта и может обеспечить успешный SPF для нового домена, но не восстанавливает автоматически выравнивание с исходным From.

Исходный маршрут: sender.com отправляет с IP A. SPF проходит.
Пересылка: посредник передает письмо с IP B. Получатель проверяет sender.com для IP B. Если адрес не разрешен, SPF не проходит.

Неуспешный SPF сам по себе не гарантирует ошибку DMARC. Если выровненный DKIM остается действительным, DMARC все еще проходит. Поэтому надежная настройка DKIM особенно важна.

DKIM может сохранить успешную аутентификацию

DKIM, определенный в RFC 6376, подписывает выбранные заголовки и тело письма. IP пересылающего сервера не влияет на проверку подписи. Это позволяет DKIM сохранить успешный DMARC, когда SPF перестает проходить.

Однако нужны два условия:

Подпись остается действительной после пересылки.
Домен d= выровнен с видимым доменом From.

Если условие нарушено и другого успешного выровненного метода нет, возникает ошибка DMARC.

Пересылающие системы могут вносить небольшие, но значимые изменения:

Добавлять [EXTERNAL] в тему
Добавлять предупреждения или юридические подписи
Переписывать границы MIME
Менять переносы строк или пробелы

Некоторые изменения допускает каноникализация relaxed, другие нет. Шлюзы могут нарушать подпись. Поэтому ошибка DMARC при пересылке может быть следствием реализации, но сама по себе не доказывает ни подделку, ни ее отсутствие.

Ловушка выравнивания без пересылки

Ошибка DMARC возможна и без пересылки. Например, SaaS-сервис аутентифицирует письмо собственным доменом, не выровненным с вашим. Сообщение настоящее, но DMARC может не пройти.

Эту разницу часто упускают при эксплуатации.

Пример:

From: billing@yourcompany.com
Return-Path: bounce.vendor-mail.com
DKIM: d=vendor-mail.com

SPF может пройти для vendor-mail.com. DKIM может пройти для vendor-mail.com. Но DMARC покажет ошибку, если ни одна другая успешно проверенный домен не выровнена с yourcompany.com.

Решение заключается в корректной аутентификации собственного домена. Выровненный DKIM особенно полезен при пересылке, а для прямой доставки может быть достаточно выровненного SPF.

Если вы пересматриваете схему с большим количеством псевдонимов, прочитайте псевдоним доменной почты или ящик. Это помогает выявить скрытые маршруты пересылки и ответственность за них.

Как исследовать ошибку DMARC по заголовкам

Многие случаи ошибки DMARC быстрее исследовать по заголовкам, чем по предположениям. Начните с Authentication-Results, добавленного доверенным принимающим сервером, затем сравните результаты SPF, DKIM и домены выравнивания.

Попросите получателя предоставить полные заголовки. Например:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=pass header.i=@sender.com header.s=mail;
       dmarc=pass header.from=sender.com

Такой результат совместим с пересылкой, при которой SPF перестал проходить, а DKIM сохранился. DMARC успешен, но это не исключает других проблем доставки.

Следующий вариант требует дополнительной проверки:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=fail header.i=@sender.com;
       dmarc=fail header.from=sender.com

Это может быть типичная ошибка DMARC после пересылки: SPF не проходит из-за маршрута, DKIM из-за изменений или изначально недействительной подписи. Только этот результат не устанавливает все причины.

Результат в заголовках	Возможное значение	Действие
`spf=fail`, `dkim=pass`, `dmarc=pass`	Совместимо с обычной пересылкой	Наблюдать; при других симптомах исследовать маршрут.
`spf=fail`, `dkim=fail`, `dmarc=fail`	Пересылка с изменением содержимого или другая проблема DKIM	Проверить подпись, каноникализацию и фактические изменения.
`dkim=pass`, но не выровнен домен `d=`	Возможная проблема выравнивания ESP или ретранслятора	Настроить выровненный DKIM и проверить остальные успешно проверенные домены.
`spf=permerror`	Возможна сложная или некорректная запись SPF	Установить причину, убрать лишние includes; при flattening учитывать обновление IP.
`arc=pass`	Криптографическая проверка цепочки ARC успешна	Оценить доверие к посреднику и политику получателя; это не автоматический успех DMARC.

Как уменьшить ошибки DMARC при пересылке

Запретить людям пересылать письма невозможно. Уменьшать ошибки DMARC лучше за счет схемы, учитывающей пересылку: выровненного DKIM, понятного SPF и маршрута, по возможности сохраняющего подписанные данные.

1. Предусмотрите DKIM для всех потоков

Если важно сохранять аутентификацию легитимной почты при пересылке, выровненный DKIM необходим как надежная опора. Подписывайте все контролируемые потоки, а не только рассылки или ответы поддержки.

Подпись должна быть выровнена с видимым From. Для yourdomain.com подойдет yourdomain.com или соответствующий поддомен при relaxed-выравнивании. Строгий режим требует точного совпадения.

В TrekMail настройка DNS начинается с обязательных записей DNS. Желтый или красный статус нужно исследовать; зеленый тоже не гарантирует успеха любой пересылки.

2. Рассмотрите каноникализацию DKIM relaxed

Каноникализация simple чувствительнее к небольшим изменениям формата, которые могут привести к ошибке DMARC. Relaxed допускает определенную нормализацию пробелов и заголовков, а не любые правки письма.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
 c=relaxed/relaxed; h=from:to:subject:date:message-id; ...

Добавленный в тело длинный блок подписи обычно нарушит проверку и в этом режиме. Допуск ограничен правилами нормализации из спецификации.

3. Проверьте аутентификацию доменов поставщиков

Если CRM, служба поддержки или сервис рассылок подписывает с d=vendor.com, проверьте выравнивание и другие подписи, а не считайте сам домен доказательством ошибки. При отсутствии выровненного DKIM пересылка может лишить письмо успешного SPF и вызвать ошибку DMARC. Настройте собственные DKIM и при необходимости Return-Path. Для успеха DMARC не требуется одновременный успех обоих методов.

4. Сохраняйте SPF понятным и проверяемым

SPF может ошибаться не только при пересылке. Перегруженная конфигурация тоже создает проблемы. RFC 7208 ограничивает число учитываемых механизмов и модификаторов, требующих DNS-поиска при проверке SPF, значением 10, включая соответствующие вложенные элементы. Превышение, а не простое достижение лимита, способно вызвать permerror и исключить успешный путь SPF для DMARC.

dig +short TXT example.com

dig +short TXT _dmarc.example.com

Если в одной записи накопились Google, Microsoft, Mailgun, SendGrid, Zendesk и три старых хостинга, проверьте актуальность источников. Поддомены могут помочь, если они соответствуют фактическим доменам конверта.

5. Понимайте возможности и ограничения SRS и ARC

SRS переписывает отправителя конверта при пересылке и может обеспечить SPF для нового домена аутентификации, но не восстанавливает автоматически исходное выравнивание DMARC. ARC передает предыдущие результаты проверки в проверяемой цепочке. Получатель решает, доверять ли посреднику и применять ли исключение из политики. Эти механизмы не заменяют корректный DKIM.

Рекомендации Google для непрямой доставки различают пересылку и прямую отправку и советуют пересылающим сервисам добавлять ARC. Это не означает общего освобождения от выравнивания DMARC. Для 2025 и 2026 годов проверяйте актуальные правила провайдера и реальные результаты.

При большом числе пересылаемых ящиков выбор платформы имеет значение. По текущей документации TrekMail поддерживает пересылку и инструкции DNS. Материал Bring Your Own SMTP помогает проверить внешние пути отправки и требования к выравниванию.

Прежний и более структурированный подход для множества доменов

При прежнем подходе к ошибкам DMARC иногда добавляют все новые инструменты, пока никто не помнит, кто что подписывает. Более структурированный подход четко разделяет хранение ящиков, доставку и состояние DNS, чтобы причины можно было исследовать.

Прежний подход	Структурированный подход
Оплата за пользователя иногда подталкивает к множеству псевдонимов и пересылок	Тарифы нескольких доменов могут сделать отдельные ящики экономичнее при подходящей нагрузке
Одна большая запись SPF для всех когда-либо подключенных сервисов	Проверенные источники, меньше лишних includes и подходящие поддомены
ESP подписывает не выровненным доменом поставщика	Для каждого легитимного потока проверяется выровненная аутентификация
Проблемы видны только после жалоб	Проверки DNS могут раньше выявлять часть ошибок конфигурации
Перенос ящиков основан на экспортах и неясной процедуре	IMAP копирует данные ящиков, а DNS и аутентификацию отправки переключают отдельно

По действующим тарифам TrekMail может объединять ящики нескольких доменов, предоставлять общее хранилище и отправку через управляемый SMTP или собственного провайдера. Стоимость и пригодность зависят от использования. Сравните почтовый хостинг нескольких доменов и материал о миграции imapsync.

Что делать при обращении об ошибке DMARC

При ошибке DMARC не стоит автоматически менять reject на none. Сначала выясните, связана ли причина с пересылкой, недействительным DKIM или выравниванием. Изменение политики требует учета отправителей, тестов, наблюдения и согласованного плана отката.

Получите полные заголовки от получателя.
Проверьте, относится ли IP соединения с неуспешным SPF к известному пересылающему серверу.
Проверьте результаты DKIM и подписавший домен d=.
Сопоставьте домен подписи с видимым доменом From.
При доверенном посреднике найдите arc=pass и оцените значение для конкретного получателя.
Проверьте SPF на избыток запросов, старые includes и ошибки синтаксиса.

Для TrekMail отправной точкой служат добавление домена для проверки записей и я не получаю письма, если сообщение пропало без видимого возврата.

Вывод: ошибку DMARC можно исследовать системно

Повторяющаяся ошибка DMARC не означает, что почта неисправима. Возможны чрезмерная зависимость от SPF, не выровненный или чувствительный к изменениям DKIM и правки пересылающих систем. Также нужно учитывать неразрешенные источники.

Основные меры просты: подписывать выровненным доменом, сохранять действительность DKIM, поддерживать SPF и тестировать пересылку. Проверяйте реальные потоки и доступные отчеты, учитывая неполноту покрытия.

TrekMail в зависимости от текущего тарифа предлагает ящики нескольких доменов, общее хранилище, IMAP-миграцию, catch-all и разные варианты отправки. По приведенным условиям платные планы начинаются с $3.50 в месяц при годовой оплате; для них может предоставляться бесплатный пробный период на 14 дней; актуальные условия и необходимость карты следует проверить. Nano может быть бесплатным без карты. IMAP переносит данные ящиков, но не DNS или репутацию. Проверяйте тарифы или TrekMail на актуальные условия.

Коротко: если в вашей среде есть пересылка, ошибка DMARC является важным тестовым сценарием. Успешные проверки помогают сделать конфигурацию устойчивее, но не гарантируют результат на любом маршруте или доставку любому получателю.