Письма с сайта пропадают: SMTP, SPF, DKIM и DMARC на пальцах

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

Не обязательно.

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

остаться в очереди;
быть отклонено сервером получателя;
вернуться на неправильный адрес;
не пройти SPF;
получить повреждённую DKIM-подпись;
провалить DMARC;
попасть в спам из-за репутации;
быть ограничено по частоте;
уйти с неожиданного домена;
отправиться через старый сервер после переезда;
вообще не запускаться, если отправка выполняется очередью.

Даже стандартная PHP-функция mail() возвращает true, когда сообщение принято для дальнейшей доставки. Это не означает, что оно дошло до почтового ящика получателя.

Поэтому диагностика почты начинается не с вопроса:

Почему Gmail не показывает письмо?

А с более точного:

До какого этапа дошло сообщение и что произошло дальше?

Почта сайта и почтовые ящики — не одна настройка

Владелец домена может использовать адрес:

[email protected]

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

для входящей почты сотрудников.

Одновременно сайт отправляет уведомления:

[email protected]

через совершенно другой сервис.

Это два независимых потока.

Входящая почта

Когда кто-то отправляет сообщение на:

[email protected]

почтовый сервер ищет MX-записи домена:

example.com    MX    10 mail.provider.example

Разместите сайт, проверьте скорость и оцените удобство Siteko.net. Просто выберите тариф и начните тестовый месяц.

MX сообщает, куда доставлять входящие письма для домена. SMTP-серверы сначала ищут MX, а при его отсутствии в некоторых сценариях могут использовать A или AAAA домена как запасной вариант.

Исходящая почта сайта

Приложение может отправлять через:

smtp.transactional-provider.example

с логином и паролем отдельного сервиса.

При этом MX продолжает указывать на корпоративную почту:

mail.provider.example

Схема выглядит так:

Входящие сообщения сотрудникам:

отправитель
    ↓
MX example.com
    ↓
корпоративная почта
    ↓
[email protected]


Исходящие сообщения сайта:

сайт
    ↓
SMTP-сервис
    ↓
сервер получателя
    ↓
покупатель

Изменение MX не настраивает отправку писем сайтом.

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

И настройка SMTP в Laravel, WordPress или другой системе не переносит входящие почтовые ящики.

Это особенно важно при переезде. Можно перенести сайт на новый хостинг, оставить MX у прежнего почтового провайдера и отправлять транзакционные сообщения через третий сервис.

Как письмо идёт от сайта к получателю

Упрощённый маршрут:

Приложение
    ↓
SMTP submission
    ↓
Исходящий почтовый сервер
    ↓
DNS-запрос MX домена получателя
    ↓
Почтовый сервер получателя
    ↓
Антиспам и проверка подлинности
    ↓
Входящие, спам, карантин или отказ

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

На каждом этапе возможен отдельный результат:

Приложение не сформировало письмо.
Приложение не подключилось к SMTP.
SMTP принял письмо в очередь.
Исходящий сервер не смог найти получателя.
Сервер получателя временно отказался принимать сообщение.
Сервер окончательно отклонил его.
Сообщение принято, но помещено в спам.
Сообщение доставлено, но пользователь его не заметил.

Фраза «отправлено» часто означает только второй или третий пункт.

Почему SMTP лучше простой отправки через `mail()`

Функция mail() может быть удобна для простого скрипта, но она скрывает значительную часть процесса.

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

с какого IP уходит сообщение;
какой Return-Path используется;
подписывается ли письмо DKIM;
где находится очередь;
какой ответ дал получатель;
куда приходят возвраты;
ограничена ли отправка;
какая репутация у общего IP.

При SMTP-аутентификации приложение подключается к конкретному сервису:

SMTP host
SMTP port
username
password
encryption

Это даёт более предсказуемую схему:

понятный провайдер отправки;
отдельные учётные данные;
журнал сообщений;
статистика доставок;
возвраты;
DKIM;
ограничения скорости;
управление репутацией;
иногда API и webhooks.

SMTP не гарантирует попадание во «Входящие», но делает путь сообщения наблюдаемым.

Порт 25, 587 или 465

Эти порты используются для разных задач.

Порт 25

Обычно применяется для передачи сообщений между почтовыми серверами:

почтовый сервер отправителя
    ↓ порт 25
почтовый сервер получателя

На клиентских серверах и VPS исходящий порт 25 иногда ограничивается для борьбы со спамом.

Для обычного приложения с логином и паролем это обычно не основной выбор.

Порт 587

Стандартный порт отправки сообщения клиентом на сервер submission. RFC 6409 закрепляет порт 587 для message submission, отделяя отправку авторизованным клиентом от серверной ретрансляции по порту 25.

Обычно используется:

порт 587
STARTTLS
SMTP AUTH

Соединение начинается как обычное SMTP и затем повышается до TLS.

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

Порт 465

Используется для SMTP submission с TLS с самого начала соединения:

порт 465
implicit TLS

Современные рекомендации признают защищённую отправку через такой режим наряду с submission через 587.

Какой выбрать

Используйте параметры, которые указал SMTP-провайдер.

Обычно:

587 + STARTTLS

или:

465 + TLS

Не подбирайте порт и тип шифрования методом случайного перебора. Комбинация должна совпадать с конфигурацией сервиса.

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

Пример SMTP-конфигурации PHP-приложения

Условный .env:

MAIL_MAILER=smtp
MAIL_HOST=smtp.provider.example
MAIL_PORT=587
MAIL_USERNAME=[email protected]
MAIL_PASSWORD=strong-generated-password
MAIL_ENCRYPTION=tls

MAIL_FROM_ADDRESS=[email protected]
MAIL_FROM_NAME="Example Store"

Для порта 465 конкретный фреймворк может ожидать другое обозначение режима:

MAIL_PORT=465
MAIL_ENCRYPTION=ssl

или DSN с smtps.

Синтаксис зависит от используемой библиотеки. Не копируйте значение ssl или tls из чужого примера без проверки документации проекта.

