WordPress не отправляет письма после переноса на VPS: диагностика и исправление

Почему после переноса на VPS WordPress перестал отправлять письма

Если на старом хостинге письма WordPress работали, а после миграции на VPS исчезли, сначала нужно определить масштаб проблемы. Shared-хостинг обычно уже имеет настроенный почтовый транспорт. На чистом VPS его может не быть вообще, а сохранённые в WordPress SMTP-настройки могут указывать на старую инфраструктуру.

Обычно после переноса владелец видит рабочий сайт: база подключена, SSL действует, Nginx или Apache отвечает, админка открывается. Но отправка почты находится за пределами файлов WordPress. Поэтому миграция сайта может быть закончена, а почтовая цепочка — нет.

Есть сценарий, который легко сломать лишними действиями: сайт переехал на VPS, а почта домена осталась у прежнего почтового провайдера. В таком случае перенос WordPress сам по себе не требует изменения MX-записей.

Не меняйте одновременно SMTP-плагин, SPF, MX и конфигурацию Postfix. Отправьте один контролируемый тест и найдите первую точку отказа. Иначе причина просто потеряется среди собственных изменений.

Как определить, WordPress не отправляет письмо или письмо не доставляется

Если форма сообщает об успешной отправке, но письмо отсутствует в ящике, это ещё не доказывает ошибку формы. Успешный вызов wp_mail() означает лишь, что WordPress не обнаружил ошибку на своём этапе передачи сообщения. Это не подтверждение доставки получателю.

Отправьте одно письмо и больше ничего не меняйте. Если установлен SMTP-плагин, посмотрите его тест и ответ SMTP-сервера. Если WordPress использует локальный Postfix или Exim, одновременно откройте почтовый журнал. Нужна первая подтверждённая ошибка.

Если SMTP отвечает 250, возвращаться к Contact Form 7 и бесконечно менять поля формы уже нет смысла. Сообщение принято следующим SMTP-сервером. Проблема находится дальше по цепочке.

Если TCP-соединение до SMTP вообще не открывается, SPF пока не трогаем. Письмо ещё не дошло до этапа SPF-проверки. Это уже сеть.

Работает ли wp_mail() и PHP mail() на новом VPS

Если после переноса одновременно перестали работать форма обратной связи, восстановление пароля и системные уведомления WordPress, нужно проверить общий механизм отправки. Если же reset password приходит, а Contact Form 7 молчит, MTA пока оставляем в покое — сервер уже умеет отправлять хотя бы часть писем WordPress.

Как отделить WordPress от конкретного плагина формы

Проверьте отправку из двух независимых источников. Например, запросите восстановление пароля WordPress и выполните тест из SMTP-плагина. Для WooCommerce можно дополнительно проверить системное уведомление о заказе, если магазин уже работает.

• работает всё, кроме одной формы — сначала проверяем форму;
• не работает несколько независимых источников — идём к wp_mail() и транспорту;
• SMTP test работает, а форма нет — проблема почти наверняка выше SMTP-уровня;
• не работает даже тест SMTP — смотрим ошибку подключения или авторизации.

Как проверить wp_mail() через WP-CLI

Если на VPS установлен WP-CLI, из каталога нужной установки WordPress можно выполнить тест напрямую:

wp eval 'var_dump(wp_mail("test@example.com", "WP mail test", "test"));'

Замените test@example.com на внешний тестовый адрес. Результат bool(true) не означает, что письмо попало во «Входящие». Он говорит лишь о том, что wp_mail() не получил ошибку на своём этапе.

Если команда возвращает false, уже есть основание разбирать WordPress, PHPMailer и способ передачи сообщения. Если возвращается true, следующий вопрос — появилось ли письмо в SMTP-журнале или mail log.

Как получить реальную ошибку wp_mail()

WordPress вызывает событие wp_mail_failed, когда PHPMailer не смог выполнить отправку. Для временной диагностики можно записать сообщение ошибки в PHP error log:

add_action( 'wp_mail_failed', function ( $error ) {
    error_log( 'wp_mail_failed: ' . $error->get_error_message() );
} );

Такой код лучше использовать временно и удалить после проверки. При включённом и корректно настроенном WP_DEBUG_LOG сообщение может попасть в wp-content/debug.log; в другой конфигурации смотрите PHP error log, заданный для PHP-FPM.

