Я меняю почтовый адрес в настройках сайта, сохраняю изменения и жду письмо с подтверждением. Ошибок на странице нет, но письмо не приходит.

С такой ситуацией я столкнулся в своём блоге. Причина оказалась на веб-сервере: сайт передавал письмо локальной почтовой службе, а та не была настроена на отправку во внешние домены.

Расскажу, как я нашёл проблему и подключил отправку через отдельный почтовый сервер.

Сначала — журнал отправки

Проверять папку «Спам» полезно, но в этом случае письмо до получателя даже не дошло.

Веб-сервер использовал локальную почтовую службу. В её журнале я нашёл запись об отказе:

Mailing to remote domains not supported

Это сразу сузило поиск. Форма сайта работала, запрос на отправку возникал, но следующий участник цепочки отказывался доставлять сообщение за пределы локальной системы.

При этом WordPress ещё ожидал подтверждения нового адреса. Изменение не завершилось — и это было правильным поведением: без перехода по ссылке из письма новый административный адрес не должен становиться действующим.

Почему «отправлено» ещё не означает «доставлено»

У письма несколько этапов:

Сайт → почтовая служба → сервер получателя → почтовый ящик

Успех на одном этапе не подтверждает прохождение остальных.

Например, функция wp_mail() может сообщить об успешной передаче письма используемому механизму отправки. Из этого ещё нельзя сделать вывод, что сообщение оказалось во входящих.

Поэтому при диагностике я смотрю на два отдельных результата: приняла ли почтовая система сообщение и появилось ли оно в нужном ящике.

Отдельный отправитель для сайта

Для блога я создал служебную почтовую учётную запись. Пароль личного ящика для этой задачи не понадобился.

Учётной записи я оставил возможность отправлять письма через SMTP, а доступ к веб-почте, IMAP и POP3 отключил. Административных прав у неё тоже нет.

Это удобнее для дальнейшего обслуживания: у сайта собственные реквизиты подключения, которые можно заменить отдельно от личной почты.

При этом такая учётная запись всё равно требует защиты. Её пароль позволяет отправлять сообщения от имени служебного адреса.

Подключение через SMTP и STARTTLS

На стороне WordPress я подключил SMTP с авторизацией через небольшой служебный плагин. Он настраивает используемую WordPress библиотеку PHPMailer перед отправкой письма.

Параметры подключения выглядят так:

Порт: 587
Авторизация: включена
Шифрование: STARTTLS
Проверка сертификата: включена

STARTTLS переводит SMTP-соединение в защищённый режим перед передачей учётных данных.

Отдельный нюанс моей настройки: веб-сервер обращается к почтовому серверу по внутреннему адресу, а сертификат выпущен на его DNS-имя. Поэтому для проверки сертификата я явно указал ожидаемое имя почтового сервера.

Отключать проверку TLS ради успешного подключения не потребовалось. Проверка цепочки доверия и соответствия имени осталась включённой.

Где хранится пароль

Реквизиты SMTP я вынес в отдельный файл за пределами публичного каталога сайта. В коде плагина пароля нет.

Файл принадлежит пользователю блога и доступен только ему. В Unix это соответствует правам:

0600

Такой файл нельзя получить обычным запросом к сайту, а другие системные пользователи не должны иметь возможности его читать.

Это не защищает секрет от взломанного приложения, которое работает от того же пользователя. Но убирает лишние способы раскрытия: публикацию вместе с кодом или случайную раздачу файла веб-сервером.

Как я проверил результат

Сначала я отправил тестовое письмо из WordPress. Затем нашёл его в нужном почтовом ящике по Message-ID.

Message-ID — идентификатор сообщения в его заголовках. По нему удобно сопоставлять конкретную отправку с результатом, особенно когда несколько тестовых писем имеют одинаковую тему.

После теста я повторно запустил штатную отправку подтверждения смены административного адреса. Это письмо тоже нашлось во входящих по своему идентификатору.

Таким образом, я проверил не только подключение к SMTP, но и получение двух конкретных сообщений нужным ящиком. Для завершения смены адреса мне оставалось перейти по ссылке подтверждения.

Что я буду проверять в следующий раз

Если сайт перестал отправлять письма, начну с короткой последовательности:

  1. Убедиться, что приложение действительно пытается отправить сообщение.
  2. Найти эту попытку в журнале почтовой службы.
  3. Проверить очередь и причину отказа.
  4. Проверить SMTP-авторизацию и TLS.
  5. Найти тестовое письмо в ящике получателя.

В моём случае решающей оказалась одна строка в журнале. Она показала, что искать проблему в форме сайта или папке «Спам» было рано: письмо останавливалось ещё на веб-сервере.

После подключения авторизованного SMTP тест и повторное подтверждение дошли до ящика. Именно это стало проверенным результатом настройки.