После изменения конфигурации Laravel может продолжать использовать старые значения из кэша:

php artisan optimize:clear

Затем можно вернуть production-оптимизацию:

php artisan optimize

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

Пароль SMTP не следует хранить в репозитории. Он находится в .env, секретах CI/CD или системе управления конфигурацией.

Используйте отдельную учётную запись для сайта

Не стоит подключать интернет-магазин к личному ящику директора:

[email protected]

Лучше создать отдельный источник:

[email protected]

или:

[email protected]

Преимущества:

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

Для крупного проекта полезно разделять потоки:

[email protected]  — системные уведомления
[email protected]         — заказы
[email protected]       — входы и восстановление
[email protected]           — рассылки

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

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

У письма несколько отправителей

Получатель обычно видит:

From: Example Store <[email protected]>

Но внутри SMTP существуют и другие идентификаторы.

`From`

Это видимый автор сообщения:

From: [email protected]

Именно этот домен используется DMARC как Author Domain.

`Reply-To`

Адрес, на который следует отправить ответ:

Reply-To: [email protected]

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

Он может отличаться от From.

Envelope From

Адрес, переданный SMTP-командой MAIL FROM.

После доставки он часто отображается как:

Return-Path: [email protected]

На него приходят автоматические сообщения о недоставке.

DKIM-домен

Указывается внутри подписи:

DKIM-Signature: ... d=example.com; s=mailer1; ...

Это домен, который криптографически подписал сообщение.

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

Для успешного DMARC видимый From должен быть согласован хотя бы с доменом SPF или DKIM.

Главная ошибка контактных форм

Посетитель заполняет форму:

Имя: Иван
Email: [email protected]
Сообщение: Нужна консультация

Разработчик формирует письмо:

From: [email protected]
To: [email protected]

Но отправляет его сервер сайта.

Получается, что сервер хостинга заявляет:

Я отправляю письмо от имени gmail.com.

Сервер не принадлежит Google и не авторизован отправлять сообщения от gmail.com. SPF, DKIM и DMARC могут закономерно провалиться.

Правильная схема:

From: Website Form <[email protected]>
Reply-To: Иван <[email protected]>
To: [email protected]

Теперь:

письмо отправляется от вашего домена;
ваш SMTP-сервис может его аутентифицировать;
сотрудник нажимает «Ответить» и пишет посетителю;
домен пользователя не подделывается.

Для любых форм используйте адрес посетителя в Reply-To, а не в From.

Что делает SPF

SPF — Sender Policy Framework.

Владелец домена публикует DNS-запись, перечисляющую серверы, которым разрешено использовать домен в SMTP Envelope From.

Пример:

example.com    TXT    "v=spf1 ip4:203.0.113.25 -all"

Упрощённо запись говорит:

IP 203.0.113.25 разрешён.
Остальные не разрешены.

Получатель сравнивает IP подключившегося SMTP-сервера с политикой домена. SPF стандартизирован RFC 7208.

SPF проверяет не обязательно видимый `From`

Письмо может содержать:

From: [email protected]
Return-Path: [email protected]

SPF проверит домен Envelope From:

mailer-provider.example

Он может пройти, но видимый From использует:

example.com

Для DMARC эти домены должны быть согласованы. Просто spf=pass ещё не гарантирует dmarc=pass.

Примеры SPF-записей

Один IP

v=spf1 ip4:203.0.113.25 -all

IPv4 и IPv6

v=spf1 ip4:203.0.113.25 ip6:2001:db8::25 -all

Почтовый сервис

Провайдер может дать:

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

Несколько источников

Например, корпоративная почта и сервис транзакционных писем:

v=spf1 include:_spf.workspace.example include:spf.transactional.example -all

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

Не придумывайте include по названию компании.

У домена должна быть одна SPF-политика

Ошибка:

example.com TXT "v=spf1 include:_spf.provider-a.example -all"
example.com TXT "v=spf1 include:_spf.provider-b.example -all"

Два отдельных SPF-record не объединяются автоматически.

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

RFC 7208 запрещает публиковать несколько записей, из-за которых проверка выбирает более одной SPF-политики; результатом может стать permerror.

Нужно объединить источники:

v=spf1 include:_spf.provider-a.example include:_spf.provider-b.example -all

Остальные TXT-записи домена — подтверждения сервисов, DKIM или произвольные значения — могут существовать рядом. Ограничение относится именно к нескольким TXT-значениям, начинающимся с v=spf1.

Лимит DNS-запросов SPF

Механизмы:

include
a
mx
exists
redirect

могут вызывать дополнительные DNS-запросы.

SPF ограничивает число таких механизмов и модификаторов десятью. При превышении получатель должен вернуть permerror. Механизмы ip4 и ip6 не расходуют этот лимит во время проверки.

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

Проблема часто появляется постепенно:

корпоративная почта
CRM
интернет-магазин
сервис рассылок
helpdesk
старый хостинг

Каждый поставщик добавляет include, который внутри содержит другие include.

Внешне запись остаётся короткой, но фактическая цепочка превышает десять запросов.

Не применяйте автоматическое «SPF flattening» без понимания последствий: IP-адреса провайдера могут меняться, а статическая копия устареет.

Лучше:

удалить неиспользуемые источники;
разделить потоки по поддоменам;
использовать DKIM-выравнивание для DMARC;
следить за глубиной include;
регулярно проверять SPF после подключения нового сервиса.

`~all` и `-all`

Конец SPF-записи определяет результат для остальных серверов.

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

Softfail

~all

Сообщает, что остальные источники не предполагаются, но оставляет получателю больше свободы в обработке.

Fail

-all

Явно говорит, что остальные источники не авторизованы.

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

сайт;
корпоративную почту;
CRM;
helpdesk;
сервис рассылок;
платёжную систему, если она отправляет от вашего домена;
старые приложения;
резервные SMTP-серверы.

Иначе вы начнёте отклонять собственные сообщения.

Что SPF не делает

