Почему после DMARC p=reject счета не доходят клиентам

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

Что именно делает DMARC p=reject

DMARC — правило, которое помогает принимающей стороне решить, что делать с письмом, если его проверка не прошла. При политике p=reject владелец домена просит отклонять такие сообщения. Это не команда «все письма домена доставлять во входящие» и не гарантия, что письмо, прошедшее проверку, минует спам-фильтр. Я объясняю это клиентам до изменения записи: политика защищает домен от части подделок, но не управляет всей логикой доставки.

Здесь важно различать два результата. Сервер может отклонить сообщение, не прошедшее DMARC, ещё до попадания во входящие. А письмо, которое прошло DMARC, всё равно может оказаться в спаме по другим причинам. Среди них могут быть настройки SPF или DKIM, PTR, репутация отправляющего сервера и оценка содержимого принимающей стороной. В предоставленных фактах эти причины перечислены как возможные, а не как универсальный диагноз. Поэтому фраза «включили reject — теперь спам» описывает совпадение по времени, но ещё не доказывает причину.

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

Условный пример — студия «Янтарь». Сотрудники отправляют письма через корпоративную почту, а счета формируются отдельной системой. После включения строгой политики клиенты сообщают, что часть счетов не пришла. Я не объявляю DMARC виновником по одному такому сообщению: сначала сравниваю обычное письмо и счёт, затем проверяю, совпадают ли у них отправляющий сервер и результаты аутентификации. Пока этих данных нет, корректный вывод один: нужно установить, на каком этапе пропадает конкретное письмо. Ироничная версия диагноза — «почта сломалась». Техническая версия полезнее.

• p=reject просит отклонять письма, не прошедшие DMARC.
• Успешный DMARC сам по себе не обещает попадание во входящие.
• Разные системы отправки могут давать разные результаты проверки.

Почему после включения политики перестают доходить счета

Самая частая управленческая ошибка — считать домен одним отправителем. На деле письма могут уходить через корпоративный почтовый сервер, сайт, систему выставления счетов, службу рассылок или оборудование, которое давно никто не вспоминал. Если хотя бы один такой источник отправляет от имени домена, но не соответствует требованиям DMARC, при p=reject принимающая сторона может отклонить его сообщение. Настройка основного почтового ящика при этом может быть исправна.

В студии «Янтарь» я бы начал с конкретного недоставленного счёта: кто его сформировал, какой адрес указан отправителем, какой сервер передал письмо и что сообщила принимающая сторона. Затем сопоставил бы его с обычным письмом от сотрудника. Если обычное письмо проходит, а счёт нет, это сильная зацепка в пользу отдельного потока отправки, но ещё не окончательное доказательство. Причину подтверждают сведения о конкретном сообщении и проверках, а не предположение по типу приложения.

Второй источник путаницы — разные формулировки пользователя. «Не дошло» может означать отказ отправки, возврат с уведомлением об ошибке, задержку, попадание в спам или отсутствие сообщения у адресата без видимой причины. Это разные сценарии. Я прошу сохранить уведомление о недоставке целиком и уточнить адрес получателя, время отправки и тип письма. Такие сведения помогают отличить отклонение политикой от проблем маршрута и фильтрации.

Третий фактор — ожидание, что p=reject исправит доставляемость. Политика предназначена для обработки проваливших DMARC писем. Она не служит средством повышения репутации и не заставляет почтовые сервисы считать любое сообщение безопасным. Если аутентификация проходит, а письмо оказывается в спаме, отдельно проверяют SPF, DKIM, DMARC, PTR и прочие причины фильтрации. Источники из брифа прямо связывают попадание в спам или недоставку с ошибками этих настроек; это повод проверить их, а не менять всё сразу.

Я отдельно проверяю, не отправляет ли кто-то письма с доменом «в обход» штатной почты. Это может быть не злой умысел, а забытая интеграция. Политика обнаруживает несоответствие, но сама не сообщает администратору, какая именно система его создала. Поэтому список отправителей и тестовое письмо от каждого потока дают больше пользы, чем спор о том, «правильно ли вообще включать reject».

• Разделите потоки: сотрудники, счета, сайт и прочие системные письма.
• Сохраните уведомление о недоставке и данные конкретного сообщения.
• Не принимайте попадание в спам за доказанный DMARC reject.

Как найти источник сбоя без догадок