У wp_mail_failed есть предел: событие поможет, если ошибка произошла внутри PHPMailer или при передаче письма транспорту. Если SMTP уже принял сообщение, а затем оно попало в спам или было отфильтровано дальше, WordPress об этом не узнает.

Как понять, используется ли локальный sendmail или внешний SMTP

Если SMTP-плагина нет и WordPress использует стандартный механизм PHP, проверьте наличие sendmail-совместимого бинарного файла:

which sendmail

Затем посмотрите путь, настроенный в PHP:

php -i | grep sendmail_path

Наличие /usr/sbin/sendmail ещё не доказывает доставку. Это лишь интерфейс, через который PHP может передавать письмо Postfix, Exim или другому MTA.

Есть ещё одна ловушка: php -i запускает CLI PHP. На сервере с несколькими версиями PHP сайт может работать через другой PHP-FPM и другой php.ini. Поэтому сверяйте конфигурацию именно того PHP, который обслуживает виртуальный хост WordPress.

Как понять, дошло ли письмо от WordPress до Postfix

Это одна из самых полезных границ диагностики. Откройте mail log, затем вызовите тестовое письмо через WordPress.

• новая запись о письме появилась — WordPress/PHP передали сообщение локальному MTA;
• в логе тишина — до Postfix письмо не дошло;
• в логе тишина, но WordPress настроен на внешний SMTP — это нормально: локальный Postfix в этой схеме может вообще не участвовать.

Если форма пишет «успешно», reset password тоже не приходит, а после теста в mail log нет ни одной новой строки, искать SPF ещё рано. Сначала разбираем WordPress, PHPMailer, PHP и реальный транспорт.

Есть ли на VPS почтовый транспорт Postfix, Exim или Sendmail

На минимально установленном Linux VPS почтового сервера может не быть. Nginx, PHP-FPM и MariaDB работают, WordPress открывается быстро, но передавать письмо из PHP наружу просто некому.

Для Postfix проверьте состояние сервиса:

systemctl status postfix

Для Exim в Debian/Ubuntu имя сервиса часто выглядит так:

systemctl status exim4

• Unit postfix.service could not be found — Postfix не установлен как systemd-сервис;
• inactive или failed — пакет есть, но сервис не работает нормально;
• active (running) — MTA запущен, но доставка ещё не доказана.

Посмотреть процессы можно дополнительной командой:

ps aux | grep -E 'postfix|exim|sendmail'

Если используется Postfix и нужно увидеть его эффективную конфигурацию без большого массива значений по умолчанию:

postconf -n

Здесь полезно сверять не каждую строку подряд, а параметры, связанные с вашей схемой: hostname сервера, relayhost, сетевые интерфейсы и другие настройки, которые вы действительно изменяли. Если используется внешний SMTP relay, особенно важно понять, настроен ли Postfix на отправку через него, а не напрямую.

Что означает пустая очередь Postfix

Очередь Postfix проверяется так:

postqueue -p

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

Mail queue is empty

Сам по себе пустой queue ничего не доказывает. Письмо могло быстро уйти, а могло вообще не попасть в Postfix. Поэтому очередь всегда сверяется с журналом.

Если письмо осталось в очереди, в выводе будут видны queue ID, отправитель, получатель и причина задержки. Например, при сетевой проблеме сообщение может иметь deferred-состояние и ждать повторной попытки.

Не устанавливайте полноценный Postfix только потому, что WordPress не отправляет две формы. Если сайт будет работать через внешний авторизованный SMTP, локальный MTA может вообще не понадобиться.

Что искать в mail.log, если сервер принимает письмо от WordPress, но оно не приходит

Если Postfix работает и WordPress передаёт ему сообщение, следующим источником правды становится почтовый журнал. Именно там видно, пытался ли сервер отправить письмо дальше и какой ответ получил.

На Ubuntu и Debian журнал часто находится здесь:

tail -n 100 /var/log/mail.log

На AlmaLinux, Rocky Linux и других RHEL-подобных системах часто используется:

tail -n 100 /var/log/maillog

Если такого файла нет, это ещё не означает отсутствие почтовых событий. Сервис может писать в systemd journal:

journalctl -u postfix --since "10 minutes ago"

Проще всего открыть лог в реальном времени и сразу после этого отправить тестовое письмо:

tail -f /var/log/mail.log

Что означает status=sent