SPF не:

подписывает содержание письма;
гарантирует попадание во «Входящие»;
проверяет адрес Reply-To;
предотвращает похожие домены;
доказывает, что сообщение не изменили;
заменяет DKIM и DMARC;
переживает обычную пересылку во всех случаях.

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

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

Что делает DKIM

DKIM — DomainKeys Identified Mail.

Исходящий сервер создаёт криптографическую подпись для выбранных заголовков и тела письма.

В сообщение добавляется:

DKIM-Signature:
    v=1;
    d=example.com;
    s=mailer1;
    ...

Здесь:

d=example.com

— домен подписи;

s=mailer1

— selector, то есть имя используемого ключа.

Получатель запрашивает открытый ключ в DNS:

mailer1._domainkey.example.com

и проверяет подпись.

DKIM хранит данные подписи в заголовке DKIM-Signature; подпись связывает домен, selector, заголовки и тело сообщения.

Как выглядит DKIM-запись

Упрощённый пример:

mailer1._domainkey.example.com
TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Поле:

p=

содержит открытый ключ.

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

Его нельзя публиковать в DNS, репозитории или тикете поддержки.

Зачем нужен selector

Selector позволяет использовать несколько ключей:

site._domainkey.example.com
marketing._domainkey.example.com
support._domainkey.example.com

Это полезно для:

разных сервисов;
постепенной ротации;
отключения одного поставщика;
разделения потоков;
расследования проблем.

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

DKIM защищает от изменения сообщения

Получатель рассчитывает подпись заново.

Если после подписания изменили важную часть письма:

тело;
подписанный заголовок;
MIME-структуру;
тему, если она включена в подпись,

проверка может завершиться ошибкой.

Это помогает подтвердить, что сообщение подписано владельцем домена и не было незаметно изменено по дороге.

Однако некоторые почтовые посредники:

добавляют рекламный текст;
переписывают тему;
меняют ссылки;
перестраивают MIME;
добавляют подпись списка рассылки.

Такая обработка способна повредить DKIM.

DKIM и пересылка

Обычная пересылка часто сохраняет исходное содержимое, поэтому DKIM может продолжить проходить, даже когда SPF уже провалился из-за нового IP.

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

Это одна из причин настраивать оба механизма.

Но DKIM тоже не гарантированно переживает:

mailing list;
изменение тела;
добавление футера;
антивирусную модификацию;
некорректную перекодировку.

Размер DKIM-ключа

Google требует для отправки на личные Gmail-адреса ключ DKIM не короче 1024 бит и рекомендует 2048 бит, если провайдер поддерживает такой размер.

Сегодня разумный стандартный выбор — 2048-битный RSA-ключ либо другой современный алгоритм, поддерживаемый обеими сторонами и сервисом отправки.

Не генерируйте ключ вручную, если почтовый провайдер уже выдаёт готовую DNS-запись и самостоятельно хранит закрытую часть.

Что DKIM не делает

DKIM не:

определяет, разрешён ли конкретный IP через SPF;
гарантирует хорошую репутацию;
запрещает другому домену подписать собственное мошенническое письмо;
требует совпадения d= с видимым From сам по себе;
гарантирует доставку;
заменяет DMARC.

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

Злоумышленник может подписать письмо своим доменом:

d=attacker.example

и поставить:

From: [email protected]

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

Именно эту связь проверяет DMARC.

Что делает DMARC

DMARC — Domain-Based Message Authentication, Reporting, and Conformance.

Он отвечает на три вопроса:

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

Прошёл ли SPF или DKIM?
Согласован ли успешный домен с видимым From?
Что получателю делать, если проверка не пройдена?

В мае 2026 года основной протокол DMARC был обновлён RFC 9989; вместе с RFC 9990 и RFC 9991 новые документы заменили прежний RFC 7489 и разделили основной протокол и форматы отчётности.

Что такое alignment

Рассмотрим письмо:

From: [email protected]

SPF-идентификатор

Return-Path: [email protected]

SPF прошёл для:

example.com

Он согласован с видимым From.

DKIM-идентификатор

DKIM-Signature: ... d=example.com; ...

DKIM прошёл для:

example.com

Он тоже согласован.

DMARC проходит, если хотя бы один из механизмов:

SPF;
DKIM

успешен и его домен выровнен с доменом видимого From.

Пример: SPF прошёл, DMARC нет

From: [email protected]
Return-Path: [email protected]

SPF:

spf=pass smtp.mailfrom=provider.example

Но:

provider.example ≠ example.com

SPF не выровнен.

Если DKIM отсутствует или подписывает:

d=provider.example

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

DMARC провалится.

Поэтому SMTP-провайдер обычно предлагает настроить:

custom Return-Path;
MAIL FROM domain;
bounce domain;
DKIM domain.

Это позволяет использовать ваш домен или поддомен:

bounce.mail.example.com

и пройти relaxed alignment.

Строгое и мягкое выравнивание

Relaxed alignment

Домены имеют общий организационный домен:

From: [email protected]
Return-Path: [email protected]

Оба относятся к:

example.com

Это relaxed alignment.

Strict alignment

Домены должны совпадать точно:

example.com = example.com

DMARC поддерживает оба режима, но почти все владельцы доменов используют relaxed alignment как достаточный для практических задач.

DMARC-запись

Публикуется по адресу:

_dmarc.example.com

Пример режима наблюдения:

v=DMARC1; p=none; rua=mailto:[email protected]

Здесь:

v=DMARC1 — версия;
p=none — не просить получателя применять санкции;
rua — адрес агрегированных отчётов.

Политики DMARC

`p=none`

v=DMARC1; p=none

Режим наблюдения.

Сообщения не должны обрабатываться иначе только из-за этой политики, но владелец может собирать отчёты и видеть источники отправки. RFC 9989 рекомендует начинать внедрение с p=none, чтобы найти забытые и неправильно настроенные системы.

`p=quarantine`

v=DMARC1; p=quarantine

