Настройка SMTP для отправки писем с сайта в 2026

Письма с сайта не доходят — это одна из тех проблем, которая всплывает в самый неподходящий момент: клиент оформил заказ, а подтверждение ушло в спам или не дошло вообще. За 10 лет практики я настроил SMTP, наверное, на сотне проектов — и каждый раз убеждаюсь, что стандартная функция mail() в PHP это тихая катастрофа, которую надо заменять сразу.

Почему стандартная mail() — это плохая идея

PHP-функция mail() отправляет письма через локальный sendmail или postfix на сервере. Звучит нормально, но на деле это означает следующее: письмо уходит с IP-адреса хостинга, у которого нет нормальной репутации, нет правильно настроенных SPF/DKIM записей, и почтовые серверы Google, Яндекс и Mail.ru просто кладут такие письма в спам. Или вообще отклоняют.

Был у меня клиент — небольшой интернет-магазин на WordPress, около 50 заказов в день. Полгода работали нормально, потом вдруг посыпались жалобы: "Где моё письмо с заказом?". Начали разбираться — все письма исправно отправлялись через mail(), но Gmail их стабильно клал в спам. Хостинг переехал на новый сервер, IP сменился, репутация нулевая. Настроили SMTP через Google Workspace — проблема ушла за 10 минут.

А ещё mail() не умеет нормально работать с вложениями, не поддерживает аутентификацию, не логирует ошибки доставки. Грубо говоря, это инструмент из 2005 года, который в 2026 году использовать просто нельзя. Особенно если у вас транзакционные письма: подтверждения регистрации, восстановление пароля, уведомления об оплате.

Какие SMTP-серверы использовать в 2026 году

Вопрос выбора SMTP-провайдера зависит от объёма писем и типа проекта. Я обычно делаю так: для корпоративных сайтов с небольшим трафиком — Google Workspace или Яндекс 360, для интернет-магазинов с большим объёмом транзакционных писем — специализированные сервисы.

Транзакционные сервисы

Postmark — мой личный фаворит для транзакционных писем. Доставляемость у них действительно высокая, есть детальная аналитика, webhook-и при отказе доставки. Бесплатный план: 100 писем в месяц. Платный от $15 за 10 000 писем.

SendGrid — один из самых популярных сервисов. Бесплатно даёт 100 писем в день навсегда. Для среднего сайта этого хватает. Но интерфейс у них, честно говоря, перегружен — настройка с первого раза не очевидна.

Mailgun — хорош для разработчиков, API очень удобный. Бесплатный план закрыли в 2023, сейчас минимум $35/месяц. Для небольших проектов уже не так привлекателен.

SMTP.ru — отечественный сервис, актуален если нужна российская инфраструктура. Есть бесплатный тариф до 500 писем в день. По доставляемости на российские почтовые сервисы (Mail.ru, Яндекс) работает хорошо.

Корпоративная почта как SMTP

Если у вас уже есть корпоративная почта на Google Workspace или Яндекс 360 — можно использовать её SMTP-серверы. Это бесплатно в рамках тарифа и даёт хорошую репутацию отправителя. Ограничение у Gmail: 2000 писем в сутки через SMTP. Для большинства сайтов более чем достаточно. Про настройку корпоративной почты на домене я подробно писал отдельно — Корпоративная почта на домене: настройка с нуля 2026.

Настройка SMTP на PHP через PHPMailer

PHPMailer — стандарт де-факто для отправки писем через PHP. Устанавливается через Composer, работает с любым SMTP-сервером, поддерживает TLS/SSL, вложения, HTML-письма. Я использую его на всех проектах, где нет встроенного механизма отправки.

Установка через Composer:

composer require phpmailer/phpmailer

Базовый пример подключения к SMTP-серверу — здесь я покажу конфиг для SendGrid, но параметры одинаковые для любого провайдера:

<?php
use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\SMTP;
use PHPMailer\PHPMailer\Exception;

require 'vendor/autoload.php';

