-
Форма
Обращение сохранено на сайте
-
Отправка
Очередь и ответ SMTP
-
Домен
SPF, DKIM и политика DMARC
-
Получатель
Входящие, спам и отклонения
Если письмо с формы не пришло, проверяйте цепочку по порядку: заявка сохранена → задание отправки создано → SMTP принял сообщение → почта получателя обработала его. SPF, DKIM и DMARC проверяют после этого, а не вместо этого. Правильные DNS-записи не помогут, если обработчик формы вообще не создал письмо.
Убедитесь, что заявка существует
Отправьте одну согласованную тестовую заявку и запишите время, вид формы и её внутренний ID. Сообщение «Спасибо» в браузере недостаточно: интерфейс иногда показывает его до завершения запроса. Проверьте запись в хранилище сайта и статус фоновой задачи. Если записи нет, ищите ошибку валидации, CAPTCHA, JavaScript или серверного обработчика.
Если письмо и CRM вызываются последовательно, сбой Битрикс24 может остановить email. Для важных обращений настройте независимые каналы доставки. Тогда ошибку одного канала можно исправить без повторного создания всей заявки.
Разберите ответ SMTP
В журнале нужны время попытки, ID заявки, категория ответа и следующий шаг. Полное содержимое формы и пароль SMTP туда попадать не должны. Ошибка авторизации, временный отказ сервера и недопустимый адрес требуют разных действий. Не увеличивайте число повторов, пока не поняли причину.
| Наблюдение | Следующий шаг |
|---|---|
| Задание не запускается | Проверить процесс очереди и расписание |
| Не устанавливается соединение | Проверить адрес SMTP, порт, TLS и сетевые ограничения |
| Отказ авторизации | Проверить учётную запись и разрешённый способ входа |
| Временный отказ | Сохранить задание и повторить с увеличенным интервалом |
| SMTP принял письмо | Искать Message-ID, спам, карантин и уведомление о недоставке |
Успешный ответ SMTP означает принятие сообщения конкретным сервером, а не прочтение менеджером. Для точного разбора запросите у почтового администратора поиск по Message-ID. Пересылка скриншота папки «Входящие» не показывает карантин и серверные фильтры.
Проверьте адрес отправителя и ответ клиенту
В поле From используйте контролируемый адрес вашего домена, разрешённый почтовым провайдером. Email посетителя размещайте в Reply-To после валидации. Подстановка чужого домена в From создаёт конфликт аутентификации: сайт не имеет права отправлять от имени почты клиента.
Разделите envelope sender, видимый From и Reply-To в техническом задании. Они участвуют в разных проверках. Это особенно важно, если отправка идёт через внешний сервис, а ответы менеджеров — через корпоративную почту.
Что показывают SPF, DKIM и DMARC
Проверка почтовых DNS покажет MX, опубликованную SPF-политику и DMARC точного домена. Для DKIM потребуется selector — значение s= из заголовка DKIM-Signature тестового письма. Не угадывайте selector по названию провайдера: у одного домена могут работать несколько отправителей.
SPF описывает разрешённых отправителей для проверяемого почтового домена. DKIM позволяет проверить подпись письма. DMARC связывает аутентификацию с доменом видимого From и задаёт политику обработки. Наличие всех трёх записей ещё не подтверждает правильное выравнивание доменов и подпись конкретного сообщения.
Не добавляйте вторую SPF-запись при подключении нового сервиса. Согласуйте единую политику и проверьте её ограничения. Не переключайте DMARC на reject, пока не учтены легитимные рассылки, CRM, формы сайта и сервисы бухгалтерии: иначе можно заблокировать собственные письма. Настройки берите из кабинета конкретного отправителя, а не из случайного примера.
Как принять исправление
Проверьте отправку на согласованные тестовые адреса разных почтовых систем. Сохраните Message-ID, фактические результаты Authentication-Results и место доставки. Затем временно воспроизведите отказ одного канала в тестовом окружении и убедитесь, что заявка сохраняется, повтор выполняется, а менеджер получает уведомление о длительной ошибке.
Добавьте контроль необработанной очереди: количество задач, возраст самой старой и повторяющиеся причины отказа. Проверка раз в месяц не обнаружит поломку, возникшую после смены SMTP-пароля вчера. Для внедрения можно обратиться в техническую поддержку сайта; состав проверки заранее закрепите в ТЗ на доставку обращений.
Какие доказательства собрать до обращения в поддержку
Запишите точное время теста, адрес страницы, номер сохранённого обращения и адрес получателя. Найдите ответ SMTP и идентификатор сообщения, если сервер его выдал. Передавая журнал подрядчику, удалите пароль, токены авторизации и содержимое чужих заявок. Для диагностики обычно важнее этап отказа и код ответа, чем полный текст обращения.
Если письмо дошло в спам, откройте исходные заголовки у получателя. Посмотрите результаты проверки SPF, DKIM и DMARC, домен отправителя и цепочку доставки. Проверка DNS показывает опубликованные записи, но не доказывает, что конкретное письмо было правильно подписано или отправлено с разрешённого сервера. Поэтому исправление записи обязательно подтверждают новым тестовым письмом.
При полном отсутствии письма проверьте адрес назначения, правила пересылки, карантин и журнал принимающей системы. Отправка на второй согласованный тестовый ящик помогает отделить общую ошибку отправителя от особенностей одного получателя. Не рассылайте много одинаковых тестов подряд: достаточно ограниченной серии с различимыми темами и зафиксированным временем.
Учебный пример: адрес клиента поставлен в From
Форма просит email посетителя, и разработчик использует этот адрес как отправителя уведомления. Письмо выглядит удобным для ответа, но сайт не управляет чужим доменом и не может согласовать его почтовую аутентификацию. Правильнее отправлять с адреса собственного настроенного домена, а контакт клиента помещать в Reply-To. Получатель сможет ответить человеку, не подменяя домен отправки.
После изменения проверьте не только новый From, но и фактический SMTP-конверт, DKIM-подпись и результат DMARC у получателя. Не включайте строгую политику вслепую: сначала составьте перечень законных отправителей домена. В него могут входить сайт, CRM, сервис рассылок и почтовые ящики сотрудников. Исправление формы не должно нарушать остальные согласованные отправки.
Завершённая задача содержит воспроизводимый результат: обращение сохранено, попытка доставки выполнена, письмо найдено у получателя, ответ направляется нужному человеку. Если почта временно недоступна, обращение остаётся в базе и в очереди, а повтор выполняется по регламенту. Отдельно задайте срок хранения этих данных и ответственного за неуспешные попытки. Тогда следующая ошибка обнаружится по журналу, а не из жалобы клиента.