Просьба относиться к сообщениям, провалившим DMARC, как к подозрительным — например помещать в спам или карантин.

`p=reject`

v=DMARC1; p=reject

Просьба отклонять сообщения, не прошедшие DMARC.

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

Не начинайте сразу с `p=reject`

У домена могут отправлять:

хостинг;
сайт;
бухгалтерская система;
CRM;
helpdesk;
сервис рассылок;
облачная почта;
платёжная система;
старый сервер;
тестовое окружение;
внешнее агентство.

Если хотя бы один источник не настроен, p=reject может начать блокировать легитимные письма.

Безопасная последовательность:

1. SPF и DKIM
2. DMARC p=none
3. Сбор и анализ отчётов
4. Исправление всех источников
5. p=quarantine
6. Проверка
7. p=reject

DMARC-отчёты

Агрегированные отчёты показывают:

какие IP отправляли от вашего домена;
сколько сообщений прошло SPF;
сколько прошло DKIM;
какие домены были выровнены;
какая политика применялась;
какие неизвестные источники появились.

Они обычно приходят в машинно-читаемом формате и удобнее анализируются специализированным сервисом, чем вручную. RFC 9989 прямо отмечает, что агрегированные отчёты рассчитаны прежде всего на машинный разбор.

Не направляйте отчёты в обычный рабочий ящик:

[email protected]

Лучше использовать:

[email protected]

или отдельный сервис обработки.

SPF, DKIM и DMARC — не конкуренты

Они решают разные задачи.

Механизм	Что проверяет
SPF	Разрешён ли подключившийся IP для Envelope From
DKIM	Подписано ли сообщение доменом и не повреждено ли оно
DMARC	Согласованы ли SPF/DKIM с видимым `From`, и как обрабатывать сбой
MX	Куда принимать входящую почту
SMTP	Как передавать исходящие сообщения
PTR	Как IP отправителя представляется в обратном DNS
TLS	Шифруется ли соединение между сторонами

Нельзя «выбрать DKIM вместо SPF» в общей архитектуре.

Для надёжной отправки обычно настраивают все три:

SPF + DKIM + DMARC

PTR и обратный DNS

Обычный DNS связывает имя с IP:

mail.example.com → 203.0.113.25

PTR делает обратное:

203.0.113.25 → mail.example.com

Почтовые системы используют обратный DNS как один из сигналов корректности инфраструктуры.

Google требует, чтобы у отправляющих доменов или IP существовали согласованные прямые и обратные DNS-записи.

PTR нельзя обычно изменить в DNS-панели домена.

Его настраивает владелец IP:

хостинг;
облачный провайдер;
оператор VPS;
SMTP-сервис.

Если вы отправляете через внешний SMTP, PTR обслуживает этот провайдер.

Если вы поднимаете почтовый сервер на VPS, нужно запросить настройку PTR у владельца IP.

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

Хорошая схема:

203.0.113.25 PTR mail.example.com
mail.example.com A 203.0.113.25

HELO/EHLO

SMTP-сервер представляется получателю:

EHLO mail.example.com

Имя должно быть осмысленным и корректно разрешаться в DNS.

Случайное значение:

localhost
server
ubuntu

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

При использовании управляемого SMTP HELO, PTR и исходящие IP настраивает поставщик.

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

TLS при передаче почты

TLS шифрует SMTP-соединение.

Важно различать:

TLS между приложением и SMTP submission;
TLS между почтовым сервером отправителя и сервером получателя.

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

Но обычная SMTP-доставка между серверами исторически может работать в opportunistic-режиме: стороны используют TLS, когда обе его поддерживают.

Наличие TLS не заменяет SPF, DKIM или DMARC. Оно защищает канал, а не подтверждает право использовать видимый домен отправителя.

Аутентификация не гарантирует попадание во «Входящие»

Письмо может показывать:

spf=pass
dkim=pass
dmarc=pass

и всё равно попасть в спам.

Почтовые системы дополнительно оценивают:

репутацию домена;
репутацию IP;
жалобы пользователей;
историю отправки;
резкий рост объёмов;
качество списка;
вовлечённость;
содержание;
ссылки;
вложения;
долю несуществующих адресов;
сходство со спамом;
частоту сообщений.

Аутентификация отвечает:

Кто отправил письмо?

Она не отвечает:

Хотят ли получатели его получать?

Транзакционные и маркетинговые письма

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

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

подтверждение заказа;
восстановление пароля;
чек;
уведомление о входе;
статус доставки;
подтверждение регистрации.

Маркетинговые

Отправляются по инициативе компании:

акции;
подборки;
новости;
рекламные предложения;
напоминания;
массовые кампании.

Лучше разделять потоки:

transactional.example.com
marketing.example.com

или хотя бы:

[email protected]
[email protected]

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

Yahoo прямо рекомендует не отправлять bulk-почту с тех же IP, что используются для пользовательских и транзакционных сообщений.

Современные требования Gmail и Yahoo

Начиная с 2024 года Gmail требует от всех отправителей на личные Gmail-адреса как минимум SPF или DKIM, корректный прямой и обратный DNS и TLS. Для отправителей свыше 5000 сообщений в сутки на Gmail необходимы SPF, DKIM и DMARC, а домен видимого From должен быть выровнен со SPF или DKIM. Для маркетинговых и подписных сообщений также требуется удобная отписка, включая one-click unsubscribe. Эти правила продолжают действовать в 2026 году.

Yahoo также требует от bulk-отправителей SPF, DKIM и DMARC и учитывает аутентификацию, жалобы и качество отправки.

Даже если сайт отправляет меньше 5000 писем, настройка SPF, DKIM и DMARC остаётся разумной базой.

One-click unsubscribe

Для массовой подписной почты одного текста:

Чтобы отписаться, ответьте на это письмо

уже недостаточно.

Стандарт RFC 8058 использует заголовки:

List-Unsubscribe:
    <https://example.com/unsubscribe/token>

List-Unsubscribe-Post:
    List-Unsubscribe=One-Click

