Покупатель оформил заказ, сайт показал подтверждение, а письмо не появилось. Разработчик говорит: «Отправка прошла успешно». Покупатель проверяет спам. Менеджер повторно нажимает кнопку. В результате писем может стать несколько, а причина первой задержки останется неизвестной.
Доставка почты состоит из отдельных шагов. Поэтому полезнее спросить, на каком шаге остановилось конкретное сообщение, чем сразу менять хостинг или переписывать шаблон.
Разберём условный магазин оборудования: он отправляет подтверждения заказов, уведомления о доставке и отдельную рассылку новинок. Адреса на example.com здесь учебные. Это не отчёт о результатах DDRW, не инструкция для копирования DNS-записей и не обещание доставки каждого письма во входящие.
1. Разделите создание письма, передачу и прочтение
У магазина есть заказ WEB-1042. Его сохранение — событие бизнеса. Задание на уведомление — следующая запись: кому, по какому шаблону и по какому поводу отправить письмо. Уже эти два шага полезно показывать отдельно: сбой уведомления не должен превращать существующий заказ в исчезнувший.
SMTP — протокол передачи почты между системами. Успешный ответ сервера после приёма сообщения означает принятие ответственности за дальнейшую обработку. Это не подтверждение появления письма во входящих. Возможен и последующий отказ с уведомлением о недоставке. Правила передачи описаны в RFC 5321.
В административном интерфейсе магазина стоит различать «ожидает отправки», «передано почтовому серверу», «получен отказ» и «требует проверки». Названия должны соответствовать сведениям, которые действительно доступны системе.
Если почтовый сервис показывает delivered, уточните его определение: обычно речь о принятии сервером получателя, а не о папке «Входящие». Пиксель открытия тоже не доказывает прочтение человеком: изображения могут загружаться автоматически или блокироваться. Службе поддержки нужен понятный статус доставки, а не красивый процент без объяснения метода.
2. Найдите три адреса, которые участвуют в отправке
У одного письма есть несколько доменных идентичностей. Их легко перепутать, потому что покупатель обычно видит только одну.
- Видимый From:
orders@example.com— адрес отправителя в интерфейсе почты. - SMTP MAIL FROM:
bounce@bounce.example.com— адрес обратного пути в почтовом конверте, используемый в том числе для обработки отказов. - DKIM d=:
example.com— домен, которым подписано сообщение.
Для нашего магазина это три отдельные строки в настройках отправки. Их нужно выписать до диагностики: название бренда в шаблоне не показывает, какой домен проверяли почтовые серверы.
MX-запись указывает, куда направлять входящую почту домена. Само её наличие не разрешает серверу отправлять письма от этого домена. Покупка ящика и подключение сайта к отправке тоже могут быть разными задачами.
Практический результат инвентаризации — короткая карточка каждого источника: сайт, CRM, служба поддержки, сервис рассылок. Для каждого указываем ответственного сотрудника, используемые домены и место хранения настроек. Пароли и закрытые ключи в такую таблицу не включаем. Когда подрядчик меняется, эта карточка помогает восстановить картину без доступа ко всем личным кабинетам сразу.
3. SPF отвечает, каким серверам разрешено отправлять
SPF позволяет домену объявить разрешённые источники исходящей почты. При обычной отправке проверяется IP подключившегося сервера относительно домена SMTP MAIL FROM. Сам по себе SPF не подтверждает видимый From. Для одного DNS-имени нельзя публиковать несколько отдельных SPF-записей. Пересылка способна изменить участвующий в проверке сервер и привести к неуспешному результату. Подробности — в RFC 7208.
В магазине разработчик подключил сайт к новому сервису, но старая CRM продолжает отправлять документы. Перед изменением DNS нужно учесть оба источника. Добавление второй «готовой SPF-строки» рядом с первой не заменяет согласованную настройку.
Не копируйте универсальный TXT из статьи. Подрядчик должен объяснить, для какого имени нужна запись и какие реальные системы она разрешает. Желательно сохранить предыдущую конфигурацию и записать причину изменения: через полгода это полезнее скриншота с зелёной галочкой.
Проверять стоит настоящее письмо каждого источника, а не только ответ онлайн-проверки DNS. Внешняя проверка показывает опубликованные правила; заголовки полученного сообщения помогают понять, какое правило участвовало в конкретной отправке. Если проблемы возникают только после переадресации, этот маршрут нужно исследовать отдельно, не расширяя разрешения наугад.
4. DKIM связывает сообщение с подписавшим доменом
DKIM добавляет цифровую подпись выбранных заголовков и тела письма. Получатель находит открытый ключ в DNS по домену подписи и селектору — имени конкретного ключа. Закрытый ключ остаётся у отправляющей системы. Успешная проверка не означает шифрование письма и не доказывает безопасность его содержания. Изменения сообщения при пересылке могут нарушить подпись. Механизм определён в RFC 6376.
Представим, что магазин отправляет подтверждение через сайт, а счёт — через CRM. У этих систем могут быть разные селекторы. Это удобно для управления ключами, но обе отправки нужно проверить самостоятельно: исправная подпись подтверждения заказа ничего не говорит о письме со счётом.
При передаче проекта запросите список действующих селекторов, ответственного за ключи и порядок их замены. Не требуется раскрывать закрытый ключ менеджеру или помещать его в инструкцию для контент-редактора.
Если подпись перестала проходить после подключения нового шлюза, сравните маршрут и преобразования письма. Например, дополнительный сервис мог начать менять содержимое. Не отключайте проверку ради исчезновения ошибки: сначала установите, где сообщение подписывается и что происходит после этого. Такая карта пригодится и при следующем переезде инфраструктуры.
5. DMARC сопоставляет проверенные домены с видимым отправителем
DMARC требует согласования домена видимого From с успешно проверенным SPF-доменом или доменом DKIM d=. Достаточно одного согласованного механизма; успешность обоих не обязательна. Правила strict и relaxed задают строгость сопоставления доменов. Политика p=none не запрашивает особой обработки писем, не прошедших DMARC; quarantine и reject запрашивают соответственно карантин и отказ. Отчётность настраивается отдельно. Окончательное решение принимает получатель; это не гарантия обхода спам-фильтра. Актуальная спецификация — RFC 9989, опубликованная в мае 2026 года взамен RFC 7489.
Начните со списка всех законных отправителей и анализа отчётов. Для магазина забытая система выдачи чеков важнее демонстративно строгой настройки. Проверьте редкие отправки: восстановление доступа, возврат, документы после ручной обработки заказа.
Усиление политики планируйте после разбора источников и несогласованных потоков. На каждом этапе назначьте человека, который проверит рабочие сценарии и сможет исправить конфигурацию. Отчётность полезна, когда её кто-то читает; просто создать адрес для отчётов недостаточно.
6. Служебные сообщения и рассылки требуют разного обращения
Подтверждение WEB-1042 покупатель ждёт сразу после оформления. Подборка новинок — другое ожидание и другая задача. Стоит разделить шаблоны, аудитории, правила отправки и ответственность за эти потоки. Разные поддомены помогают организовать управление, но сами по себе не гарантируют изоляцию репутации.
Покупатель должен понимать, кто пишет, к какому заказу относится сообщение и куда ответить. Проверьте поле Reply-To: ответы не должны уходить в забытый ящик. Не превращайте служебное подтверждение в длинный рекламный каталог, в котором теряются номер заказа и следующий шаг.
У рассылки должен быть рабочий механизм отказа от дальнейших сообщений. RFC 8058 описывает технический контракт отписки одним действием: специальные заголовки и обработку HTTPS POST. Обычная ссылка внизу письма не равнозначна этому механизму. Это технический разбор, не юридическая консультация.
Почтовые системы публикуют и собственные требования. Например, правила отправителей Gmail затрагивают аутентификацию и отписку; применимость требований нужно проверять для своего типа отправки. Это правила Gmail, а не универсальное описание всех почтовых сервисов.
Внутри магазина договоритесь, кто обрабатывает постоянные отказы и исключает неподходящие адреса из дальнейших рассылок. Купленная база и повторная отправка на заведомо неверные адреса не исправляются красивой подписью DKIM.
7. Диагностируйте конкретное письмо по следам
Для обращения «не пришло подтверждение» нужна связка номера заказа, Message-ID, идентификатора SMTP-очереди, времени и получателя. Храните её в защищённом журнале с ограниченным доступом. Не выводите туда пароли, ссылки восстановления и содержимое личной переписки.
Ответ SMTP класса 4xx обозначает временный сбой. Класс 5xx — постоянный отрицательный ответ на запрос: тот же запрос не следует автоматически повторять без устранения причины. Для решения нужен полный код и диагностический текст, а не только красный статус. Учтите поздний bounce — уведомление о недоставке после первоначального принятия сообщения. Повторять отправку без разбора причины не стоит.
Запросите исходные заголовки контрольного письма. Ориентируйтесь на Authentication-Results доверенной принимающей системы, а не на произвольную одноимённую строку: такой заголовок может быть добавлен и на другом участке маршрута. Границы доверия для этих результатов описаны в RFC 8601.
При приёмке используйте несколько согласованных контрольных адресов: разные почтовые сервисы и корпоративную почту. Для каждого сохраните маршрут, результат аутентификации и фактическое расположение письма. Затем отдельно проверьте ответ на сообщение, неверный адрес, временный сбой и повтор задания. Контрольные отправки — часть приёмки, а не повод рассылать письма случайным людям.
Чек-лист приёмки
- Заказ сохранён независимо от результата уведомления; сбой виден ответственному сотруднику.
- Для сайта, CRM и рассылки записаны From, MAIL FROM и домен DKIM.
- SPF согласован со всеми используемыми источниками без второй SPF-записи для того же имени.
- Подписи DKIM проверены на полученных письмах; владельцы ключей и селекторов известны.
- DMARC проверяется на согласование доменов, а изменение политики опирается на инвентаризацию и отчёты.
- Подтверждение заказа понятно на телефоне; Reply-To и отписка соответствующего потока работают.
- Временные ошибки, постоянные отказы и поздние уведомления доступны для разбора без раскрытия секретов.
- Контрольные получатели и сценарии задокументированы; назначен ответственный за последующие сбои.
FAQ
Все проверки прошли. Почему письмо всё равно в спаме?
Аутентификация подтверждает определённые технические свойства отправки. Она не заменяет остальные решения принимающей системы. Разбирайте конкретный маршрут, ожидания аудитории и точные ответы сервера; не обещайте входящие по одной зелёной отметке.
Достаточно ли поменять SMTP-пароль?
Это помогает только при соответствующей проблеме доступа к отправляющему серверу. Если сервер уже принял письмо, новый пароль не объяснит дальнейшую судьбу сообщения. Сначала определите последний подтверждённый шаг.
С чего начать владельцу небольшого сайта?
Попросите подрядчика показать путь одного заказа до контрольного ящика, результаты проверок и место, где видны отказы. Затем зафиксируйте ответственного и порядок действий при жалобе. Это полезный первый результат без перестройки всей почтовой инфраструктуры.
Связанные материалы
- Форма заявки на сайте: что проверить до запуска — путь обращения и работа с ошибками.
- Интеграции сайта без хаоса: как связать CRM и учётную систему — задания, повторы и сверка данных.
- Безопасность сайта: что проверить владельцу бизнеса — доступы, секреты и эксплуатация.