Начинаю с инвентаризации исходящей почты. Уточняю у сотрудников и ответственных за сайт и учётные системы, какие сервисы отправляют сообщения с адресами домена. Важно включить не только массовую рассылку, но и письма, которые уходят редко: счета, подтверждения заявок, уведомления о смене пароля. В маленькой компании такой перечень обычно можно собрать разговором с ответственными, но нельзя считать его полным, пока не сверили реальные потоки.

Затем беру несколько примеров: одно письмо, которое доставилось, и одно, которое не дошло или попало в спам. Сравниваю отправителя, маршрут и доступные результаты проверок. Если получатель сообщил об отклонении, его ответ помогает понять, связано ли оно с DMARC. Если письмо принято, но помещено в спам, искать нужно также в настройках и оценке принимающего сервера. Не нужно делать вывод по одному общему сообщению «письмо не пришло».

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

Если у домена нет отчётности или журнала, позволяющего увидеть, кто отправляет от его имени и где проверка не проходит, это ограничивает расследование. Тогда я прямо обозначаю предел уверенности и собираю данные по реальным письмам. Выдумывать виновника по названию сервиса или по дате изменения записи — плохой способ администрировать почту. DNS не читает мысли, а администратор не обязан их угадывать.

• Составьте перечень всех легитимных отправителей домена.
• Сравните доставленное письмо и проблемное сообщение по маршруту и проверкам.
• Исправьте обнаруженный поток, затем проверьте его повторно.

Как вернуть доставку и сохранить защиту домена

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

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

Я не предлагаю в ответ на жалобу без разбора добавлять любой найденный сервер в разрешённые источники. Это переносит ошибку в DNS и может разрешить отправку лишним системам. Сначала подтверждаем владельца потока и назначение письма, потом выбираем изменение. Если результат неясен, сохраняем исходное состояние и собираем данные. В почте аккуратная проверка быстрее, чем откат нескольких несвязанных правок.

Для контроля прошу проверить не одно письмо, а каждый важный тип: переписку сотрудника, счёт, письмо с сайта и другие реально используемые уведомления. Получатели и принимающие сервисы могут вести себя по-разному, поэтому удачный тест на одном адресе не доказывает исправность всей почты. Итог фиксирую простыми словами: какие потоки проверены, что изменено, что ещё требует наблюдения. Так руководство понимает, вернулись ли счета, а администратор — что именно он поддерживает.

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

Что проверить, если письмо всё ещё в спаме

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

Попросите адресата проверить папку спама и, если возможно, предоставить уведомление или сведения о сообщении. Уточните, происходит ли проблема с одним получателем или с разными, с одним типом письма или со всеми. Эти наблюдения сужают область поиска. Если принимающая сторона не даёт технических подробностей, честно зафиксируйте это ограничение и продолжите с доступными данными.

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

Для студии «Янтарь» вывод должен быть проверяемым: счета передаются через ожидаемый маршрут, результаты аутентификации соответствуют настройкам, а получатель больше не сообщает о прежнем сбое. Если письмо всё ещё попадает в спам при успешной DMARC-проверке, это отдельная задача по доставляемости, а не основание объявлять reject поломанным. Иронично, но почтовые фильтры не обязаны уважать уверенность администратора.

• Уточните, проходит ли DMARC для проблемного письма.
• Проверьте SPF, DKIM и PTR для фактического отправителя.
• Сравните результаты у разных получателей и для разных типов сообщений.

Как не повторить сбой после изменений

Перед изменением записи сохраните её текущее значение и запишите, кто согласовал правку. Составьте список ожидаемых отправителей и назначьте ответственного за каждый: почта, счета, сайт и системные уведомления. Это простая дисциплина, которая позволяет спустя время понять, почему домен отправляет конкретное письмо и к кому идти за настройкой.

После исправления проверьте каждый поток на практике и попросите получателей подтвердить результат. Не ограничивайтесь тестом из почтового клиента администратора: он не проверяет стороннюю систему, отправляющую счета. Если такая система меняется, включайте проверку исходящей почты в процедуру её запуска. Тогда строгая политика останется средством защиты, а не неожиданным экзаменом для бухгалтерии.

Я выбираю понятный журнал изменений и периодическую сверку отправителей вместо надежды на то, что конфигурация навсегда останется прежней. Сайты и интеграции меняются, доступы и подрядчики — тоже. При любом изменении, связанном с почтой, проверяйте отправку от домена. Это не бюрократический ритуал; это способ узнать о проблеме на тесте, а не из письма клиента со словами «счёт так и не пришёл».

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

• Ведите актуальный список легитимных отправителей домена.
• Проверяйте почтовый поток после изменений сайта и учётных систем.
• Сохраняйте запись о правках и подтверждение тестовой доставки.

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