Почему не работает PHPMailer, полный разбор ошибок mail(), SMTP и Composer в PHP

Когда PHP-приложение перестаёт отправлять почту, разработчик почти всегда начинает искать проблему в коде:

SMTP connect() failed

или

Could not instantiate mail function

На первый взгляд кажется, что неисправен PHPMailer или сломалась функция mail(). Однако практика показывает обратное: библиотека обычно оказывается лишь точкой, в которой проявляется проблема, а не её источником.

За последние годы сформировалась интересная закономерность: чем убедительнее выглядит сообщение об ошибке, тем дальше находится её настоящая причина.

Ошибка №1. Could not instantiate mail function

Рассмотрим простой код:

<?php

$result = mail(
    '[email protected]',
    'Test',
    'Hello'
);

var_dump($result);

При выполнении можно получить:

Could not instantiate mail function

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

Проверить наличие локального MTA можно командой:

which sendmail

Если команда ничего не возвращает, PHP физически не имеет механизма отправки почты.

Для более глубокой диагностики полезно посмотреть конфигурацию:

php -i | grep sendmail

Почему ошибка mail() часто означает проблему Linux

Функция mail() в PHP практически не занимается отправкой сообщений самостоятельно.

Упрощённая схема выглядит следующим образом:

Именно поэтому ошибка PHP зачастую означает проблему совершенно другого компонента системы.

Ошибка №2. Class PHPMailer not found

Одна из самых распространённых ошибок:

Fatal error: Class 'PHPMailer' not found

Типичный код выглядит так:

use PHPMailer\PHPMailer\PHPMailer;

$mail = new PHPMailer();

Однако в современных проектах этого недостаточно.

Правильное подключение:

<?php

require __DIR__ . '/vendor/autoload.php';

use PHPMailer\PHPMailer\PHPMailer;

$mail = new PHPMailer(true);

Если ошибка остаётся, необходимо проверить целостность автозагрузчика:

composer validate
composer install
composer dump-autoload

Интересно, что повреждённый кэш Composer способен воспроизводить ошибку даже при корректной структуре проекта.

Ошибка №3. SMTP connect() failed

Это, вероятно, самое известное сообщение PHPMailer:

SMTP Error: Could not connect to SMTP host.
SMTP connect() failed.

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

На практике проблема обычно находится в одном из пяти мест.

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

nc -vz smtp.gmail.com 587

Если соединение отсутствует, PHP и PHPMailer можно исключить из списка подозреваемых.

Ошибка №4. Gmail отклоняет пароль

Многие старые руководства до сих пор предлагают следующий код:

$mail->Username = '[email protected]';
$mail->Password = 'mypassword';

В современных версиях Google Workspace и Gmail такой подход обычно не работает.

Корректная конфигурация выглядит так:

$mail->isSMTP();

$mail->Host = 'smtp.gmail.com';
$mail->SMTPAuth = true;
$mail->Username = '[email protected]';
$mail->Password = $googleAppPassword;
$mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
$mail->Port = 587;

При отсутствии App Password сервер часто возвращает:

535 Authentication failed

При этом проблема находится не в PHPMailer, а в политике аутентификации Google.

Самая опасная ситуация: письмо отправлено, но пользователь ничего не получил

Это наиболее неприятный сценарий диагностики.

PHPMailer сообщает

Message has been sent

Логи не содержат ошибок, SMTP-соединение успешно, однако письмо отсутствует.

Причина обычно находится на уровне почтовой репутации.

Репутация IP Критическая

Например:

example.com TXT "v=spf1 include:_spf.google.com ~all"

Без корректных DNS-записей письмо может быть принято SMTP-сервером, но никогда не попасть во входящие.

Реальный случай диагностики

Во время миграции одного из PHP-проектов возникла ситуация, когда все проверки показывали успешную отправку:

• Composer работал корректно;

• PHPMailer инициализировался без ошибок;

• SMTP-аутентификация проходила;

• сервер возвращал успешный статус доставки.

Тем не менее пользователи не получали письма.

После нескольких часов анализа выяснилось, что VPS-провайдер блокировал исходящие SMTP-подключения на уровне инфраструктуры. Ошибка проявлялась в PHPMailer, но её настоящая причина находилась вне PHP-приложения.

Именно такие ситуации создают ложное впечатление, что неисправна библиотека.

Алгоритм правильной диагностики

На практике наиболее эффективной оказалась следующая последовательность проверки.

Парадоксально, но сам PHPMailer обычно проверяется последним.

Вывод

За годы работы с PHP-проектами удалось прийти к неожиданному выводу:

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

Библиотека чаще всего выступает лишь индикатором неисправности, расположенной в другом слое системы — сети, инфраструктуре, DNS или почтовой конфигурации.

Именно поэтому успешная диагностика почты в PHP заключается не в поиске ошибки внутри PHPMailer, а в последовательном исключении проблем на каждом уровне архитектуры.