Жалоба выглядит мелкой: «клиент говорит, что письмо о заказе не приходило». Потом выясняется, что не приходило никому и месяц, менеджеры узнают о заказах только из админки, а половина писем о восстановлении пароля улетает в спам. Для магазина это прямые потери, и чинится это не одной кнопкой.
Разберём путь письма целиком: от того момента, как сайт решил его отправить, до папки «Входящие». Теряется оно всегда на одном из шести участков.
1. Письмо вообще не отправлялось
Начинать надо отсюда, а не с настроек DNS. Проверка простая: есть ли на сайте журнал отправленных писем. В 1С-Битрикс это таблица почтовых событий, в Laravel — лог канала почты или запись в базе, в WordPress обычно ничего, пока не поставлен плагин журналирования.
Если журнала нет, его надо завести первым делом. Без него диагностика превращается в гадание: непонятно, письмо не ушло, ушло и не дошло или дошло и улетело в спам. Это три разные поломки с тремя разными решениями.
Частая причина «не отправлялось»: письма шлются через mail(), то есть через локальный sendmail, которого на сервере либо нет, либо он не настроен. Функция возвращает успех — она лишь передала письмо агенту, — а дальше оно молча умирает в очереди. Отсюда ощущение, что сайт отправил, а почта потеряла.
2. Отправка через свой сервер вместо SMTP
Даже если локальный агент настроен, отправка «со своего VPS напрямую» — плохая стратегия. Крупные почтовые провайдеры смотрят на репутацию IP-адреса, и у свежего адреса её нет. Добавьте сюда то, что в том же диапазоне провайдера наверняка когда-то рассылали спам, и письма начинают попадать в спам без всяких ваших ошибок.
Правильно — отправлять через SMTP сервиса, который этой репутацией занимается профессионально: корпоративная почта на вашем домене либо специализированный сервис транзакционных рассылок. У второго есть ощутимый бонус: статистика доставки, открытий и отказов по каждому письму, то есть журнал за вас уже ведут.
Транзакционные письма и рассылки лучше разводить по разным доменам или поддоменам. Если за массовую рассылку домен получит плохую репутацию, вместе с ней просядут и письма о заказах — а это те, которые терять нельзя.
3. SPF: кому разрешено писать от вашего имени
SPF — TXT-запись в DNS домена, которая перечисляет серверы, имеющие право отправлять письма с адресов этого домена. Выглядит так:
v=spf1 include:_spf.example-mail.ru ip4:203.0.113.10 ~all
Три вещи, на которых спотыкаются чаще всего. Первая: запись SPF для домена должна быть ровно одна. Две записи — и проверка возвращает ошибку, то есть становится хуже, чем если бы SPF не было вовсе. Когда подключают второй сервис отправки, его обычно дописывают отдельной строкой — вот и поломка.
Вторая: в SPF не больше десяти обращений к DNS. Каждый include — это обращение, и внутри него могут быть свои. Три-четыре сервиса, и лимит исчерпан, проверка падает.
Третья: окончание. ~all означает «остальным не верьте, но письмо примите с пометкой», -all — «остальных отклоняйте». Строгий вариант ставят в конце настройки, когда уверены, что перечислили все отправители. Иначе первым же отвалится что-то неучтённое: форма с другого сервера, уведомления CRM, рассылка через сторонний сервис.
И важная тонкость: SPF проверяет не адрес из поля «От кого», а конверт — технический адрес возврата. Поэтому сервис рассылок может подставлять свой адрес возврата, и тогда SPF сходится по его домену, а не по вашему. Для получателя письмо при этом выглядит как пришедшее от вас, и связать их — работа DKIM и DMARC.
4. DKIM: подпись, которую нельзя подделать
DKIM — криптографическая подпись письма. Отправляющий сервер подписывает заголовки и тело приватным ключом, публичный ключ лежит в DNS по адресу вида selector._domainkey.вашдомен. Получатель забирает ключ, проверяет подпись и убеждается, что письмо отправлено тем, кто владеет доменом, и по дороге не менялось.
Селектор — это имя ключа, его выдаёт сервис отправки. У каждого сервиса свой селектор, поэтому несколько отправителей живут рядом без конфликтов, в отличие от SPF. Ключ желательно брать на 2048 бит; записи такой длины не влезают в одну строку TXT и разбиваются на части — некоторые панели DNS делают это сами, некоторые требуют вставить уже разбитое значение.
Типичная поломка DKIM: что-то по дороге меняет письмо. Антивирус на сервере дописывает строку в конец, список рассылки добавляет префикс в тему, пересылка переписывает заголовки — подпись перестаёт сходиться. Если DKIM то проходит, то нет, искать надо именно такое вмешательство.
5. DMARC: что делать, если проверки не прошли
DMARC связывает первые два механизма и говорит получателю, как поступать с письмом, которое не прошло проверку. Запись лежит в _dmarc.вашдомен:
v=DMARC1; p=none; rua=mailto:dmarc@вашдомен; adkim=r; aspf=r
Политика p=none — только наблюдать и присылать отчёты, p=quarantine — в спам, p=reject — отклонять. Правильный порядок: начать с none, несколько недель читать отчёты, увидеть по ним всех, кто отправляет от вашего имени, и только потом усиливать политику. Если выставить reject сразу, можно отрезать собственные уведомления и не понять, почему.
Параметры adkim и aspf задают строгость совпадения домена: при r поддомен считается своим, при s домен должен совпасть точно. Для сайта, который шлёт письма с поддомена, это ровно то место, где строгий режим ломает доставку.
- SPF — одна запись, не больше десяти обращений к DNS, окончание ~all до завершения настройки
- DKIM — ключ 2048 бит, селектор от каждого сервиса отправки отдельной записью
- DMARC — начинаем с p=none и адресом для отчётов, усиливаем позже
- Обратная зона (PTR) для IP сервера, если отправляете со своего
- Адрес отправителя — на домене сайта, а не бесплатная почта в поле «От кого»
6. Очередь и момент отправки
Отдельный класс проблем: письма уходят, но не тогда, когда нужно. Если отправка происходит прямо в момент оформления заказа, то недоступный SMTP-сервер превращается в зависшую на тридцать секунд корзину, а иногда и в ошибку оформления. Для покупателя это выглядит как «сайт не работает».
Правильно — складывать письмо в очередь и отправлять фоновым процессом, с повторными попытками при сбое. В Laravel это штатные очереди, в Битриксе — агенты и почтовые события, в WordPress — обычно задача по расписанию, и вот тут засада: встроенное расписание срабатывает только при посещении сайта. На малопосещаемом сайте письмо может ждать часами. Лечится переводом расписания на системный планировщик.
Фоновая отправка требует мониторинга — иначе очередь встанет, и об этом никто не узнает. Минимально: уведомление, если в очереди висит больше N писем или если процесс не отработал дольше получаса. Такие проверки мы заводим в рамках поддержки сайта, вместе с мониторингом доступности и обмена.
Как проверить, что всё сошлось
Отправьте тестовое письмо на ящик у крупного провайдера и откройте исходный текст письма. В служебных заголовках будут результаты проверок — ищите строку с итогами аутентификации: там должно быть, что SPF пройден, DKIM пройден и DMARC пройден. Если какой-то из трёх помечен как провалившийся или нейтральный, дальше гадать не нужно, причина названа.
Второй инструмент — постмастеры почтовых служб. Они показывают по вашему домену долю писем в спаме, жалобы и ошибки доставки. Это единственный способ увидеть картину не по одному тестовому письму, а по всему потоку.
Коды отказа читаются буквально. 550 с текстом про политику — вас отклонили по репутации или DMARC. 421 и 451 — временный отказ, письмо надо повторить позже, и если ваш отправитель этого не делает, письмо потеряно навсегда.
Что ещё влияет, кроме техники
Содержимое письма тоже имеет значение. Письмо из одной картинки без текста, десяток ссылок на разные домены, капс в теме, сокращённые ссылки через внешние сервисы — всё это повышает шансы уехать в спам даже при идеальных DNS-записях.
Для писем, которые по смыслу являются рассылкой, нужен заголовок со ссылкой на отписку: почтовые клиенты показывают по нему штатную кнопку, и человек отписывается вместо того, чтобы нажать «спам». Жалоба на спам бьёт по репутации домена гораздо сильнее отписки.
И ещё одно, что регулярно всплывает в разборе: уведомление менеджеру и письмо клиенту — разные письма с разной судьбой. Первое идёт на корпоративный ящик и обычно доходит. Второе уходит на случайный адрес у любого провайдера и проверяется по всей строгости. Если «письма доходят», проверьте, не о менеджерских ли вы говорите.
Мы настраиваем доставляемость писем на действующих сайтах: журнал отправки, SMTP вместо локального агента, записи в DNS, очередь и мониторинг. Если дело в сервере и почтовой подсистеме целиком, это администрирование. Если письма — часть большей задачи с заказами и оплатой, смотрите разработку интернет-магазина: там почтовые события закладываются вместе со приёмом платежей и статусами заказа.
Как отличить сбой заказа от проблемы доставки письма
Возьмите одно событие: номер заказа, его статус, тип ожидаемого уведомления и время. Если заказ не перешёл в нужный статус, письмо могло не создаваться. Если почтовая система приняла письмо, дальнейшая проверка относится к доставке и фильтрации.
- Проверьте, должно ли выбранное уведомление отправляться при текущем статусе заказа и включено ли оно в настройках.
- Найдите попытку отправки в доступном журнале магазина или почтового сервиса. Состав журналов зависит от версии и настроек.
- Сопоставьте получателя, время и ответ почтового сервера. Успешная передача не гарантирует попадание во «Входящие».
- Проверьте одно письмо на адресе другого почтового провайдера, затем папку спама и причину отказа, если она есть.
- После исправления повторите тот же сценарий и зафиксируйте результат, а не только нажатие кнопки теста SMTP.
Для WooCommerce порядок проверки генерации и доставки письма разобран в официальной инструкции. Если сломана конкретная форма или уведомление, это задача для доработки WordPress/WooCommerce; для других CMS можно обратиться в поддержку.
Если заказ не создаётся или покупатель видит ошибку ещё до уведомления, сначала пройдите диагностику оформления заказа WooCommerce. Почта в этом случае может быть лишь следствием предыдущего сбоя.
