Если письма из WordPress уходят, но не доходят до почты пользователя, проблема часто не в самом сайте, а в том, как именно он отправляет сообщения. Для рабочих уведомлений, писем регистрации, сброса пароля и форм обратной связи лучше сразу опираться на SMTP-сервис с нормальной аутентификацией и понятными логами доставки.
Ниже разберём не абстрактный «какой SMTP лучше», а практический сценарий: как выбрать сервис под WordPress, что проверить до подключения, как не сломать отправку и как убедиться, что письма действительно уходят через нужный канал.
Когда проблема именно в SMTP-сервисе
Сначала стоит отделить сбой WordPress от проблем на стороне почтового провайдера. Если сайт отправляет письма через wp_mail(), но они регулярно попадают в спам или не доходят, обычно причина одна из трёх: слабая репутация домена, неправильная аутентификация или ограничения у хостинга/SMTP-провайдера.
Типовые симптомы
- письма из формы отправляются, но не приходят на Gmail, Outlook или корпоративные домены;
- письма доходят только на часть адресов;
- в заголовках письма видно
viaилиmailed-byне от вашего домена; - SMTP-плагин пишет об успешной отправке, но в ящике письма нет;
- после смены хостинга почта стала уходить нестабильно.
Что проверить до выбора сервиса
- есть ли у домена доступ к DNS-записям: SPF, DKIM, DMARC;
- можно ли использовать отдельный технический адрес отправителя, например
no-reply@domain.ru; - нужны ли транзакционные письма только для сайта или ещё для рассылок;
- есть ли у сервиса логи отправки и статус доставки;
- поддерживает ли он SMTP или API, если плагин умеет оба варианта.
Как выбрать SMTP-сервис под задачи WordPress
Для WordPress важны не рекламные обещания, а три вещи: стабильная аутентификация, прозрачные ограничения и нормальная наблюдаемость. Если сервис не даёт понять, почему письмо не ушло, отладка превращается в угадайку.
На что смотреть в первую очередь
- Репутация отправки. У сервиса должны быть отдельные IP или хотя бы предсказуемая политика репутации для транзакционных писем.
- Логи. Нужна история отправок с кодами ошибок, а не только статус «sent».
- Поддержка SPF/DKIM/DMARC. Без этого письма часто теряют доверие у почтовых систем.
- Ограничения. Важно знать лимиты по числу писем, скорости и доменам.
- Способ подключения. SMTP проще для большинства сайтов, API часто надёжнее, но зависит от плагина и сценария.
Короткое сравнение подходов
| Подход | Плюсы | Минусы | Когда брать |
|---|---|---|---|
| SMTP через плагин | Просто подключить, легко проверить | Зависит от стабильности SMTP-сервера | Для большинства сайтов и форм |
| API-сервис | Часто лучше логирование и доставка | Нужна поддержка в плагине | Если важны отчёты и контроль |
| Почта хостинга | Быстро и без отдельного сервиса | Слабая репутация и лимиты | Только для тестов или внутренних уведомлений |
Если нужен практичный набор для чистки сайта и снижения лишних дублей, иногда полезно дополнительно посмотреть на Clearfy Pro, но он не заменяет SMTP-сервис: это разные задачи.
Пошаговая настройка: что делать после выбора сервиса
Ниже логика, которая обычно работает без лишних сюрпризов. Сначала настраиваем домен и отправителя, потом подключаем WordPress, затем проверяем заголовки и логи.
1. Подготовьте домен
Убедитесь, что у домена есть корректные DNS-записи для отправки почты. Минимум — SPF и DKIM. DMARC не обязателен для старта, но без него сложнее контролировать подмену отправителя и разбирать проблемы с доставкой.
Если сервис выдал готовые записи, не сокращайте их и не объединяйте вручную без понимания синтаксиса. Ошибка в одной кавычке или пробеле ломает всю запись.
2. Используйте реальный адрес отправителя
Для WordPress лучше завести отдельный адрес на своём домене, например no-reply@domain.ru или mail@domain.ru. Адрес должен совпадать с доменом, который подписан в SPF/DKIM, иначе часть почтовых систем начнёт относиться к письмам подозрительно.
3. Подключите SMTP в плагине
В большинстве случаев достаточно плагина, который умеет переопределять wp_mail(). Ниже пример базовой настройки через код, если нужно быстро проверить отправку без лишней логики плагина:
add_action('phpmailer_init', function ($phpmailer) {
$phpmailer->isSMTP();
$phpmailer->Host = 'smtp.example.com';
$phpmailer->SMTPAuth = true;
$phpmailer->Port = 587;
$phpmailer->Username = 'no-reply@example.com';
$phpmailer->Password = 'your-app-password';
$phpmailer->SMTPSecure = 'tls';
$phpmailer->From = 'no-reply@example.com';
$phpmailer->FromName = 'Site Name';
});Это рабочая схема, но для постоянной эксплуатации лучше использовать плагин с интерфейсом, логами и тестовой отправкой. Код выше удобен как временная диагностика или для небольшого проекта, где вы контролируете конфигурацию.
4. Не смешивайте каналы отправки
Если часть писем уходит через SMTP, а часть — через хостинг, отладка становится бессмысленной. Для одного сайта лучше выбрать один основной канал и явно проверить, что все критичные уведомления идут через него.
Как проверить, что письма реально доходят
Успешная отправка в админке ещё не означает, что письмо дошло до ящика. Нужна проверка на нескольких уровнях: лог плагина, заголовки письма и поведение на стороне почтового сервиса.
Минимальный чек-лист проверки
- отправьте тестовое письмо из плагина SMTP;
- проверьте, появился ли лог отправки;
- откройте письмо и посмотрите заголовки;
- сравните
From,Return-Pathи домен в DKIM; - проверьте доставку на Gmail и Outlook, если сайт работает с внешней аудиторией;
- сделайте тест формы, регистрации и сброса пароля.
Что искать в заголовках
Если письмо доставлено корректно, в заголовках обычно видно, что домен отправителя совпадает с доменом подписи, а цепочка аутентификации не развалилась. Если сервис показывает ошибку SPF/DKIM, сначала исправляйте DNS, а не меняйте тему письма или текст уведомления.
Для быстрой проверки можно отправить тестовое письмо через wp_mail() и посмотреть, сработал ли ваш SMTP-плагин:
add_action('init', function () {
if (!isset($_GET['test_wp_mail'])) {
return;
}
$sent = wp_mail(
get_option('admin_email'),
'Тест SMTP из WordPress',
'Если вы получили это письмо, отправка работает.'
);
wp_die($sent ? 'Письмо отправлено' : 'Ошибка отправки');
});Такой тест не стоит держать на боевом сайте постоянно. После проверки удалите код или ограничьте доступ по роли и nonce, иначе любой посетитель сможет дергать отправку.
Частые ошибки и как их исправить
Неверный From-адрес
Если в качестве отправителя указан адрес с чужого домена, письмо может уйти в спам или быть отклонено. Исправление простое: используйте адрес на своём домене и проверьте, что он совпадает с доменом в DNS-записях.
Порт и шифрование не совпадают
Частая ошибка — поставить 465 с tls или 587 с ssl без понимания, что поддерживает конкретный сервис. Если подключение нестабильно, сначала сверяйте параметры с документацией провайдера, а не с подсказками в старых статьях.
SPF записан дважды
В DNS должен быть один SPF-запись на домен. Если добавить вторую, часть проверок начнёт падать. Нужно объединить разрешённые источники в одну запись, а не плодить отдельные строки.
Плагин логирует отправку, но письма нет
Это обычно означает, что SMTP-сервер принял сообщение, но дальше оно было отклонено фильтрами получателя. Смотрите заголовки, репутацию домена и наличие DKIM. Иногда проблема в содержимом письма: слишком много ссылок, подозрительный текст или сломанная HTML-разметка.
Используется общий ящик хостинга
Для боевого сайта это слабый вариант. У хостинга может быть плохая репутация IP, а лимиты на отправку быстро упираются в ограничения. Если проект важен, лучше вынести отправку на отдельный SMTP-сервис.
Практика безопасности и производительности
SMTP-подключение — это не только про доставку, но и про безопасность. Пароль от почтового ящика нельзя хранить в открытом виде в репозитории. Если конфигурация лежит в wp-config.php, ограничьте доступ к файлу и не передавайте его в сторонние сервисы.
Если провайдер поддерживает app password или отдельный API-ключ, используйте его вместо основного пароля почты. При компрометации такой ключ проще отозвать без потери доступа к ящику.
Для производительности важно не слать лишние письма. Если сайт генерирует много уведомлений, проверьте, нет ли дублей событий, повторной отправки форм или кривой интеграции с очередью. В этом случае полезно смотреть не только SMTP, но и саму бизнес-логику сайта.
Что делать после внедрения
После настройки не ограничивайтесь одним тестом. Проверьте несколько реальных сценариев: регистрация, восстановление пароля, комментарии, формы обратной связи, административные уведомления. Если хотя бы один тип письма идёт иначе, ищите различия в коде темы или плагина, который его формирует.
Хорошая практика — оставить логирование отправки хотя бы на время запуска. Это помогает быстро понять, где ломается цепочка: WordPress, SMTP-плагин, сервис или почтовый получатель. Когда всё стабильно, лог можно сократить или ограничить по сроку хранения, чтобы не раздувать базу.