Запись с status=sent обычно означает, что следующий SMTP-сервер принял сообщение.

status=sent (250 2.0.0 OK)

Postfix свою часть выполнил. Но status=sent не доказывает попадание во «Входящие»: следующим этапом остаются антиспам-фильтры, правила получателя и DNS-аутентификация.

Что означает status=deferred

status=deferred означает, что Postfix сейчас не смог доставить сообщение и оставил его в очереди для повторной попытки.

status=deferred (connect to mail.example.net:25: Connection timed out)

Здесь причина уже читается прямо в строке: соединение с удалённым сервером не установилось. Менять From Email в WordPress в такой ситуации бессмысленно.

Как читать SMTP-коды 4xx и 5xx

Коды семейства 4xx обычно означают временный отказ: принимающая сторона предлагает повторить попытку позже. Коды 5xx чаще требуют изменения конфигурации, отправителя или других условий доставки. Всегда читайте не только номер, но и текст ответа после него.

Лог почти всегда полезнее очередной переустановки SMTP-плагина. Он показывает конкретный этап и ответ удалённой стороны.

Не блокирует ли VPS SMTP-порты 25, 465 или 587

Если SMTP-плагин несколько секунд ждёт, а затем пишет Could not connect to SMTP host или timeout, сначала проверьте соединение непосредственно с VPS. Пока сервер не может открыть TCP-сессию до SMTP-хоста, настройки WordPress не помогут.

Как проверить нужный SMTP-порт через nc

Проверяйте именно тот порт, который указан вашим почтовым сервисом:

nc -vz smtp.example.com 587
nc -vz smtp.example.com 465
nc -vz smtp.example.com 25

• succeeded — TCP-соединение устанавливается;
• Connection refused — узел доступен, но соединение на этом порту отклонено;
• Connection timed out — проверяем маршрут, firewall и сетевые ограничения;
• ошибка разрешения имени — сначала исправляем DNS.

Порты 25, 465 и 587 выполняют разные роли. Порт 25 прежде всего используется для SMTP-доставки между почтовыми серверами. Порт 587 обычно используется для авторизованной отправки клиентом с STARTTLS, а 465 — для SMTP submission с TLS с начала соединения.

Поэтому ситуация «25 timeout, а 587 работает» для WordPress, настроенного на авторизованный SMTP через 587, может вообще не быть проблемой.

Как проверить, в какой IP резолвится SMTP hostname

Если SMTP открывается с рабочего компьютера, но с VPS получает timeout, проверьте адреса прямо на сервере:

dig A smtp.example.com
dig AAAA smtp.example.com

Дополнительно можно посмотреть все адреса, которые возвращает системный resolver:

getent ahosts smtp.example.com

Если есть и A, и AAAA, приложение может попытаться использовать IPv6. При сломанном IPv6-маршруте получается неприятная картина: IPv4 исправен, DNS выглядит нормально, но PHPMailer долго ждёт и падает по timeout.

Если установленная версия nc поддерживает явный выбор семейства адресов, сравните:

nc -4 -vz smtp.example.com 587
nc -6 -vz smtp.example.com 587

IPv4 работает, а IPv6 зависает — причина уже локализована. Это не ошибка WordPress.

Как проверить TLS через openssl

Для SMTP с implicit TLS на порту 465:

openssl s_client -connect smtp.example.com:465 -crlf

Для STARTTLS на 587:

openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf

Так можно увидеть, начинается ли TLS-сеанс и какой сертификат отдаёт сервер. Если здесь появляется ошибка hostname или TLS, похожий сбой может получать и PHPMailer.

Локальный firewall тоже проверьте:

ufw status

На серверах с nftables или iptables смотрите соответствующие правила. Не исходите из предположения, что хостер «точно блокирует порт 25»: такое ограничение встречается, но его нужно подтвердить тестом или документацией провайдера.

Если shell с VPS не может открыть нужный SMTP-порт, WordPress пока не трогаем.

Когда WordPress после переноса лучше перевести на внешний SMTP

Postfix можно поднять прямо на VPS, но для сайта, которому нужны формы, восстановление пароля и уведомления WooCommerce, это часто добавляет больше точек отказа. Если нет задачи самостоятельно обслуживать исходящий почтовый сервер, WordPress обычно проще подключить к уже настроенному авторизованному SMTP.

