Клиент оплатил заказ, но не увидел подтверждение. Другой третий раз запрашивает восстановление пароля. Заявка с сайта сохранилась, однако менеджер о ней не узнал. На поверхности это сбой почты. Для бизнеса — разрыв в покупке, доступе к аккаунту или обработке лида.
Не начинайте с замены темы письма. Сначала докажите, что приложение создало сообщение, поставило его в устойчивую очередь, отправило от аутентифицированного домена, приняло события провайдера и оставило пользователю другой способ закончить действие. SPF, DKIM и DMARC важны, но это только часть системы.
Уточните, что именно значит «письмо не пришло»
Между кнопкой на сайте и почтовым ящиком есть несколько границ. Статус delivered обычно говорит лишь о том, что сервер получателя принял сообщение. Он не подтверждает папку «Входящие», мгновенное отображение или прочтение. Бывает и обратное: почтовый провайдер ни при чем — приложение не создало задачу, адрес введен с ошибкой, прошлый окончательный отказ (hard bounce) запретил повторные попытки либо ссылка успела истечь.
| Этап | Какие данные нужны | Типичная причина |
|---|---|---|
| Бизнес-событие | Заказ, аккаунт, счет или заявка | Сценарий не запустился |
| Очередь | ID задачи, время, число попыток | Обработчик остановился, задача потеряна |
| Провайдер | Message ID и ответ API | Запрос отклонен или неверно настроен |
| Сервер получателя | Delivered, deferred, bounced, complaint | Домен, репутация, политика или адрес |
| Действие человека | Заказ открыт, пароль изменен, файл скачан | Спам, просроченная ссылка, непонятный текст |
Сотруднику поддержки нужен поиск по номеру заказа или аккаунту, который показывает всю цепочку и не раскрывает лишнее: «создано в 14:03, Outlook дважды отложил, принято в 14:11, доступна повторная отправка». Ответ «с нашей стороны все ушло» не позволяет ни исправить проблему, ни помочь клиенту.
Найдите всех отправителей до изменения DNS
У небольшой компании почти всегда несколько источников. Сотрудники пишут через Google Workspace или Microsoft 365, форма работает из CMS, магазин шлет статусы через Shopify или WooCommerce, платежный сервис — чеки, CRM — цепочки продаж, helpdesk — тикеты, бухгалтерия — счета. При жесткой политике DMARC достаточно забыть об одном легальном сервисе, чтобы его письма начали отклоняться.
Соберите реестр: владелец, назначение, видимый From, домен Return-Path, домен подписи DKIM, провайдер, способ отправки, примерный объем, тип адресатов и обработчик bounce. Проверяйте не только настройки кабинетов и TXT-записи, но и заголовки реально полученных сообщений. Именно там видны итоговые SPF, DKIM и DMARC.
Отправитель: интернет-магазин
Назначение: заказ, отгрузка, возврат
From: [email protected]
Return-Path: bounce.tx.example.com
DKIM: tx.example.com
Провайдер: [название]
Владелец события: ecommerce-команда
Webhook: [endpoint]
Запасной путь: страница заказа + повторная отправкаНе переводите DMARC сразу в p=reject. Сначала соберите отчеты на p=none, классифицируйте источники и выровняйте легитимные. Отдельный почтовый ящик с непрочитанными XML-отчетами не считается контролем — у него должен быть владелец и регулярный разбор.
Учтите действующие требования почтовых сервисов
Правила Gmail для отправителей требуют SPF или DKIM для всех. Если основной домен отправляет более 5 000 сообщений в сутки на личные адреса Gmail, нужны одновременно SPF, DKIM и DMARC, согласованность видимого From, TLS и выполнение дополнительных требований к инфраструктуре и жалобам. Google также поясняет: статус массового отправителя не исчезает просто потому, что объем позже снизился.
Yahoo Sender Hub требует как минимум SPF или DKIM от любого отправителя. Для массовой почты добавляются SPF, DKIM, согласование DMARC, корректный DNS, низкий уровень жалоб и удобная отписка от маркетинговых и подписных сообщений. В FAQ Yahoo транзакционные письма вроде подтверждения заказа и сброса пароля исключены из требования отписки одним кликом.
Microsoft ввела сопоставимые требования SPF, DKIM и DMARC для доменов, отправляющих более 5 000 писем в день на потребительские адреса Outlook.com. Официальное сообщение Microsoft относится к outlook.com, hotmail.com и live.com; конкретный порог нельзя без оговорки приписывать всем корпоративным ящикам Microsoft 365.
Даже если ваш сайт отправляет сотню писем, а не пять тысяч, разумный минимум тот же: аутентифицировать production-почту, поддерживать исправную инфраструктуру и следить за репутацией. Соблюдение порога — условие допуска, но не обещание попадания во «Входящие».
Настройте SPF, DKIM и DMARC как одну систему
- SPF перечисляет системы, которым разрешено отправлять для домена envelope sender. У домена должна быть одна согласованная SPF-политика без давно отключенных сервисов.
- DKIM подписывает сообщение доменом под вашим контролем. Проверяйте подпись в полученном письме, а не только статус в панели поставщика.
- DMARC требует согласования видимого From с доменом, который успешно прошел SPF или DKIM, задает политику обработки и адрес отчетов.
- DNS и транспорт включают правильные A/PTR-записи для собственных IP-адресов отправки, согласованные имена серверов и TLS. У управляемого провайдера часть этого слоя находится под его контролем.
В спецификации DMARC есть принципиальная деталь: протокол добавляет согласование доменов, политику и отчетность поверх SPF и DKIM. Сообщение может пройти SPF для технического домена сервиса, но провалить DMARC, если этот домен не согласован с адресом From, который видит человек.
p=none подходит для этапа наблюдения, но не должен превращаться в вечную имитацию защиты. Установите владельца отчетов, уберите неизвестные источники, настройте действующие, проверьте пересылку и особенности провайдеров. Затем постепенно применяйте quarantine и reject. Не вставляйте TXT-запись из чужого чек-листа: include, selector, Return-Path и адрес отчетов должны соответствовать вашим системам.
Разделите сервисные письма и рассылки
Проблемы рекламной базы не должны мешать восстановлению доступа. Разведите сообщения по потокам и, если это оправданно, по родственным поддоменам вроде tx.example.com и news.example.com. При этом клиенту нужен узнаваемый отправитель, ответы должны попадать в живую очередь, а домены DMARC — оставаться согласованными.
Amazon SES рекомендует отдельные поддомены для транзакционной и маркетинговой почты, чтобы они формировали раздельную репутацию. Разведите также правила запрета повторных отправлений, жалобы и показатели. Жалоба на рекламу прекращает рекламу этому получателю; обязательное обновление по оформленному заказу может обрабатываться по другой политике. Категория письма должна быть честной — добавленный баннер не превращает рекламу в транзакцию.
Не дробите домен до бесконечности. Стабильная архитектура полезнее ежемесячного «чистого старта». Не меняйте одновременно домен, провайдера, IP, имя From и частоту: иначе при ухудшении доставки не останется контрольной точки.
Соберите устойчивый контур отправки
Оформление заказа не должно зависеть от того, ответил ли в эту секунду внешний почтовый API. Сначала сохраните заказ и запись о будущем письме в одной надежной операции. Затем фоновый обработчик заберет событие из журнала исходящих событий (outbox) или очереди. Успех на сайте означает, что бизнес-транзакция записана, а не то, что Gmail уже принял письмо.
Бизнес-запись → outbox или очередь → шаблон и локаль → провайдер → подписанный webhook → история статусов → алерт или запасной сценарий.
- Постоянный ID события не дает повторной попытке создать два одинаковых подтверждения.
- Временные отказы повторяются с увеличивающейся паузой; постоянный bounce не повторяется бесконечно.
- Provider message ID связывается с заказом, аккаунтом, счетом или лидом.
- Подпись webhook проверяется, а повторная доставка одного события безопасна.
- Версии шаблонов сохраняются, чтобы поддержка могла восстановить контекст.
- Логи не содержат токены и лишние персональные данные.
Для важных писем WordPress не стоит полагаться на непрозрачную локальную почтовую функцию. Подключите надежного транзакционного провайдера или правильно управляемый почтовый сервер, аутентифицируйте домен и сделайте сбои приложения наблюдаемыми. SMTP-плагин может исправить маршрут. Он не проводит инвентаризацию, не гарантирует согласование DMARC, не обрабатывает отказы и не создает мониторинг.
Оставьте в шаблоне одну понятную задачу
В письме для смены пароля сразу назовите сервис и причину, поставьте одну главную кнопку, укажите срок действия, объясните, что делать при чужом запросе, и дайте безопасный канал поддержки. Акции и подборка товаров здесь мешают человеку и размывают назначение сообщения.
Подтверждение заказа должно содержать номер, точные позиции и суммы, состояние оплаты и исполнения, следующий шаг и ссылку на защищенную страницу статуса. Нужны HTML и читабельная текстовая версия, абсолютные HTTPS-ссылки на ожидаемом домене, стабильные From и Reply-To. Если письмо предлагает ответить, этот адрес обязан кто-то читать.
Русскую версию редактируйте отдельно: естественные статусы оплаты, сборки, доставки и возврата, правильные даты, валюты и формы имен. Не оставляйте «Ваш order shipped» из смешанного шаблона. Для всего процесса магазина — платежей, checkout, доставки и QA — используйте план запуска интернет-магазина Rendframe.
Обрабатывайте статусы и ошибки
Принятие провайдером, доставка, задержка, окончательный отказ, отклонение, жалоба и отписка означают разные вещи. Это видно, например, в документации Amazon SES по событиям отправки. После окончательного отказа адрес следует заблокировать для повторных попыток до исправления или безопасной проверки. Временная задержка остается видимой и обрабатывается по правилам.
Считайте по каждому потоку и почтовому провайдеру: принятые запросы, время от заказа до принятия письма, задержки, окончательные отказы, жалобы, опоздание вебхуков, глубину очереди, возраст самой старой задачи и завершение целевого действия. Пиксель открытия не дает надежного доказательства чтения и бывает неуместен в чувствительных письмах.
Оповещение нужно не только при всплеске, но и при тишине. Если в магазине идут заказы, а подтверждений за час нет, это инцидент. Если вебхуки перестали приходить, ровный ноль на графике означает потерю наблюдаемости, а не отсутствие проблем.
Предусмотрите путь без письма
Письмо подтверждает операцию, но не должно быть единственным ее следом. После оплаты покажите номер заказа и следующие шаги на сайте. В личном кабинете дайте проверить статус и запросить контролируемую повторную отправку. Поиск гостевого заказа не должен позволять проверять, зарегистрирован ли произвольный адрес.
Для восстановления пароля нужны rate limit, одноразовые токены с коротким сроком, нейтральный ответ без раскрытия существования аккаунта и безопасная помощь тем, кто потерял доступ к ящику. У повторного запроса должна быть ясная политика относительно старой ссылки. Сотрудник поддержки не должен вручную пересылать reset token.
Заявку с формы сначала сохраняйте в CRM или рабочей очереди. Письмо менеджеру — уведомление, а не база данных. Иначе один фильтр превращает реальный интерес клиента в невидимую потерю.
Проведите аудит по 12 пунктам
- Перечислите приложения, рабочую почту, CRM, платежные и сторонние сервисы, отправляющие от ваших доменов.
- По заголовкам сопоставьте From, Return-Path, SPF, DKIM и согласование DMARC.
- Разделите транзакционный и маркетинговый потоки, владельцев, запреты повторных отправлений и метрики.
- Проверьте, что домен, аккаунты провайдера и ключи вебхуков контролирует компания.
- Перенесите критические письма в устойчивый outbox или очередь.
- Добавьте защиту от дублей, ограниченные повторные попытки, очередь ошибок и управляемый повторный запуск.
- Проверяйте подписи webhook и связывайте события с бизнес-записью.
- Обрабатывайте окончательные отказы, задержки, жалобы и запреты повторной отправки с учетом категории.
- Отправьте реальные шаблоны на Gmail, Outlook, Yahoo, Apple Mail и важные региональные сервисы.
- Проверьте мобильную верстку, текстовую версию, доступность, локали, ссылки, срок действия и ответы.
- Настройте графики и алерты по очереди, тишине, задержкам, bounce, жалобам и целевым действиям.
- Для каждого критического сообщения сделайте страницу статуса, безопасный resend или человеческий резерв.
Тестируйте на новых аккаунтах и production-подобных заказах, затем повторяйте после изменений DNS, провайдера, шаблонов и аутентификации. Seed-ящики полезны для диагностики, но не дают универсальной оценки inbox placement.
Частые вопросы
Почему письма с сайта попадают в спам?
Возможны ошибки аутентификации или согласования доменов, но проверьте весь путь: создание события, очередь, ответ провайдера, репутацию, качество адресов, статусы, шаблон и общий поток с рассылками.
Гарантируют ли SPF, DKIM и DMARC «Входящие»?
Нет. Они подтверждают разрешенный и согласованный домен, задают политику и отчеты. Почтовый сервис также оценивает репутацию, жалобы, инфраструктуру, содержание, поведение адресатов и динамику отправки.
Что означает delivered в панели провайдера?
Как правило, сервер получателя принял сообщение. Это не доказательство папки «Входящие» или чтения. Сопоставляйте почтовый статус с бизнес-результатом: заказ просмотрен, пароль изменен, документ открыт.
Нужна ли отписка в письме о заказе?
Чистое подтверждение заказа или сброс пароля не равно маркетинговой подписке. Не добавляйте туда рекламу. Для рассылки нужны отдельные ожидания, предпочтения и механизм отписки по действующим требованиям.
Исправит ли SMTP-плагин письма WordPress?
Он может направить сообщения через подходящего провайдера, и это часто необходимо. Но отдельно остаются DNS и согласование доменов, полный список отправителей, обработка отказов, защита от дублей, наблюдение за очередью и запасной путь для человека.
Относитесь к почте как к части продукта
Надежность не измеряется скриншотом DNS или максимальным баллом spam tester. Бизнес-событие должно сохраниться, письмо — один раз попасть в очередь, домен — пройти аутентификацию, статусы — вернуться в систему, сбой — получить владельца, а пользователь — иметь возможность закончить действие.
Rendframe может проверить почту сайта или магазина от событий приложения и DNS до провайдера, шаблонов, вебхуков, панели мониторинга и запасного сценария. Посмотрите услугу продуктового инжиниринга или принесите один пример потерянного подтверждения либо восстановления пароля для предметного аудита.