function sendEmail(string $to, string $subject, string $body): bool
{
    $mail = new PHPMailer(true); // true включает исключения

    try {
        // Настройки SMTP
        $mail->isSMTP();
        $mail->Host       = 'smtp.sendgrid.net';   // SMTP-сервер
        $mail->SMTPAuth   = true;
        $mail->Username   = 'apikey';               // Для SendGrid логин всегда 'apikey'
        $mail->Password   = 'ваш_api_ключ_sendgrid';
        $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS; // TLS
        $mail->Port       = 587;

        // Отправитель
        $mail->setFrom('no-reply@yourdomain.ru', 'Название компании');
        $mail->addReplyTo('support@yourdomain.ru', 'Поддержка');

        // Получатель
        $mail->addAddress($to);

        // Содержимое
        $mail->isHTML(true);
        $mail->CharSet = 'UTF-8';
        $mail->Subject = $subject;
        $mail->Body    = $body;
        $mail->AltBody = strip_tags($body); // Текстовая версия для старых клиентов

        $mail->send();
        return true;

    } catch (Exception $e) {
        // Логируем ошибку, не показываем пользователю
        error_log('Mailer Error: ' . $mail->ErrorInfo);
        return false;
    }
}

// Использование
$result = sendEmail(
    'client@example.com',
    'Ваш заказ #12345 принят',
    '<h1>Спасибо за заказ!</h1><p>Мы уже начали его обрабатывать.</p>'
);

Обратите внимание на несколько моментов. Первое — я всегда использую порт 587 с STARTTLS, а не 465 с SSL. Технически оба варианта рабочие, но 587 — современный стандарт, и с ним реже бывают проблемы на разных хостингах. Второе — AltBody обязателен. Письма без текстовой версии некоторые почтовые клиенты помечают как подозрительные. Третье — ошибки надо логировать, а не показывать пользователю. Никто не должен видеть ваши SMTP-креденциалы в трейсе.

Настройка SMTP в WordPress

WordPress по умолчанию тоже использует wp_mail(), которая под капотом вызывает всё ту же PHP-функцию mail(). Для настройки SMTP есть несколько подходов.

Плагин WP Mail SMTP

Это самый популярный вариант — плагин WP Mail SMTP от WPForms. Бесплатная версия поддерживает все основные провайдеры: SendGrid, Mailgun, Gmail, SMTP.com, а также универсальный SMTP. Платная версия добавляет логирование писем, уведомления об ошибках, резервные SMTP-каналы.

Установка стандартная через меню плагинов. Настройки находятся в разделе WP Mail SMTP → Settings. Выбираете провайдера, вводите данные — и всё. Но я предпочитаю другой способ: прописывать настройки SMTP прямо в wp-config.php, чтобы они не зависели от плагина и не светились в базе данных.

// Добавляем в wp-config.php перед строкой "That's all, stop editing!"

define('WPMS_ON', true);
define('WPMS_MAILER', 'smtp');
define('WPMS_SMTP_HOST', 'smtp.sendgrid.net');
define('WPMS_SMTP_PORT', 587);
define('WPMS_SSL', 'tls');
define('WPMS_SMTP_AUTH', true);
define('WPMS_SMTP_USER', 'apikey');
define('WPMS_SMTP_PASS', 'ваш_api_ключ');
define('WPMS_SET_RETURN_PATH', false);
define('WPMS_MAIL_FROM', 'no-reply@yourdomain.ru');
define('WPMS_MAIL_FROM_FORCE', true);
define('WPMS_MAIL_FROM_NAME', 'Название сайта');
define('WPMS_MAIL_FROM_NAME_FORCE', true);

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

Настройка через хук wp_mail

Если плагины — не ваш путь, можно настроить SMTP через хук прямо в functions.php темы или в отдельном мю-плагине:

add_action('phpmailer_init', function(PHPMailer\PHPMailer\PHPMailer $phpmailer) {
    $phpmailer->isSMTP();
    $phpmailer->Host       = defined('SMTP_HOST') ? SMTP_HOST : 'smtp.sendgrid.net';
    $phpmailer->SMTPAuth   = true;
    $phpmailer->Port       = defined('SMTP_PORT') ? SMTP_PORT : 587;
    $phpmailer->Username   = defined('SMTP_USER') ? SMTP_USER : '';
    $phpmailer->Password   = defined('SMTP_PASS') ? SMTP_PASS : '';
    $phpmailer->SMTPSecure = 'tls';
    $phpmailer->From       = defined('SMTP_FROM') ? SMTP_FROM : get_option('admin_email');
    $phpmailer->FromName   = get_option('blogname');
    $phpmailer->CharSet    = 'UTF-8';
});