SMTP может предоставлять почтовый сервис домена, корпоративная почта или отдельный сервис транзакционных сообщений. Конкретный WordPress-плагин здесь вторичен: он должен корректно подключить PHPMailer к выбранному серверу.

Сверьте параметры с документацией именно вашего SMTP-сервиса:

• SMTP hostname;
• порт;
• TLS/STARTTLS;
• логин;
• пароль или app password, если он требуется;
• разрешённый From Email.

Порты 465 и 587 не нужно менять местами «на пробу», если сервис явно указал свою схему подключения. Сначала повторите его настройки точно, а уже затем разбирайте ошибку.

Отдельно проверьте From Email. Например, WordPress авторизуется на SMTP как site@example.com, а форма пытается отправлять письмо от адреса посетителя customer@gmail.com. SMTP-сервис может запретить такой sender, переписать From или отклонить сообщение.

Для формы обычно безопаснее использовать адрес своего домена в From, а email посетителя передавать через Reply-To. Тогда SMTP отправляет письмо от разрешённого домена, а менеджер всё равно может ответить посетителю обычной кнопкой «Ответить».

После настройки не останавливайтесь на зелёном сообщении SMTP-плагина. Нормальный контрольный тест выглядит так: соединение установлено, авторизация прошла, sender принят, SMTP вернул успешный ответ, письмо пришло на внешний адрес, а в заголовках нет неожиданных ошибок SPF/DKIM/DMARC.

Только после этого возвращайтесь к реальным формам WordPress и WooCommerce.

Не сломались ли SPF, DKIM и DMARC после переноса

Если SMTP принимает сообщения, но Gmail, Outlook или другой получатель отправляет их в спам либо отклоняет, проверьте DNS-аутентификацию домена. После миграции реальный источник почты мог измениться, а записи остаться от старой схемы.

Что проверить в SPF после миграции

Посмотрите TXT-записи домена:

dig TXT example.com

Среди ответа нужно найти запись, начинающуюся с v=spf1. Условный пример:

v=spf1 include:_spf.example.net -all

Это только пример структуры, а не готовая запись для вашего домена. Значения ip4, ip6, include и другие механизмы должны соответствовать реальному сервису, который отправляет почту.

Если WordPress теперь отправляет через внешний SMTP, SPF обычно должен разрешать инфраструктуру этого SMTP-провайдера. Если VPS отправляет напрямую, в политике должен быть учтён реальный исходящий сервер. Проверяйте источник, а не просто IP сайта.

Не создавайте вторую отдельную SPF-политику в надежде «добавить ещё один сервер». Для домена должна быть одна согласованная SPF-политика, включающая все разрешённые источники отправки.

Когда нужен DKIM и что искать в ответе DNS

DKIM подписывает письмо приватным ключом отправляющей стороны, а публичный ключ публикуется в DNS под конкретным selector:

dig TXT selector._domainkey.example.com

В корректном ответе обычно видна структура с версией DKIM и публичным ключом, например:

v=DKIM1; k=rsa; p=MIIB...

Selector и значение p= выдаёт конкретный почтовый сервис. Нельзя копировать публичный ключ из чужого примера. Если сервис использует другой selector, запрос к selector._domainkey просто не покажет нужную запись.

Как DMARC помогает найти проблему

DMARC-политику домена можно посмотреть так:

dig TXT _dmarc.example.com

Минимальная структура может выглядеть так:

v=DMARC1; p=none; ...

Конкретная политика зависит от настроек домена. Для диагностики после миграции важнее другое: DMARC оценивает согласование домена в видимом From с результатами SPF и DKIM. Поэтому SPF может формально пройти для одного домена, а сообщение всё равно получить DMARC fail из-за несовпадения идентификаторов.

Почему перенос сайта не требует автоматически менять MX

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

dig MX example.com

Например, сайт example.com может работать на новом VPS, а ящики info@example.com продолжать обслуживаться старым почтовым провайдером. Тогда A-запись сайта меняется, а MX остаётся прежним.

Если после переноса сайта сотрудники внезапно перестали получать обычную почту, проверьте, не заменили ли MX вместе с A-записью. Сайт и почта могут находиться на разных серверах — и это нормальная схема.

Что проверить, если письма WordPress попадают в спам

Если письмо уже появилось в папке «Спам», WordPress и исходящий транспорт выполнили основную часть работы. Теперь нужно смотреть, как сообщение оценил принимающий сервер.

