Кнопка формы показала «Отправлено», заявка сохранилась в админке, но письмо менеджеру не пришло. Это ещё не доказывает сбой почты. Сайт мог вообще не вызвать SMTP, relay мог принять письмо и позже отклонить его, а получатель мог отправить его в спам.
Первое, что я бы сделал, — отправил одно тестовое сообщение с уникальной меткой, например FORM-20260910-0801. Эту метку нужно найти в application log, SMTP log и заголовках письма. Без сквозного ID вы сравниваете разные попытки.
Цепочка доставки и доказательство
| Участок | Что считать доказательством | Что не доказывает успех |
|---|---|---|
| Браузер → backend | Submission ID и HTTP 2xx | Зелёная надпись без записи в журнале |
| Backend → SMTP | Код 250 и message ID | Отсутствие исключения в приложении |
| DNS-аутентификация | SPF/DKIM/DMARC в Authentication-Results | Наличие TXT без проверки синтаксиса |
| Почтовый ящик | Письмо или точный bounce | Проверка только папки Входящие |
Проверьте DNS из двух инструментов
# PowerShell
Resolve-DnsName example.ru -Type TXT
Resolve-DnsName _dmarc.example.ru -Type TXT
Resolve-DnsName selector._domainkey.example.ru -Type TXT
# Windows nslookup
nslookup -type=TXT example.ru
nslookup -type=TXT _dmarc.example.ruИмя selector берите у почтового провайдера. Не подставляйте случайное значение. У SPF должна быть одна политика, начинающаяся с v=spf1. Если записей две, принимающая сторона не обязана угадывать, какую использовать.
Рабочий алгоритм
- Создайте отдельный тестовый адрес и одну отправку с уникальным submission ID.
- Найдите попытку в журнале приложения. Проверьте получателя, From и число SMTP-вызовов.
- Запишите точный ответ SMTP. Код 250 означает принятие relay, но не гарантирует Inbox.
- Проверьте SPF домена, DMARC на
_dmarcи DKIM selector отправителя. - Если письмо дошло хотя бы на один тестовый ящик, откройте «Показать оригинал» и найдите
Authentication-Results. - Сопоставьте pass/fail с доменом в From. Для DMARC нужна согласованность доменов.
- После изменения DNS повторите тест новым ID и сохраните заголовки.
PASS и FAIL
- PASS: один submission ID создаёт один SMTP-вызов и получает message ID.
- PASS: SPF или DKIM проходит, а домен согласован для DMARC.
- PASS: тест принят двумя независимыми почтовыми сервисами либо возвращён точный bounce.
- FAIL: backend отвечает пользователю успехом до результата SMTP.
- FAIL: в DNS опубликованы две записи
v=spf1. - FAIL: From использует домен компании, а DKIM подписан несогласованным доменом провайдера.
Ошибки, которые встречаются чаще всего
Сайт отправляет через локальный mail. На сервере нет управляемого relay, очереди и понятного журнала. Подключите авторизованный SMTP-провайдер и записывайте ответ без credentials.
Новый сервис забыли добавить в SPF. В домене уже разрешена корпоративная почта, но форма шлёт через другой relay. SPF должен включать все легитимные источники.
DMARC включили сразу в reject. Часть старых отправителей не проходит alignment, и рабочие уведомления исчезают. Сначала соберите перечень потоков и отчёты.
Проверяют только адрес менеджера. Его фильтр может скрыть общую картину. Используйте тестовые ящики разных провайдеров и читайте заголовки.
Чек-лист перед запуском формы
- У каждой отправки есть submission ID.
- Приложение сохраняет SMTP-код и message ID.
- SPF-политика одна и включает реальных отправителей.
- DKIM selector опубликован по данным провайдера.
- DMARC включён после проверки alignment.
- Тесты выполнены минимум на двух почтовых сервисах.
Читайте точный SMTP-ответ, а не слово error
Коды 4xx обычно означают временный отказ: очередь может повторить доставку с ограничением. Коды 5xx требуют исправления адреса, политики или аутентификации; бесконечный retry здесь только раздувает очередь. Сохраняйте код, короткий текст ответа и host relay. Пароль, тело письма и данные формы в журнал не нужны.
Проверьте envelope sender отдельно от заголовка From. SPF оценивает домен, связанный с транспортным отправителем, а пользователь видит From. DMARC требует согласования домена, прошедшего SPF или DKIM, с доменом From. Поэтому «SPF=pass» сам по себе не всегда даёт DMARC=pass.
Контроль после изменения DNS
- авторитетные DNS-серверы возвращают новую TXT-запись;
- публичный resolver видит то же значение после TTL;
- в заголовках нового письма изменился Authentication-Results;
- старый тест не используется для оценки новой настройки;
- DMARC-отчёты приходят на рабочий технический адрес.
Не добавляйте в SPF каждый IP из Received-заголовков. Включайте только документированные механизмы провайдера. У SPF есть ограничение на число DNS-поисков; длинная цепочка include может дать permerror даже при правильном синтаксисе.
Для формы используйте адрес вашего домена в From, а email посетителя помещайте в Reply-To после валидации. Подстановка чужого адреса в From часто ломает alignment и делает сайт похожим на отправителя, который подделывает другой домен.
Что делать, если не помогло
Возьмите один message ID и безопасные заголовки без тела письма. Если application log не содержит SMTP-вызова, чините backend. Если relay принял сообщение, но пришёл bounce, разбирайте код принимающего сервера. Если письмо дошло в спам, смотрите Authentication-Results и репутацию отправителя. Отдельно проверьте резервный канал фиксации заявок и маршрут формы до CRM. Мы можем проверить сайт, формы и почтовую доставку до следующего релиза.
