2026: Письма с заказами независимого магазина попадают в спам — сначала проверять SPF или DKIM?

Для владельцев магазинов: если покупатель не получил подтверждение заказа или уведомление об отправке, вы сможете отделить отсутствие срабатывания от проблем доставки.
Для технических специалистов и администраторов нескольких доменов: материал поможет проверить источники отправки, DNS-аутентификацию и адрес From, прежде чем менять записи.

Последнее обновление: 5 ноября 2026 года. Данные сверены с руководством Google для отправителей, RFC 9989 и документацией WooCommerce по неполученным письмам, почтовым сервисам и аутентификации.

Доставляемость писем: сначала разделите отсутствие отправки и отказ доставки

Если письмо не пришло, это ещё не доказывает ошибку SPF. У цепочки есть несколько отдельных этапов: магазин должен создать уведомление, приложение должно передать его почтовому сервису, тот должен принять запрос и отправить сообщение, а сервер получателя — принять или отфильтровать его. Ошибка на каждом этапе выглядит для покупателя одинаково: письма нет.

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

Разделите ситуацию по наличию записи:

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

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

Шаг первый: проверьте, создал ли магазин уведомление

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

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

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

Если запись сервиса есть, сохраните точный статус, ответ получателя и идентификатор сообщения. Не трактуйте «принято к обработке» как подтверждение доставки в папку «Входящие»: запросите у поставщика расшифровку статуса, если она неясна.

SPF: проверьте авторизацию фактического источника, а не чужой шаблон

SPF позволяет домену сообщить, какие источники отправки уполномочены передавать почту от его имени. Но значение записи зависит от фактического сервиса, используемого магазином. Возьмите требуемые параметры в его панели или официальной инструкции по настройке стороннего сервиса, затем сравните их с DNS именно того домена, который участвует в отправке. Общий принцип задан в RFC 7208.

Проверьте четыре вещи:

• опубликована ли SPF-запись для правильного домена;
• включён ли в неё текущий источник отправки согласно инструкции сервиса;
• не осталось ли нескольких независимых SPF-записей для одного домена;
• не потеряли ли вы другие действующие источники — например, отдельный сервис для транзакционных уведомлений или рассылок.

Если DNS содержит несколько SPF-записей, не объединяйте их механически: сначала составьте список всех легитимных источников и сверьте требуемый формат с инструкцией сервиса. Также учитывайте ограничение SPF на DNS-запросы: стандарт устанавливает предел в 10 таких операций при проверке политики; подробности приведены в RFC 7208. Сложная запись, которая включает много внешних доменов, может не пройти проверку даже при наличии нужного источника.

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

DKIM и From: успешная подпись ещё не означает согласование доменов

DKIM добавляет к сообщению криптографическую подпись, связанную с доменом подписанта и DNS-ключом. Проверяйте не только то, что сервис включил DKIM, но и результат проверки в заголовках конкретного письма: какая подпись присутствует, какой домен указан и прошла ли проверка. Стандарт описан в RFC 6376.

Затем сравните домен подписи DKIM с доменом видимого адреса From. Здесь важно различать два понятия: «подпись DKIM действительна» и «подпись согласована с From для DMARC». Первое подтверждает результат проверки подписи, второе относится к связи доменов. Аналогично SPF может пройти собственную проверку, но не дать нужного соответствия домену From.

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

Требования платформы также нельзя автоматически распространять на всех получателей. Например, руководство Google различает общие требования для отправителей и дополнительные требования для отправителей, превышающих 5 000 сообщений в день на личные аккаунты Gmail; оно отдельно описывает SPF, DKIM, DMARC и согласование доменов. Проверьте применимость по актуальной инструкции Google, а не принимайте условия одной платформы за единое правило всех почтовых систем.

DMARC: сначала инвентаризация отправителей, затем политика

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

RFC 9989 опубликован в мае 2026 года и заменил документы RFC 7489 и RFC 9091. Это обновление стандарта само по себе не означает, что магазин обязан менять способ отправки или переходить на собственный почтовый сервер. Чтобы определить, влияет ли новая редакция на вашу реализацию, сопоставьте её с текущей конфигурацией, документацией сервиса и результатами проверки.

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

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

Если аутентификация успешна, проверьте получателя, контент и ответ сервиса

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