Что искать в Authentication-Results

Откройте технические заголовки полученного письма и найдите Authentication-Results. Условный успешный результат может выглядеть так:

Authentication-Results: mx.example.net;
    spf=pass smtp.mailfrom=example.com;
    dkim=pass header.d=example.com;
    dmarc=pass header.from=example.com

При проблеме один или несколько результатов могут содержать fail, softfail или другую диагностическую информацию. Читайте весь параметр, а не только слово рядом с SPF или DKIM.

Если SPF, DKIM и DMARC показывают pass, а письмо всё равно оказалось в спаме, DNS-аутентификация здесь уже не главный подозреваемый. Дальше проверяются репутация реального отправляющего IP или SMTP-сервиса, содержание сообщения, объём и характер отправки, история домена и политика принимающей стороны.

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

Когда проверять PTR/rDNS VPS

PTR и репутация IP VPS особенно важны при прямой отправке:

WordPress → Postfix на VPS → SMTP-сервер получателя

В такой схеме VPS сам подключается к серверам получателей. Тогда уже имеют значение PTR/rDNS, hostname, прямой DNS, HELO/EHLO, DKIM, SPF, очередь и репутация IP.

При другой схеме:

WordPress → внешний SMTP → получатель

интернет-доставку выполняет SMTP-провайдер. Проверять PTR веб-VPS как главную причину спама в таком случае не нужно: получатель может вообще не видеть IP этого VPS как отправляющий SMTP.

Даже полностью корректные SPF, DKIM и DMARC не гарантируют папку «Входящие». Они подтверждают техническую аутентификацию, но не отменяют антиспам-оценку самого сообщения и репутации отправителя.

Какую схему отправки оставить на WordPress VPS

После исправления зафиксируйте, кто именно доставляет почту: внешний SMTP, локальный Postfix с relay или сам VPS. Это избавляет от ситуации, когда через несколько месяцев никто уже не понимает, зачем установлен Postfix и почему WordPress одновременно настроен на отдельный SMTP-плагин.

Для обычного корпоративного сайта или интернет-магазина внешний авторизованный SMTP обычно требует меньше самостоятельного обслуживания. Прямая отправка с VPS добавляет DNS, reverse DNS, DKIM, очередь, SMTP-отказы и репутацию IP.

Если на VPS работает несколько приложений и инфраструктуру контролирует администратор, локальный Postfix с единым SMTP relay может быть удобнее: приложения передают сообщения локально, а один MTA отправляет их через внешний сервис.

Прямая доставка с собственного VPS имеет смысл только тогда, когда вы готовы администрировать полноценный исходящий почтовый узел. Сам факт наличия root-доступа ещё не делает эту схему проще.

WordPress не отправляет письма после переноса: контрольный чек-лист

1. Отправьте одно тестовое письмо WordPress.
2. Проверьте другую функцию wp_mail(), например восстановление пароля.
3. Если доступен WP-CLI, выполните прямой тест wp_mail().
4. При ошибке WordPress проверьте wp_mail_failed и PHP error log.
5. Определите, используется локальный sendmail/MTA или внешний SMTP.
6. Если используется локальный MTA, проверьте состояние Postfix или Exim.
7. Откройте mail log и повторите одно тестовое письмо.
8. Проверьте очередь Postfix через postqueue -p.
9. Если письмо не появляется в mail log, вернитесь к WordPress/PHP или проверьте, не используется ли внешний SMTP.
10. При timeout проверьте именно нужный SMTP-порт через nc.
11. Сверьте A и AAAA SMTP hostname и отдельно исключите проблему IPv6.
12. При TLS-ошибке проверьте соединение через openssl s_client.
13. Сверьте SMTP hostname, порт, режим TLS, логин и пароль.
14. Проверьте, разрешён ли используемый From Email.
15. Определите реальный сервер, который отправляет письмо в Интернет.
16. Проверьте SPF этого источника.
17. Проверьте DKIM и правильный selector.
18. Проверьте DMARC.
19. Проверьте MX, но не меняйте его только потому, что WordPress переехал на другой VPS.
20. Если письмо доставлено, проверьте «Спам» и Authentication-Results.
21. При прямой отправке с VPS проверьте PTR/rDNS, hostname и репутацию исходящего IP.
22. После исправления повторите тест формы, восстановления пароля и WooCommerce, если он используется.