Константы SMTP_HOST, SMTP_USER и так далее определяются в wp-config.php. Чисто, без лишних зависимостей.

Настройка SMTP в Битрикс

В Битриксе ситуация немного другая. Там есть встроенный почтовый модуль, но он тоже по умолчанию использует PHP mail(). Настройка SMTP делается через административную панель или через конфиг.

Через админку: Настройки → Настройки продукта → Почта. Там можно указать SMTP-сервер, порт, логин и пароль. Но по опыту скажу — интерфейс там немного запутанный, особенно в старых версиях Битрикса.

Более надёжный способ — прописать SMTP в файле /bitrix/.settings.php или создать обработчик события OnBeforeEventMessageSend. Но для большинства проектов достаточно настройки через админку. Если у вас Битрикс и возникают проблемы с почтой — это часто симптом более широких проблем с настройкой сервера. У меня есть отдельный материал про Настройку кеширования в Битрикс — там же затрагиваю тему правильной конфигурации окружения.

Одна история из практики: клиент на Битриксе жаловался, что письма о новых заказах приходят с задержкой в 10-15 минут. Оказалось, что на сервере был настроен локальный postfix, который ставил письма в очередь и отправлял пакетами. Переключили на прямой SMTP через Postmark — задержка исчезла, письма стали доходить мгновенно.

Настройка SMTP в Laravel

В Laravel всё сделано максимально удобно. Почтовый драйвер настраивается в файле .env, а отправка идёт через Mailable-классы. Это правильная архитектура — логика письма отделена от бизнес-логики.

Конфигурация в .env для PHP 8.2+ и Laravel 10/11:

MAIL_MAILER=smtp
MAIL_HOST=smtp.postmarkapp.com
MAIL_PORT=587
MAIL_USERNAME=ваш_postmark_api_token
MAIL_PASSWORD=ваш_postmark_api_token
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=no-reply@yourdomain.ru
MAIL_FROM_NAME="${APP_NAME}"

# Для логирования в dev-окружении
# MAIL_MAILER=log

Обратите внимание на строку MAIL_MAILER=log в комментарии. На локальной разработке я всегда использую log-драйвер — письма не отправляются реально, а пишутся в storage/logs/laravel.log. Это спасает от случайной отправки тестовых писем реальным пользователям. Звучит банально, но я видел, как разработчики случайно слали тестовые уведомления базе в 50 000 клиентов — не лучший опыт.

В Laravel 11 появился удобный Resend-драйвер как нативная интеграция. Если вы ещё не смотрели в сторону Resend — это молодой сервис с очень щедрым бесплатным планом (3000 писем в месяц) и отличным API. Для новых проектов на Laravel я сейчас рекомендую именно его.

Диагностика проблем с доставкой

Настроили SMTP, но письма всё равно в спаме или не доходят? Вот мой чек-лист диагностики.

Проверка SPF, DKIM, DMARC

Первым делом проверяю DNS-записи через MXToolbox (mxtoolbox.com/SuperTool). Вводите домен и смотрите SPF Lookup, DKIM Lookup, DMARC Lookup. Если хоть одна из этих записей отсутствует или неправильная — письма будут в спаме вне зависимости от качества SMTP. Это фундамент.

SPF должен включать серверы вашего SMTP-провайдера. Например, для SendGrid:

yourdomain.ru. IN TXT "v=spf1 include:sendgrid.net ~all"

Если используете несколько источников отправки (например, сайт через SendGrid и CRM через другой сервис), объединяете их в одну SPF-запись:

yourdomain.ru. IN TXT "v=spf1 include:sendgrid.net include:_spf.google.com ip4:1.2.3.4 ~all"

Тест отправки

Для проверки реальной доставляемости использую mail-tester.com. Отправляете письмо на их временный адрес — получаете детальный отчёт с оценкой по 10-балльной шкале. Цель — 9 из 10 и выше. Всё ниже 7 означает реальные проблемы с доставкой.

Ещё один инструмент — Google Postmaster Tools. Если значительная часть ваших пользователей на Gmail, регистрируйте домен там и следите за репутацией IP и домена. Это бесплатно и даёт реальную картину того, как Google оценивает ваши письма.