Попросите получателя проверить спам и карантин, а при возможности — открыть заголовки сообщения. Сверьте их с записью сервиса и временем теста. Если сервис зарегистрировал отказ, временное ограничение или иной ответ, передайте поставщику точный текст и идентификатор сообщения. Общая формулировка «клиент ничего не получил» для расследования менее полезна, чем конкретный статус.

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

Используйте следующий порядок действий в зависимости от доказательств:

• Нет записи о передаче в почтовый сервис — проверьте событие заказа, настройки уведомления и журнал приложения; DNS пока не меняйте.
• Есть запись отправки и подтверждён сбой SPF или DKIM — сверяйте DNS и подпись с инструкцией именно фактически используемого сервиса, затем повторите тест.
• SPF или DKIM проходят, но DMARC не согласован — сравните домены From и результата SPF/DKIM, после чего проверьте политику и список источников.
• Аутентификация проходит, но получатель не видит письмо — проверьте его папки и заголовки, запросите у сервиса статус и ответ принимающей стороны.
• Журнал показывает отказ, который вы не можете объяснить, — отправьте поставщику время события, идентификатор сообщения, получателя и полный текст ответа, предварительно убрав конфиденциальные данные.

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

Где заканчивается почтовая настройка и начинается инфраструктура

Настройка DNS и отправки выполняется в связке домена и выбранного стороннего почтового сервиса. Аренда сервера не добавляет отправителя в SPF, не выпускает DKIM-подпись и не определяет решение почтового оператора о папке доставки. Поэтому не выбирайте сервер как способ «исправить репутацию» или гарантировать попадание писем во входящие: для такого обещания нет оснований.

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

Для сайтов, которым нужна независимая среда приложения и стабильная работа под собственным управлением, можно рассмотреть выделенный физический сервер OSFP Cloud в Японии, в Токио. Но это решение относится к размещению магазина, а не к отправке почты: доменная авторизация и фактическая доставка по-прежнему зависят от стороннего сервиса, DNS и почтовой системы получателя. Общая облачная среда может означать соседнюю конкуренцию за ресурсы, тарифы с отдельным учётом трафика или ограничения на настройку окружения; физический сервер имеет смысл сравнивать по этим условиям и требуемому уровню контроля, а не как замену почтовому провайдеру.

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

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

Что проверять первым, когда письма с заказами попадают в спам?

Начните с журнала стороннего сервиса и установите, было ли сообщение передано ему. Если записи нет, исследуйте событие заказа и приложение. Если запись есть, сохраните статус доставки и заголовки тестового письма, после чего проверьте SPF, DKIM и соответствие DMARC. Это помогает не менять DNS из-за сбоя, который на самом деле возник до отправки.

Сервис показывает отправку, а покупатель не видит письмо — как продолжить?

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

Нужна ли доменная настройка, если используется сторонний почтовый сервис?

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

Почему успешная проверка DMARC не гарантирует попадание во входящие?

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

Вопросы

С чего начать, если письма с заказами оказываются в спаме?

Сначала откройте журнал стороннего сервиса и установите, было ли письмо принято к отправке. Если записи нет, проверьте событие заказа, настройки уведомления и журнал приложения. Если запись есть, сохраните результат доставки и заголовки тестового письма, после чего сравните SPF, подпись DKIM и домены From. Менять DNS до такого разделения причин обычно преждевременно.

Что проверять, если сервис показывает отправку, а покупатель письма не получил?

Статус «отправлено» у сервиса не всегда означает, что сообщение оказалось во входящих: оно могло быть отклонено, помещено в карантин или отфильтровано получателем. Запросите у покупателя адрес, примерное время и папки спама и карантина; в журнале сервиса найдите SMTP-ответ или другой статус доставки. Затем проверьте заголовки теста у нескольких адресатов.

Нужны ли SPF и DKIM при отправке через сторонний почтовый сервис?

Обычно стороннему сервису требуется доменная авторизация, но точные записи и способ настройки зависят от его документации. Используйте значения именно для подключённого аккаунта и домена отправителя, а не записи из чужого руководства. Проверьте, что SPF не опубликован несколькими отдельными записями для одного имени, а DKIM-подпись присутствует в заголовке реального тестового письма.

Почему письмо может попадать в спам, если DMARC прошёл проверку?

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