Получатель может выполнить HTTPS POST и отписать пользователя без перехода через сложную форму или входа в аккаунт. Эти заголовки должны быть покрыты действительной DKIM-подписью.

One-click unsubscribe предназначен для рассылок и подписных сообщений, а не для обязательных транзакционных уведомлений вроде чеков или сброса пароля.

В теле маркетингового письма всё равно должна быть видимая ссылка на отписку.

Не отправляйте рассылку функцией сайта

Сайт может технически сформировать 50 000 сообщений и передать их SMTP-серверу.

Но для массовой рассылки нужны:

управление подписками;
double opt-in;
отписка;
suppression list;
обработка возвратов;
ограничение скорости;
контроль жалоб;
прогрев домена и IP;
сегментация;
статистика;
защита репутации;
повтор временных ошибок.

Это работа специализированной платформы.

Обычный SMTP-тариф хостинга может иметь ограничения:

100 писем в час
500 писем в сутки
ограничение числа получателей

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

Репутация общего IP

На виртуальном хостинге несколько клиентов могут отправлять почту через общий IP.

Преимущества:

провайдер управляет сервером;
не нужно прогревать собственный IP;
PTR и инфраструктура уже настроены.

Недостатки:

поведение соседей может влиять на репутацию;
меньше контроля;
строгие лимиты;
один IP используется для разных типов сообщений.

Хороший провайдер:

ограничивает массовую отправку;
блокирует заражённые аккаунты;
следит за очередями;
обрабатывает жалобы;
разделяет потоки;
исключает IP из блок-листов;
предоставляет SMTP с аутентификацией.

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

Выделенный IP не всегда лучше

Новый выделенный IP не имеет положительной истории.

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

новый IP
новый домен
резкий объём
низкая история взаимодействия

Это выглядит подозрительно.

Выделенный IP полезен при достаточном стабильном объёме и наличии специалиста, который контролирует репутацию.

Для небольшого сайта качественный общий пул SMTP-провайдера часто работает лучше.

Как проверить DNS-настройки почты

MX

dig +short example.com MX

Пример:

10 mail.provider.example.

Это только входящая почта.

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

SPF

dig +short example.com TXT

Найдите значение:

v=spf1 ...

Убедитесь, что оно одно.

DKIM

Selector сообщает SMTP-провайдер.

Например:

dig +short mailer1._domainkey.example.com TXT

Ожидается:

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

Некоторые сервисы используют CNAME:

dig +short mailer1._domainkey.example.com CNAME

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

DMARC

dig +short _dmarc.example.com TXT

Например:

v=DMARC1; p=none; rua=mailto:[email protected]

Как проверить SMTP-соединение

Для порта 587 с STARTTLS:

openssl s_client \
    -starttls smtp \
    -connect smtp.provider.example:587 \
    -servername smtp.provider.example

Для порта 465:

openssl s_client \
    -connect smtp.provider.example:465 \
    -servername smtp.provider.example

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

250-AUTH PLAIN LOGIN
250-STARTTLS
250 SIZE ...

Возможные проблемы:

Connection refused

— порт закрыт или сервис не слушает;

Connection timed out

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

— firewall или сеть блокирует соединение;

certificate verify failed

— неверный сертификат SMTP-сервера или старое окружение;

authentication failed

— неверный логин, пароль или способ AUTH.

Не вводите реальные пароли в команды, которые сохраняются в истории shell, если не понимаете последствий.

Проверьте, не блокирует ли хостинг исходящие соединения

Некоторые хостинги разрешают отправку только:

через локальный MTA;
через собственный SMTP;
на определённые порты;
после обращения в поддержку.

Если приложение не соединяется с внешним SMTP:

Connection timed out

проверьте доступность:

nc -vz smtp.provider.example 587

или TLS-командой OpenSSL.

Но отсутствие соединения может быть также вызвано:

DNS;
IPv6;
firewall SMTP-провайдера;
неправильным портом;
блокировкой вашего IP;
временной аварией.

Как это устроено на Siteko. Отправка почты с виртуального хостинга по умолчанию выключена — это та же защита общей репутации IP, о которой шла речь в статье про «безлимитный» хостинг: один заражённый сайт не должен отправлять письма соседей в спам. На платных тарифах отправка включается по запросу в поддержку — после этого работают и mail(), и SMTP через ящик на вашем домене (ящик создаётся в панели, там же видны параметры подключения). На пробном периоде отправка недоступна. Аутентификация настраивается без ручной возни с ключами: SPF-запись для сервера хостинга добавляется в DNS-зону автоматически вместе с доменом, а DKIM включается в настройках почтового домена в панели — ключ и DNS-запись создаются сами, письма подписываются вашим доменом, то есть выровнены для DMARC. Отправка через внешний SMTP-сервис под это ограничение не попадает: приложение подключается к провайдеру напрямую; для массовых рассылок и серьёзных объёмов мы по-прежнему рекомендуем специализированный сервис.

Проверьте очередь приложения

В Laravel письмо может отправляться не сразу:

Mail::to($user)->queue(new OrderCreated($order));

HTTP-запрос успешно добавляет задание в очередь:

Письмо поставлено в очередь.

Но worker не работает.

Симптомы:

заказ создаётся;
ошибок SMTP в веб-логе нет;
задания накапливаются;
письмо появляется только после ручного запуска worker.

Проверьте:

php artisan queue:work --stop-when-empty

Состояние failed jobs:

php artisan queue:failed

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

Успех постановки в очередь — не успех SMTP-отправки.

Проверьте журнал приложения

Ищите:

Could not connect to host
Connection timed out
Authentication failed
535 Incorrect authentication data
Expected response code 250
Connection unexpectedly closed
TLS negotiation failed

Laravel:

tail -n 200 storage/logs/laravel.log

Symfony:

tail -n 200 var/log/prod.log

Если используется очередь, ошибка может находиться в журнале worker, а не веб-запроса.

Проверьте журнал SMTP-провайдера

Хороший сервис показывает этапы:

accepted
queued
delivered
deferred
bounced
blocked
complained
opened

Accepted

Провайдер принял сообщение от приложения.

Delivered

Удалённый сервер подтвердил приём.

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

Это всё ещё не всегда означает папку «Входящие»: сервер получателя мог позднее классифицировать сообщение как спам.

Deferred

Временная ошибка. Провайдер попробует позже.

Bounced

Постоянный отказ:

ящик не существует;
домен не принимает почту;
политика отклонила сообщение;
адрес заблокирован.

Complaint

Получатель нажал «Спам».

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

Коды SMTP: 4xx и 5xx

4xx

Временная ошибка:

421 Service not available
450 Mailbox unavailable
451 Temporary local problem
452 Insufficient storage

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

5xx

Постоянная ошибка:

550 User unknown
552 Message too large
553 Invalid recipient
554 Message rejected

Автоматический повтор без изменения причины обычно бессмысленен.

Коды часто дополняются расширенным статусом:

5.7.26

Например, Gmail использует 5.7.26 для отдельных отказов, связанных с аутентификацией и политикой SPF/DKIM/DMARC.

Сохраняйте полный текст ответа, а не только число 550.

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

Письмо принято, но не пришло

Проверьте по порядку.

1. Правильный ли адрес

Опечатка:

[email protected]

может выглядеть правдоподобно.

2. Есть ли bounce

Если указан корректный Return-Path, сообщение о недоставке должно попасть в журнал SMTP-сервиса или специальный ящик.

3. Доставлено ли на сервер получателя

Статус delivered означает, что сервер получателя ответил успешным кодом.

4. Где письмо внутри ящика

Проверьте:

спам;
промоакции;
карантин;
фильтры;
правила пересылки;
заблокированных отправителей;
полный поиск по адресу и теме.

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

5. Не удаляет ли его корпоративный фильтр

В корпоративной инфраструктуре сообщение может быть принято внешним gateway, но заблокировано внутренней политикой.

Как посмотреть заголовки полученного письма

Отправьте тест на ящик, где сообщение дошло, и откройте «Показать оригинал» или «Исходный код сообщения».

Ищите:

Authentication-Results:
    spf=pass
    dkim=pass
    dmarc=pass

Также полезны:

Return-Path:
Received:
DKIM-Signature:
Message-ID:
From:
Reply-To:

Пример:

Authentication-Results:
    spf=pass [email protected];
    dkim=pass header.d=example.com;
    dmarc=pass header.from=example.com

Это хороший результат:

SPF прошёл;
DKIM прошёл;
DMARC прошёл;
видимый From согласован.

Если SPF прошёл, а DKIM провалился

Возможные причины:

неверная DNS-запись ключа;
используется другой selector;
запись добавлена не в авторитетную DNS-зону;
ключ ещё кэшируется;
SMTP подписывает старым закрытым ключом;
письмо изменяется после подписи;
часть серверов отправителя использует другую конфигурацию.

Проверьте из письма:

d=example.com
s=mailer1

Затем:

dig +short mailer1._domainkey.example.com TXT

Не проверяйте selector, который вы предполагаете. Берите его из фактического заголовка.

Если DKIM прошёл, а DMARC провалился

Смотрите домен подписи:

header.d=provider.example

и видимый адрес:

header.from=example.com

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

DKIM математически корректен, но домены не выровнены.

Нужно подключить custom DKIM для вашего домена:

d=example.com

или согласованного поддомена.

Если SPF прошёл, а DMARC провалился

Смотрите:

smtp.mailfrom=provider.example
header.from=example.com

Потребуется custom Return-Path или bounce domain, либо выровненная DKIM-подпись.

Для DMARC достаточно одного успешно выровненного механизма, но лучше иметь корректные SPF и DKIM одновременно.

Если всё проходит, но письмо в спаме

Проверьте:

репутацию домена;
репутацию IP;
жалобы;
возраст домена;
резкий рост объёма;
качество базы;
наличие согласия;
число недействительных адресов;
ссылки и домены внутри письма;
сокращатели URL;
вложения;
HTML-разметку;
текстовую альтернативу;
частоту отправки;
одинаковые сообщения многим получателям.

Google рекомендует держать долю жалоб в Postmaster Tools ниже 0,3%, а также следить за аутентификацией и практиками отправки.

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

Прогрев отправки

Новый домен или IP не следует сразу использовать для максимального объёма.

Разумный рост:

небольшой объём
    ↓
реальные активные пользователи
    ↓
контроль возвратов и жалоб
    ↓
постепенное увеличение

Резкий переход:

0 писем в день
    ↓
50 000 писем за час

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

выглядит подозрительно.

Но «прогрев» не спасёт купленный список адресов или нежелательную рассылку. Главный фактор — законные ожидаемые сообщения реальным получателям.

Не покупайте базы адресов

Покупной список обычно содержит:

старые адреса;
несуществующие ящики;
пользователей без согласия;
spam traps;
адреса, уже получающие много спама.

Результат:

возвраты;
жалобы;
блокировка;
ухудшение доменной репутации;
проблемы с транзакционными письмами.

Для подписных сообщений используйте подтверждение адреса и понятную отписку. Google рекомендует подтверждать email до отправки подписных сообщений.

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

Возможная структура:

example.com

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

— основной сайт и корпоративная почта;

mail.example.com

— транзакционные письма;

news.example.com

— маркетинговые рассылки.

Преимущества:

проще разделить SPF;
отдельные DKIM selectors;
понятнее DMARC-отчёты;
легче менять поставщика;
меньше влияние маркетинга на основной поток.

Но использование поддомена не отменяет репутацию организационного домена полностью. Почтовые системы всё равно могут связывать потоки.

Не создавайте новый поддомен для каждой неудачной кампании — это выглядит как попытка уйти от репутации.

Не используйте адрес `no-reply`, если ответ может быть полезен

Адрес:

[email protected]

подходит не всегда.

Получатель может хотеть:

уточнить заказ;
сообщить об ошибке;
предупредить о мошенничестве;
задать вопрос;
указать, что письмо пришло не тому человеку.

Можно отправлять:

From: Example Store <[email protected]>
Reply-To: [email protected]

Если ответы действительно не обрабатываются, объясните это в сообщении и предоставьте другой канал связи.

Message-ID

Письмо должно иметь уникальный заголовок:

Message-ID: <[email protected]>

Он помогает:

объединять цепочки;
искать сообщение в логах;
исключать дубли;
сопоставлять событие приложения и SMTP.

Почтовая библиотека обычно создаёт его автоматически.

Не формируйте один и тот же Message-ID для тысяч разных писем.

Размер письма

Письмо может быть отклонено из-за размера:

552 Message size exceeds fixed limit

Base64-кодирование вложений увеличивает их объём.

Файл размером 20 МБ может превратиться в сообщение заметно больше 20 МБ.

Для крупных файлов лучше:

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

Ошибки адреса отправителя

Плохие варианты:

From: wordpress@localhost
From: root@server
From: [email protected]
From: [email protected]

Хороший вариант:

From: Example Store <[email protected]>

Адрес должен:

использовать домен, который вы контролируете;
существовать или корректно обрабатывать возвраты;
быть согласован с DKIM или SPF;
не меняться случайно между сообщениями;
соответствовать назначению.

Письма с тестового окружения

Staging-сайт может случайно отправить реальные сообщения клиентам.

Защитные меры:

MAIL_MAILER=log

или перенаправление всех писем на тестовый ящик.

Также можно:

использовать sandbox SMTP;
блокировать внешних получателей;
добавлять [TEST] в тему;
использовать отдельный домен;
не копировать production SMTP-пароль в staging.

Особенно опасен staging с копией реальной базы и работающим cron.

Он способен повторно отправить:

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

Переезд сайта и почта

При переезде проверьте отдельно:

1. MX
2. SMTP
3. SPF
4. DKIM
5. DMARC
6. Return-Path
7. очереди
8. старый сервер

Частая ситуация:

сайт уже работает на новом хостинге;
SMTP всё ещё использует старый локальный сервер;
SPF разрешает только старый IP;
DKIM-подпись не создаётся;
письма начинают попадать в спам.

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

Или наоборот:

SMTP настроен правильно;
при смене NS забыли перенести MX;
сайт отправляет уведомления;
сотрудники перестали получать входящие письма.

Пошаговая диагностика: письмо не дошло

Шаг 1. Убедитесь, что код отправки выполнился

Проверьте:

лог приложения;
исключения;
очередь;
failed jobs;
правильный адрес получателя;
событие, которое запускает отправку.

Шаг 2. Проверьте SMTP-соединение

openssl s_client \
    -starttls smtp \
    -connect smtp.provider.example:587 \
    -servername smtp.provider.example

Шаг 3. Проверьте учётные данные

Типичная ошибка:

535 Authentication failed

Причины:

неверный пароль;
используется пароль обычного ящика вместо app password;
запрещён SMTP AUTH;
аккаунт заблокирован;
неверный логин;
доступ ограничен по IP.

Шаг 4. Проверьте, принял ли SMTP письмо

Ищите:

250 Accepted
250 Queued

или запись в панели провайдера.

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

Шаг 5. Найдите Message-ID

Сопоставьте:

журнал приложения;
журнал SMTP;
bounce;
заголовок полученного письма.

Шаг 6. Проверьте статус доставки

delivered
deferred
bounced
blocked

Шаг 7. Если письмо дошло хотя бы на один ящик, изучите заголовки

Ищите:

spf=
dkim=
dmarc=

Шаг 8. Проверьте DNS

dig +short example.com TXT
dig +short selector._domainkey.example.com TXT
dig +short _dmarc.example.com TXT

Шаг 9. Проверьте репутацию и жалобы

Для значимых объёмов используйте инструменты почтовых провайдеров, журналы SMTP и DMARC-отчёты.

Шаг 10. Исправьте одну проблему и повторите тест

Не меняйте одновременно:

SPF;
DKIM;
SMTP;
From;
Return-Path;
DMARC.

Иначе вы не поймёте, какое изменение повлияло на результат.

Быстрый чек DNS

DOMAIN="example.com"
SELECTOR="mailer1"

echo "=== MX ==="
dig +short MX "$DOMAIN"

echo
echo "=== SPF / TXT ==="
dig +short TXT "$DOMAIN"

echo
echo "=== DKIM ==="
dig +short TXT "$SELECTOR._domainkey.$DOMAIN"
dig +short CNAME "$SELECTOR._domainkey.$DOMAIN"

echo
echo "=== DMARC ==="
dig +short TXT "_dmarc.$DOMAIN"

Таблица: симптом, причина и следующее действие

Симптом	Вероятная причина	Что проверять
Приложение пишет «отправлено», письма нет	Сообщение только принято локально	Очередь и SMTP-лог
`Connection timed out`	Порт заблокирован или сеть недоступна	587/465 и firewall
`535 Authentication failed`	Неверный логин или пароль	SMTP-учётные данные
`550 User unknown`	Получателя не существует	Адрес
`552 Message too large`	Слишком крупное письмо	Вложения и лимиты
`spf=fail`	IP не разрешён	SPF и реальный отправляющий IP
`spf=permerror`	Несколько SPF или слишком много DNS-запросов	SPF-синтаксис
`dkim=fail`	Неверный ключ или письмо изменено	Selector и DKIM DNS
`dkim=none`	Письмо не подписывается	Настройки SMTP
`dmarc=fail` при `spf=pass`	SPF-домен не выровнен	Return-Path
`dmarc=fail` при `dkim=pass`	`d=` не выровнен с `From`	Custom DKIM
Работает на одном домене, не работает на другом	Разные политики или репутация	Заголовки и DNS
Письма уходят в спам	Репутация, жалобы или содержание	Postmaster, список и поток
Заказы есть, писем нет	Не работает queue worker	Очередь и cron
Входящие письма пропали после переезда	Потеряны MX	DNS-зона
Сайт отправляет, сотрудники не получают	Внутренний антиспам или маршрут	Корпоративный gateway
Контактная форма проваливает DMARC	`From` равен адресу посетителя	Использовать `Reply-To`
Письма дублируются	Повтор jobs или нет идемпотентности	Очередь и Message-ID
Письма приходят с задержкой	Временный 4xx и повтор	Deferred-лог
После смены DNS DKIM не проходит	Запись добавлена не у авторитетного DNS	NS и selector