Логирование SMTP-соединений

Если PHPMailer возвращает ошибку, включаю отладку временно:

$mail->SMTPDebug = SMTP::DEBUG_SERVER; // Детальный лог SMTP-диалога
$mail->Debugoutput = function($str, $level) {
    error_log("SMTP Debug: $str");
};

Это показывает весь SMTP-диалог: подключение, аутентификацию, передачу данных. Обычно из лога сразу видно, где обрывается соединение — неправильный порт, TLS-ошибка, отказ в аутентификации.

SMTP vs API: что выбрать в 2026

Честно говоря, в 2026 году я всё чаще рекомендую использовать HTTP API вместо SMTP — там где это возможно. Объясню почему.

SMTP — это протокол из 1982 года. Он требует постоянного TCP-соединения, работает через несколько стадий handshake, и если соединение рвётся — письмо может потеряться. HTTP API работает проще: один POST-запрос с данными письма, получаете ответ с ID сообщения, и всё. Если запрос не прошёл — сразу видите ошибку и можете повторить.

Большинство современных сервисов (SendGrid, Postmark, Mailgun, Resend) предоставляют оба варианта. Для PHP-проектов без фреймворка я использую SMTP через PHPMailer — это универсально. Для Laravel-проектов — нативный HTTP-драйвер или пакет конкретного провайдера. Для WordPress — плагин WP Mail SMTP с API-интеграцией.

Единственный случай, когда SMTP однозначно лучше API — это когда нужна совместимость с разными системами и вы не знаете заранее, какой клиент будет отправлять письма. SMTP — универсальный стандарт, API у каждого провайдера свой.

Безопасность SMTP-настроек

Этот раздел часто пропускают, а зря. Утечка SMTP-креденциалов — это не просто плохо, это катастрофа. Злоумышленник получит возможность отправлять миллионы писем от вашего имени, ваш домен попадёт в чёрные списки, и вы потратите недели на восстановление репутации.

Правило первое: никогда не храните SMTP-пароль в коде, который попадает в Git. Используйте .env файлы и добавьте .env в .gitignore. Это базовая гигиена.

Правило второе: используйте API-ключи с минимальными правами. В SendGrid можно создать API-ключ только с правом "Mail Send" — он не сможет управлять списками, настройками или другими функциями аккаунта. Если ключ утечёт — ущерб минимален.

Правило третье: для продакшн-серверов ограничьте исходящие SMTP-соединения только нужными хостами. В Nginx или через iptables можно разрешить исходящий трафик на конкретный IP SMTP-провайдера и закрыть всё остальное. Это предотвращает использование вашего сервера для рассылки спама через другие каналы, если он будет скомпрометирован.

Правило четвёртое: настройте уведомления о необычной активности. Postmark и SendGrid умеют присылать алерты, если объём отправки резко вырос. Если ваш сайт обычно шлёт 100 писем в день, а вдруг пошли 10 000 — это повод немедленно проверить, что происходит.

Итоги и практические рекомендации

Если обобщить всё вышесказанное: mail() забудьте, SMTP через PHPMailer или нативные инструменты фреймворка — это минимум. Идеально — HTTP API от специализированного сервиса плюс правильно настроенные DNS-записи.

По выбору провайдера: для новых проектов в 2026 году я смотрю на Resend (если Laravel) или Postmark (если нужна максимальная доставляемость). Для российской аудитории с акцентом на Mail.ru и Яндекс — SMTP.ru или UniSender. Для WordPress — WP Mail SMTP с SendGrid это проверенная связка, работает без сюрпризов.

По безопасности: .env файлы, API-ключи с минимальными правами, мониторинг объёма отправки. Если нужна помощь с настройкой — обращайтесь в поддержку WordPress или поддержку Битрикс, в зависимости от вашей CMS.

И последнее: после настройки обязательно проверяйте доставляемость через mail-tester.com и смотрите статистику в личном кабинете SMTP-провайдера. Bounce rate выше 5% — сигнал тревоги, надо чистить базу. Open rate ниже 15% на транзакционных письмах — скорее всего проблемы с попаданием в спам. Всё это лечится, но лучше поймать на старте, чем через полгода.