Как проследить письмо WordPress от события формы до ящика: транспорт, разрешённый From, журнал, аутентификация домена, очередь, коды отказа и проверка после исправления.
Зафиксируйте одно сообщение
Выберите согласованный адрес получателя и одно действие: тест формы, уведомление или восстановление доступа. Запишите время, отправителя и тип события. Не отправляйте десятки повторов и не используйте реальные клиентские адреса для диагностики.
Уточните, возникает ли письмо в приложении. Если событие не создаётся, SMTP не исправит логику формы. Если создаётся, исследуйте результат передачи. Возвращённый wp_mail успех означает принятие запроса механизмом отправки, а не гарантию попадания во входящие.
Настройте поддерживаемую отправку
Используйте способ, разрешённый вашим почтовым поставщиком: SMTP или другой документированный канал. Сервер, порт, шифрование и учётные данные берутся из вашего кабинета. Не копируйте настройки из чужого аккаунта и не отключайте проверку сертификата.
Не храните пароль в публичном репозитории или скриншоте. Отдельная техническая учётная запись с ограниченными правами упрощает отзыв. Проверьте, разрешено ли отправлять с выбранного From: сервис может требовать подтверждение домена или адреса.
Найдите последний подтверждённый этап
Письмо проходит несколько стадий: событие создаётся плагином, передаётся транспорту, принимается почтовым сервисом, доставляется серверу получателя и размещается по его политике. Успех на раннем этапе не доказывает следующий. Ищите последнюю подтверждённую точку по времени и идентификатору, а не меняйте SMTP-пароль при любом отсутствии письма.
| Последний факт | Куда смотреть дальше |
|---|---|
| Форма не создала событие | Валидация, условия отправки, обработчик формы |
| Есть вызов, транспорт вернул ошибку | Адрес сервера, сеть, TLS, аутентификация |
| Сервис принял письмо | Очередь, лимиты и последующий ответ получателя |
| Получатель отклонил | Код и текст отказа, домен и политика |
| Сообщение в спаме | Заголовки, содержание и репутация |
| Письмо получено, ответ не идёт | Reply-To и входящая схема адреса |
Для восстановления доступа не используйте в тесте неизвестные адреса пользователей. Применяйте собственную согласованную запись и ящик. Сохраняйте обезличенный идентификатор сообщения и технический результат. Полный текст обращения клиента обычно не нужен для проверки сетевого соединения и должен оставаться вне общего журнала.
Разделите From, Reply-To и технический возврат
Посетитель формы не должен автоматически становиться неподтверждённым From на вашем сервере. Для отправки используйте адрес, разрешённый почтовым сервисом, а нужный адрес ответа задавайте по поддерживаемой логике формы. Иначе письмо может выглядеть как подделка чужого домена. Проверьте фактически полученные заголовки, потому что транспорт способен нормализовать отправителя.
Технический адрес возврата и видимый From могут отличаться. SPF, DKIM и DMARC оценивают связанные, но разные свойства. Не считайте любое pass окончательным подтверждением всех проверок. Сверьте Authentication-Results у доверенного получателя и действующую инструкцию своего поставщика. В 2026 году актуальная основа DMARC — RFC 9989, а не заменённый RFC 7489.
Идентификатор теста: SMTP-DEMO-001
Источник: кнопка теста / реальная форма / уведомление
From: разрешённый адрес
Reply-To: согласованный адрес ответа
Время: с часовым поясом
Передача: принята / ошибка
Доставка: получено / отказ / неизвестно
Ответ: проверен отдельноПроверьте домен отправителя
| Контроль | Что искать |
|---|---|
| From | Разрешённый адрес вашего домена |
| SPF | Учтён фактический источник отправки |
| DKIM | Сообщение подписано нужным доменом |
| DMARC | Политика согласована с отправителями |
| Ответ получателя | Нет отказа или понятна его причина |
| Лимиты | Не превышены правила выбранной услуги |
Отделите соединение от доставки
Ошибка аутентификации требует проверки секрета и разрешённого метода. Таймаут соединения — адреса, сети и ограничений. Успешная передача с последующим отказом — анализа ответа принимающей стороны. Папка спама требует изучения заголовков и репутации, а не случайной смены порта.
Сохраняйте код ошибки и идентификатор без персонального содержания письма. Если ведётся журнал сообщений, ограничьте доступ и срок хранения. Полное тело формы может содержать персональные данные, которые не нужны для технической диагностики.
Сверьте транспорт без случайной смены портов
Параметры берите из своего кабинета: имя сервера, порт, ожидаемый режим TLS и способ авторизации. Прямой TLS и STARTTLS не являются взаимозаменяемыми галочками для любого порта. Сервис может требовать пароль приложения, OAuth или отдельный API. Если метод не поддерживается текущим компонентом, его нужно согласованно менять, а не отключать проверку сертификата.
Ошибка проверки сертификата требует проверки имени сервера, времени, доверенной цепочки и сетевого пути. Передайте точный отказ поставщику. Не задавайте verify_peer=false как универсальное лечение. Для тайм-аута установите, происходит ли он до соединения или после передачи. Смена порта без понимания этапа может лишь создать другой отказ.
- Подтвердите параметры по актуальной инструкции услуги.
- Проверьте доступность сети и допустимость исходящего соединения с площадки.
- Сверьте разрешённый способ авторизации и From.
- Выполните один обезличенный тест транспорта.
- Сохраните технический идентификатор и результат.
- Проверьте исходный сценарий формы отдельно.
Проверьте формы и очередь
Разные плагины могут отправлять почту разными способами. Проверьте фактический сценарий, а не только кнопку SMTP-теста. Для очереди убедитесь, что событие не осталось ожидающим или ошибочным. После исправления выполните новый штатный тест.
При переносе сайта проверьте повторно DNS и отправителя. Сохранённый пароль не означает, что новая площадка имеет те же сетевые разрешения. Не запускайте рабочую рассылку на тестовой копии.
Проверьте очередь, повторы и отказы после принятия
Некоторые плагины отправляют сообщение через фоновые задачи. Тогда нажатие формы создаёт запись в очереди, а фактическая доставка происходит позже. Найдите задачу, её статус и журнал. Не запускайте всю очередь вручную ради одного письма: там могут быть клиентские уведомления и другие операции. Failed не всегда доказывает отсутствие внешней отправки, если подтверждение потерялось.
Почтовый сервис может принять письмо и затем вернуть отказ. Нужен доступ к предусмотренному журналу, bounce-адресу или событию доставки с ответственным за разбор. Временный отказ и окончательное отклонение требуют разного поведения повторов. Не устраивайте массовую пересылку, пока неизвестно, какие сообщения уже доставлены. Придерживайтесь правил выбранного сервиса и обработчика.
После исправления повторите полезный сценарий
Выполните новый тест с отличимым идентификатором: транспорт, затем исходная форма, затем ответ на сообщение, если это часть процесса. Сверьте адрес сотрудника и содержимое без персональных данных. Проверьте независимую сессию и очистку релевантного кэша, если старая форма могла использовать прежние настройки. Успешная кнопка SMTP-теста не закрывает ошибку условий отправки формы.
Сохраните исходные настройки до изменения и порядок возврата. Возврат транспорта не отзывает уже отправленные письма, поэтому последствия повторов учитываются отдельно. Для временного обхода назначьте срок и дальнейшее исправление. Если часть получателей отклоняет письма, укажите границы результата вместо обещания стопроцентной доставки.
Регламент журналирования и секретов
Ограничьте доступ к почтовому журналу и срок хранения. Тела форм могут содержать персональные сведения, а диагностический вывод SMTP — детали аутентификации. Для технического отчёта обычно достаточно времени, источника, кода, идентификатора и обезличенной причины. Не включайте пароль, токен или письмо клиента в публичный скриншот.
При смене исполнителя отзовите его доступ к настройкам и секретам по карте проекта, сохранив рабочий транспорт. Если пароль заменён, проверьте все разрешённые приложения, которые его использовали. Отдельный технический доступ на задачу делает такой отзыв проще, чем один общий пароль почты для всей инфраструктуры.
FAQ и итог
wp_mail вернул true — письмо точно доставлено?
Нет. Это подтверждает обработку запроса используемым механизмом без сообщённой ошибки, но не получение адресатом.
SMTP-тест прошёл, а форма не отправляет — что дальше?
Проверьте событие и условия формы, получателя, очередь и фактический транспорт этой операции.
Нужно ли отключить TLS-проверку при ошибке сертификата?
Нет. Сначала разберите имя, доверенную цепочку, время и путь соединения по официальной процедуре.
Можно ли указать email посетителя в From?
Используйте разрешённого отправителя своего сервиса; адрес ответа задаётся поддерживаемым механизмом формы.
Исправление подтверждено доставкой согласованного теста из исходной формы и понятным прохождением этапов. Журнал и ответственный позволяют заметить будущие отказы, а секреты остаются вне отчёта.
Источники и дата
Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.