Грабли почты сайта

Грабля	Результат	Решение
MX считают настройкой исходящей почты	Сайт продолжает отправлять старым способом	Настроить SMTP отдельно
`mail()` вернул `true`	Доставка ошибочно считается успешной	Проверить очередь и возвраты
В `From` ставят email посетителя	SPF/DMARC проваливаются	Перенести адрес в `Reply-To`
Создают две SPF-записи	Получатели видят `permerror`	Объединить в одну
Добавляют много `include`	Превышается лимит SPF	Аудит источников
DKIM DNS создан, но сервер не подписывает	`dkim=none`	Включить подпись у отправителя
Проверяют неправильный selector	DNS кажется отсутствующим	Взять `s=` из заголовка
Сразу включают `p=reject`	Блокируются собственные письма	Начать с `p=none`
Отчёты DMARC не читают	Неизвестные источники остаются незамеченными	Использовать анализатор
Рассылки смешаны с паролями и чеками	Жалобы портят транзакционную доставку	Разделить потоки
Рассылают покупной список	Растут bounce и complaints	Только согласившиеся получатели
Нет one-click unsubscribe	Массовая почта нарушает требования	RFC 8058 и видимая отписка
Используют личный SMTP-пароль	Компрометация рабочего ящика	Отдельная учётная запись
Не настроен PTR на VPS	Снижается доверие получателей	Запросить PTR у владельца IP
В staging включён production SMTP	Клиенты получают тестовые письма	Sandbox или log transport
После изменения `.env` не очищен кэш	Используется старый SMTP	Очистить конфигурацию
Игнорируют 4xx и 5xx	Письма теряются без диагноза	Сохранять полный SMTP-ответ

Что приложить к обращению в поддержку

Плохое обращение:

Письма не доходят. Проверьте почту.

Хостинг для сайта, который должен работать стабильно

Перенесите проект или запустите новый сайт на Siteko.net и протестируйте сервис без предоплаты.

Полезное:

Домен:
example.com

Приложение:
Laravel, production

SMTP:
smtp.provider.example
порт 587
STARTTLS

Время отправки:
23 июля 2026, 12:42

Получатель:
[email protected]

Message-ID:
<[email protected]>

Результат приложения:
сообщение передано SMTP без исключения

Результат SMTP-провайдера:
bounced

Полный ответ:
550 5.7.26 ...

DNS:
SPF — одна запись
DKIM selector — mailer1
DMARC — p=none

Заголовки другого доставленного теста:
spf=pass
dkim=pass
dmarc=fail

Authentication-Results показывает:
smtp.mailfrom=provider.example
header.from=example.com

Предполагаю отсутствие DMARC alignment для Return-Path
либо custom DKIM домена.

Для проблемы соединения:

Команда:
openssl s_client \
-starttls smtp \
-connect smtp.provider.example:587 \
-servername smtp.provider.example

Результат:
Connection timed out

Через порт 465 соединение устанавливается.
Подскажите правильный порт и режим TLS.

Не прикладывайте:

пароль SMTP;
закрытый DKIM-ключ;
полный .env;
персональные данные клиентов;
содержимое конфиденциальных писем.

Минимальный чек-лист почты сайта

Входящая почта

MX указывает на правильного провайдера?
Созданы ли ящики?
Сохранены ли MX после смены NS?

SMTP

Какой host?
Какой порт?
Какой режим TLS?
Какой логин?
Есть ли отдельный пароль приложения?
Разрешены ли исходящие соединения с хостинга?

Адреса

From использует ваш домен?
Reply-To задан правильно?
Return-Path обрабатывает возвраты?
Не подделяется ли адрес посетителя?

SPF

Запись только одна?
Все отправители перечислены?
Не превышено ли 10 DNS-запросов?
Удалены ли старые сервисы?

DKIM

Письмо реально подписывается?
Правильный ли selector?
DNS содержит открытый ключ?
Домен d= выровнен с From?

DMARC

Опубликована ли запись?
Начали ли с p=none?
Приходят ли aggregate reports?
Все ли законные источники найдены?
Безопасно ли переходить к quarantine/reject?

Репутация

Есть ли согласие получателей?
Обрабатываются ли bounce?
Исключаются ли жалобы?
Разделены ли transactional и marketing?
Есть ли отписка?
Не растёт ли объём резко?

Наблюдаемость

Есть ли SMTP-лог?
Хранятся ли полные ответы получателей?
Можно ли найти письмо по Message-ID?
Проверяется ли очередь приложения?

Что в итоге

Работающая функция отправки не означает доставленное письмо.

Почта проходит несколько уровней:

1. Приложение
Было ли письмо сформировано?

2. Очередь
Выполнилось ли задание?

3. SMTP submission
Принял ли сервер сообщение?

4. Исходящая доставка
Какой ответ дал получатель?

5. Аутентификация
Прошли ли SPF, DKIM и DMARC?

6. Репутация
Доверяет ли получатель отправителю?

7. Почтовый ящик
Куда было помещено письмо?

MX отвечает за входящую почту домена.

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

SMTP передаёт исходящие сообщения.

SPF сообщает, какие серверы разрешены.

DKIM подписывает сообщение доменом.

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

Но даже идеально настроенные SPF, DKIM и DMARC не дают права отправлять нежелательные письма. Доставляемость зависит также от репутации, жалоб, качества списка и ожидаемости сообщений.

Главный принцип: