Если письма с сайта попадают в спам, проблема не всегда в тексте письма или форме на сайте. Доставка зависит от всей цепочки: домена, DNS-записей, SMTP, IP-адреса, репутации сервера, заголовков письма и настроек CMS.
Для владельца сайта базовый чек-лист выглядит так:
- SPF разрешает тот сервер или SMTP-сервис, который реально отправляет письма;
- DKIM включён, и письма действительно подписываются;
- DMARC настроен хотя бы в мягком режиме;
- PTR-запись есть и указывает на нормальный hostname, прописанный в почтовом сервере;
- hostname сервера выглядит корректно;
- IP-адрес не находится в blacklist;
- У IP и домена нет плохой почтовой репутации;
- Письма отправляются через SMTP, а не через PHP mail();
- From использует домен сайта, а не случайный адрес;
- Return-Path не конфликтует с доменной аутентификацией;
- SMTP-плагин WordPress или интернет-магазина настроен правильно;
- Текст письма не похож на спам;
- Частота отправки не выглядит подозрительно.
Симптомы тоже важно разделять. Если письма не доходят вообще, нужно смотреть SMTP, порты, логи и очередь отправки. Если письма доходят, но попадают в spam, или возвращаются с отбивкой, чаще виноваты SPF, DKIM, DMARC, PTR, репутация IP, содержание письма или заголовки. Если проблема есть только у части получателей, стоит отдельно проверить корректность получателей, а также Gmail, Outlook, корпоративные ящики и blacklist. Если всё сломалось после переноса сайта, нужно проверить новый IP, DNS, SMTP-плагин, From/Return-Path и отправку тестовых писем.
Для WordPress, WooCommerce и других CMS лучше не использовать встроенную отправку через PHP mail(). Надёжнее подключить SMTP-плагин и отправлять письма через авторизованный SMTP: собственный почтовый сервер или внешний SMTP-сервис.
Отдельно стоит быть осторожнее с адресами вида noreply@example.com. Сам по себе noreply не запрещён, но если домен не настроен через SPF, DKIM и DMARC, такие письма могут выглядеть менее доверенно.
После переноса сайта на новый VPS нельзя просто проверить, что страница открывается. Нужно отдельно протестировать письма: регистрация, восстановление пароля, формы заявок, заказы, уведомления WooCommerce, письма администраторам и клиентам.
Главная логика простая: письмо должно не только отправиться, но и выглядеть доверенным для принимающего сервера. Для этого нужны нормальные DNS-записи, корректные заголовки, чистая репутация IP, рабочий SMTP и аккуратная частота отправки.
Диагностика по симптомам
Когда письма с сайта не работают нормально, важно сначала определить симптом. “Письма попадают в спам” и “письма не доходят вообще” — это разные проблемы.
В первом случае отправка может работать, но принимающий сервер не доверяет письму. Во втором письмо может даже не покидать сайт, VPS или SMTP-сервер. Поэтому диагностику лучше начинать не с установки нового плагина, а с вопроса: что именно происходит с письмом после отправки?
Письма не доходят вообще
Если письма не доходят вообще, сначала нужно понять, отправляются ли они с сайта. Иногда проблема находится не в SPF, DKIM или репутации IP, а в самой CMS, SMTP-плагине, форме, очереди писем или сетевых ограничениях.
Для WordPress и WooCommerce стоит проверить:
- Установлен ли SMTP-плагин;
- Правильно ли указаны SMTP-host, порт, логин и пароль;
- Включена ли авторизация;
- Не используется ли PHP mail() вместо SMTP;
- Есть ли ошибки в журнале отправки;
- Не блокирует ли хостинг или VPS исходящие соединения.
Если сайт использует собственный VPS, нужно проверить почтовые логи и очередь отправки. Письмо может быть создано, но зависнуть на сервере из-за ошибки подключения, блокировки порта или отказа принимающей стороны.
Отдельно проверьте исходящий SMTP. Если провайдер блокирует порт 25, собственный почтовый сервер может не отправлять письма напрямую. Для внешнего SMTP обычно используют 587 или 465 порт, и сайт должен подключаться именно к нему.
В этом сценарии SPF, DKIM и DMARC тоже важны, но они не помогут, если письмо физически не уходит с сайта или SMTP-сервера. Сначала нужно добиться стабильной отправки, а уже потом проверять доставляемость.
Когда письмо начало хотя бы доходить до получателя, появляется следующий уровень диагностики: оно попадает во входящие или сразу уходит в спам.
Письма попадают в спам
Если письма приходят, но оказываются в spam, значит отправка технически работает. Проблема чаще всего в доверии к домену, IP-адресу или самому письму.
В первую очередь нужно проверить доменную аутентификацию:
- SPF разрешает реальный сервер отправки;
- DKIM подписывает письма;
- DMARC настроен и не конфликтует с источниками отправки;
- Return-Path не выглядит чужим или случайным;
- From использует домен сайта.
Затем стоит проверить PTR, hostname и репутацию IP. Если сайт отправляет письма с нового VPS без нормальной обратной DNS-записи, крупные почтовые системы могут относиться к таким письмам осторожнее.
Также важно посмотреть заголовки полученного письма. В Gmail это можно сделать через “Показать оригинал”. Там видно, прошли ли SPF, DKIM и DMARC, какой сервер отправил письмо и какой домен использовался в From и Return-Path.
Но техническая настройка — не единственный фактор. Письмо может выглядеть подозрительно по содержанию: слишком много ссылок, сокращатели URL, агрессивные формулировки, вложения, пустой текст, плохая HTML-вёрстка или одинаковые массовые сообщения.
Для интернет-магазина отдельно стоит проверить письма о заказах, оплате, регистрации и восстановлении пароля. Они должны быть понятными, с нормальным отправителем и без лишних “маркетинговых” элементов, если это транзакционные уведомления.
Хорошей идеей будет отправить тестовое письмо, оформленное как реальное, на специальные сервисы, которые проверят корректность всех DNS-записей, подпись и содержание письма.
Если письма попадают в spam не у всех, а только у части получателей, значит проблема может зависеть от конкретной почтовой системы. Тогда нужно смотреть следующий сценарий.
Письма доходят только на часть ящиков
Иногда письма нормально приходят на один ящик, но попадают в spam или не доходят до другого. Например, на корпоративную почту письмо приходит, а на Gmail или Outlook — нет. Или наоборот.
Сначала стоит отмести самый простой вариант - если получатель указан некорректно, или его ящик переполнен, то письмо не дойдёт, а мы получим отбивку (NDR, Non-Delivery Report) с подробным описанием произошедшего. И тут важным моментом будет получать эти NDR - как правило они уходят по обратному адресу (Return-Path) или на адрес отправителя (Mail From).
Если же с получателем всё хорошо, понадобится дополнительное изучение проблемы.
Это нормальная ситуация для диагностики: разные почтовые системы используют разные фильтры, базы репутации и правила проверки.
В таком случае нужно тестировать отправку на несколько типов ящиков:
- Gmail;
- Outlook/Hotmail;
- Yahoo или другой массовый сервис;
- Корпоративная почта;
- Почта на собственном домене;
- Временный тестовый ящик для проверки заголовков.
Если проблема проявляется только у Gmail, стоит внимательно смотреть SPF, DKIM, DMARC, From, Return-Path и репутацию домена. Если письма не доходят до корпоративной почты, причина может быть в более жёстких антиспам-фильтрах, blacklist или политике принимающего сервера.
Также нужно проверить, не отличается ли маршрут отправки. Например, письма из формы обратной связи уходят через SMTP-плагин, а письма WooCommerce — через PHP mail() или другой механизм. В результате часть писем подписывается DKIM, а часть — нет.
Для владельца сайта это важный сигнал: проверять нужно не только “одно тестовое письмо”, а все реальные сценарии отправки. Регистрация, заявка, заказ, смена пароля и уведомление администратору могут уходить разными способами.
Если же проблемы начались сразу после переезда сайта, диагностика обычно начинается с IP, DNS и SMTP-настроек.
Всё сломалось после переноса сайта
После переноса сайта на новый VPS письма часто ломаются не из-за CMS, а из-за смены окружения. Сайт переехал, IP изменился, SMTP-настройки сбросились, DNS-записи остались старыми, а новый сервер ещё не имеет почтовой репутации или она плохая.
После миграции нужно проверить:
- Изменился ли IP отправки;
- Обновлён ли SPF под новый сервер или SMTP-сервис;
- Работает ли DKIM на новом окружении;
- Не изменился ли Return-Path;
- Настроен ли PTR для нового IP;
- Не заблокирован ли исходящий SMTP у нового провайдера;
- Не попал ли новый IP в blacklist;
- Работает ли SMTP-плагин WordPress после переноса.
Частая ошибка — перенести сайт и проверить только главную страницу. Формы, WooCommerce, восстановление пароля и уведомления администратора остаются без тестов. В итоге проблема обнаруживается уже тогда, когда клиент не получил письмо о заказе или пользователь не смог восстановить доступ.
Если до переноса письма отправлялись через внешний SMTP, нужно убедиться, что настройки сохранились: host, порт, логин, пароль, шифрование, From и Return-Path. Если раньше письма уходили с одного IP, а теперь с другого, SPF и репутацию тоже нужно проверить заново.
После миграции лучше отправить тестовые письма на разные почтовые системы и посмотреть заголовки. Так можно сразу увидеть, прошли ли SPF, DKIM и DMARC, какой IP использовался и почему письмо могло попасть в spam.
В итоге диагностика по симптомам помогает не чинить всё подряд. Если письма не уходят — проверяют отправку, SMTP и логи. Если уходят в spam — смотрят аутентификацию, репутацию и содержимое. Если проблема только у части ящиков — сравнивают фильтры и заголовки. Если всё сломалось после переноса — проверяют новый IP, DNS, SMTP и реальные сценарии отправки сайта.
Чек-лист deliverability для сайта
Deliverability — это не просто факт отправки письма. Это вероятность, что письмо дойдёт до получателя и попадёт именно во входящие, а не в spam.
Для сайта, WordPress или интернет-магазина проверку лучше начинать с домена. Принимающий сервер должен понять: письмо действительно отправлено от имени этого домена, а не подделано случайным скриптом.
SPF, DKIM, DMARC
SPF, DKIM и DMARC — базовый набор доменной аутентификации. Без него письма с сайта могут выглядеть подозрительно даже тогда, когда SMTP работает без ошибок.
SPF должен разрешать тот сервер, который реально отправляет письма. Если сайт отправляет письма через внешний SMTP, в SPF должен быть указан этот сервис. Если письма уходят напрямую с VPS, SPF должен разрешать IP этого VPS.
Проверить SPF можно так: dig TXT example.com +short
DKIM должен не просто существовать в DNS. Важно, чтобы письма действительно подписывались. Это проверяется по заголовкам полученного письма: там должен быть результат DKIM-проверки и заголовок DKIM-Signature.
DMARC показывает принимающей стороне, что делать с письмами, которые не прошли SPF или DKIM. На старте лучше использовать мягкую политику p=none, чтобы не сломать легитимные письма с сайта, CRM, WooCommerce или внешнего SMTP.
Проверить DMARC можно так: dig TXT _dmarc.example.com +short
SPF, DKIM и DMARC отвечают за доверие к домену. Но письмо оценивается не только по домену — принимающий сервер смотрит и на IP-адрес отправителя.
PTR, hostname и IP-репутация
PTR-запись связывает IP с доменным именем. Для почтового сервера это обычно что-то вроде: 203.0.113.10 → mail.example.com
Проверить PTR можно так: dig -x 203.0.113.10 +short
Хорошо, когда есть согласованность:
mail.example.com → 203.0.113.10
203.0.113.10 → mail.example.com
Hostname сервера тоже должен быть осмысленным. Если письма уходят с VPS, лучше, чтобы SMTP-сервер представлялся не случайной строкой провайдера, а нормальным именем вроде mail.example.com, совпадающим с PTR.
IP-репутация особенно важна после переноса сайта на новый VPS. Если IP раньше использовался для спама или долго не имел нормальной истории отправки, письма могут хуже доставляться даже при корректных DNS-записях.
Следующий шаг — проверить, не попал ли IP или домен в blacklist.
Blacklist
Blacklist — это списки IP-адресов и доменов, которые замечены в спаме, подозрительной активности или вредоносной отправке. Если IP VPS попал в такой список, письма могут попадать в spam или отклоняться ещё до анализа текста письма.
Проверять blacklist стоит, если:
- Письма резко начали попадать в spam;
- Письма не доходят до части получателей;
- Сайт переехал на новый VPS;
- IP раньше принадлежал другому клиенту;
- В логах есть отказы принимающих серверов;
- Была подозрительная массовая отправка.
Для проверки обычно используют публичные сервисы blacklist lookup. Но важно не ограничиваться только одним сервисом: разные почтовые системы могут ориентироваться на разные базы репутации.
Если IP оказался в blacklist, сначала нужно устранить причину. Нельзя просто отправить заявку на удаление и продолжать рассылать письма так же. Нужно проверить сайт, формы, учётные записи, SMTP-доступы, лимиты отправки, очередь писем и логи.
Даже если IP чистый, само письмо всё равно должно выглядеть корректно. Для этого нужно посмотреть From, Return-Path и технические заголовки.
From, Return-Path и заголовки письма
Принимающий сервер смотрит не только на текст письма, но и на технические заголовки. Для deliverability особенно важны From, Return-Path, DKIM-подпись и результаты SPF/DMARC.
From — это адрес, который видит пользователь. Например: From: Shop <info@example.com>
Return-Path — это адрес для технических возвратов и ошибок доставки. Он может отличаться от From, особенно если используется внешний SMTP-сервис.
Проблемы начинаются, когда From указывает на домен сайта, а Return-Path связан с другим доменом, который не проходит SPF или DMARC alignment. В таком случае письмо может выглядеть менее доверенно.
Проверять заголовки нужно в полученном письме. Можно воспользоваться специальными сервисами, или например в Gmail можно открыть “Показать оригинал” и посмотреть результаты:
SPF: PASS
DKIM: PASS
DMARC: PASS
Если один из пунктов показывает fail или softfail, нужно возвращаться к DNS, SMTP-сервису или настройкам отправителя.
Также важно, чтобы адрес отправителя был на домене сайта. Письмо от интернет-магазина лучше отправлять с orders@example.com, а не со случайного Gmail-адреса или технического адреса сервера.
Для WordPress и WooCommerce отдельная зона риска — способ отправки. Даже правильный From не спасёт, если сайт отправляет письма через ненадёжный механизм.
SMTP-плагин WordPress
WordPress по умолчанию может отправлять письма через PHP mail(). Это работает не всегда стабильно и часто даёт слабую доставляемость, потому что письма могут уходить без нормальной авторизации, DKIM-подписи и понятного SMTP-маршрута.
Для WordPress, WooCommerce и сайтов с формами лучше использовать SMTP-плагин. Он подключает сайт к почтовому серверу или внешнему SMTP-сервису через авторизованное соединение.
В настройках SMTP-плагина нужно проверить:
- SMTP-host;
- Порт 587 или 465;
- Тип шифрования;
- Логин и пароль;
- From Email;
- From Name;
- Return-Path, если настройка доступна;
- Включена ли отправка всех писем через SMTP;
- Есть ли журнал ошибок отправки.
После настройки нужно отправить тестовое письмо из плагина. Но одного теста мало: нужно проверить реальные письма сайта — форму заявки, регистрацию, восстановление пароля, заказ WooCommerce, уведомление администратору и письмо клиенту.
Если часть писем уходит через SMTP, а часть через PHP mail(), результаты могут быть разными. Одни письма будут проходить SPF/DKIM, а другие попадать в spam.
Когда техническая отправка настроена, остаётся проверить само письмо: его текст, ссылки, вложения и частоту отправки.
Текст письма и частота отправки
Даже идеально настроенные SPF, DKIM, DMARC и SMTP не гарантируют inbox, если само письмо похоже на спам.
Почтовые системы оценивают содержание письма: тему, текст, ссылки, вложения, HTML-вёрстку, изображения, повторяемость сообщений и жалобы пользователей.
Письмо может попасть в spam, если в нём:
- Слишком много ссылок;
- Используются сокращатели URL;
- Есть подозрительные вложения;
- Тема выглядит как агрессивная реклама;
- Текст состоит почти только из картинки;
- Нет понятного отправителя;
- HTML сломан или выглядит как шаблон массовой рассылки;
- Письмо отправляется слишком часто;
- Отсутствие ссылки на отписку;
- Пользователи жалуются или не открывают сообщения.
Для интернет-магазина транзакционные письма лучше делать простыми: заказ, статус, сумма, контакты, ссылка на сайт. Не стоит перегружать письмо восстановления пароля рекламой, баннерами и большим количеством внешних ссылок.
Частота отправки тоже важна. Если новый сайт или новый IP резко начинает отправлять сотни писем, это может выглядеть подозрительно. Лучше наращивать объём постепенно и следить за bounce, жалобами и попаданием в spam.
В итоге чек-лист deliverability работает только как единая цепочка: домен должен проходить SPF, DKIM и DMARC, сервер должен иметь нормальный PTR и репутацию, письмо должно уходить через корректный SMTP, а содержание и частота отправки не должны напоминать спам.
Что делать, если проблема не исчезает
Если SPF, DKIM, DMARC, PTR, blacklist, SMTP-плагин и заголовки проверены, но письма всё равно попадают в spam, нужно переходить от общей диагностики к точечной.
Сначала соберите несколько реальных примеров писем. Не одно тестовое письмо из плагина, а именно те письма, которые важны для сайта: заявка, регистрация, восстановление пароля, заказ, уведомление администратору и письмо клиенту.
Для каждого письма нужно посмотреть:
- Куда оно отправлялось;
- Попало ли оно во входящие или в spam;
- Прошли ли SPF, DKIM и DMARC;
- Какой From и Return-Path использовались;
- Какой IP отправлял письмо;
- Есть ли ошибки в заголовках;
- Отличается ли маршрут отправки от других писем сайта.
Если проблема есть только у одного типа писем, например у WooCommerce-заказов, значит нужно смотреть не всю почту сайта, а конкретный сценарий: шаблон письма, плагин, From, вложения, ссылки и способ отправки.
Если проблема есть только у Gmail, Outlook или корпоративной почты, нужно сравнить заголовки в разных системах. Разные почтовые сервисы могут по-разному оценивать один и тот же домен, IP и текст письма.
Если сайт использует собственный VPS для отправки, а письма важны для бизнеса, стоит рассмотреть внешний SMTP-сервис. Это особенно актуально для интернет-магазинов, личных кабинетов, SaaS-проектов и сайтов, где письма восстановления пароля или уведомления о заказах нельзя терять.
Внешний SMTP не отменяет SPF, DKIM и DMARC. Но он упрощает доставку, даёт понятные логи, снижает зависимость от репутации нового VPS и помогает быстрее понять, где именно ломается отправка.
Также стоит разделить транзакционные письма и массовые рассылки. Восстановление пароля, заказ и уведомление клиента не должны уходить тем же способом, что и маркетинговая рассылка по старой базе. Если рассылка получит жалобы, это может ухудшить доставку важных писем.
Если проблема появилась после миграции, отката DNS или смены SMTP, не стоит сразу менять всё подряд. Лучше зафиксировать текущую схему, проверить один сценарий, исправить его, затем перейти к следующему.
Рабочая логика такая:
- Проверить техническую отправку.
- Проверить DNS и доменную аутентификацию.
- Проверить IP, PTR и blacklist.
- Посмотреть заголовки реального письма.
- Сравнить разные почтовые системы.
- Проверить текст и частоту отправки.
- При необходимости перейти на внешний SMTP.
Если после этого письма всё равно стабильно попадают в spam, проблема может быть в репутации домена, истории IP, жалобах пользователей или качестве базы получателей. В таком случае быстрых исправлений может не быть: нужно постепенно восстанавливать доверие, снижать жалобы, чистить базу и отправлять только ожидаемые письма.
Заключение
Письма с сайта попадают в спам не из-за одной универсальной причины. Обычно проблема возникает на стыке нескольких факторов: DNS-записей, SMTP-настроек, репутации IP, заголовков письма, способа отправки в CMS и самого содержания письма.
Для владельца сайта важно не просто “проверить почту”, а разобрать весь путь письма: от формы, WordPress или интернет-магазина до принимающего сервера Gmail, Outlook или корпоративной почты.
Если письма не доходят вообще, нужно смотреть SMTP, порты, логи, очередь и настройки отправки. Если письма попадают в spam, важнее SPF, DKIM, DMARC, PTR, blacklist, From, Return-Path, IP-репутация и текст письма. Если всё сломалось после переноса сайта, первым делом стоит проверить новый IP, DNS, SMTP-плагин и реальные сценарии отправки.
Для WordPress и WooCommerce лучше не полагаться на PHP mail(). Надёжнее использовать SMTP-плагин и отправлять письма через авторизованный SMTP: внешний сервис или корректно настроенный почтовый сервер.
Для интернет-магазина, SaaS-проекта или сайта с личным кабинетом доставляемость писем — это не второстепенная настройка. От неё зависят регистрации, заказы, восстановление пароля, уведомления клиентам и работа поддержки.
Правильный подход — настроить доменную аутентификацию, проверить репутацию IP, посмотреть заголовки реальных писем, протестировать разные почтовые системы и не забывать повторять проверку после миграций, смены IP, обновления SMTP-плагина или переноса сайта на новый VPS.
FAQ
Почему письма WordPress попадают в спам?
Чаще всего письма WordPress попадают в spam из-за слабой или неправильной настройки отправки. Сайт может использовать PHP mail(), отправлять письма без авторизованного SMTP, не подписывать их DKIM или использовать From, который не совпадает с доменной аутентификацией.
Также влияют SPF, DMARC, PTR, репутация IP и содержание письма. Если WordPress отправляет письма с домена сайта, принимающая сторона должна видеть, что этот домен действительно разрешил такую отправку.
Для WordPress лучше использовать SMTP-плагин и отправлять письма через внешний SMTP-сервис или корректно настроенный почтовый сервер. После настройки нужно проверить не только тестовое письмо из плагина, но и реальные сценарии: формы, регистрацию, восстановление пароля, WooCommerce-заказы и уведомления администраторам.
Почему письма с сайта не доходят вообще?
Если письма не доходят вообще, проблема может быть не в spam-фильтре, а в самой отправке. Письмо может не покидать сайт, зависать в очереди, блокироваться на уровне VPS или не проходить подключение к SMTP-серверу.
Сначала нужно проверить SMTP-настройки: host, порт, логин, пароль, шифрование и авторизацию. Затем — логи сайта, SMTP-плагина и почтового сервера.
Если используется собственный VPS, проверьте, не заблокирован ли исходящий SMTP. Некоторые провайдеры ограничивают исходящий порт 25. Для отправки через внешний SMTP обычно используют порты 587 или 465.
Что лучше: PHP mail или SMTP-плагин?
Для сайта лучше использовать SMTP-плагин. PHP mail() может работать, но часто даёт слабую доставляемость: письма уходят без нормальной авторизации, прозрачного маршрута, логов и корректной подписи.
SMTP-плагин подключает WordPress или интернет-магазин к конкретному почтовому серверу или внешнему SMTP-сервису. Это упрощает диагностику и повышает предсказуемость доставки.
Плагин сам по себе не гарантирует inbox. Нужно всё равно настроить SPF, DKIM, DMARC, From, Return-Path и проверить реальные письма сайта.
Как проверить SPF, DKIM и DMARC?
SPF и DMARC можно проверить через DNS-записи домена:
dig TXT example.com +short
dig TXT _dmarc.example.com +short
DKIM проверяется по селектору. Например, если селектор называется default, команда может выглядеть так: dig TXT default._domainkey.example.com +short
Но DNS-записей недостаточно. Нужно открыть заголовки реального полученного письма и посмотреть, прошли ли SPF, DKIM и DMARC. В Gmail это можно сделать через “Показать оригинал”. Или можно воспользоваться специальными сервисами, которые покажут проблемы, заголовки и дадут рекомендации по настройке.
Cloudflare описывает SPF, DKIM и DMARC как три метода email-аутентификации, которые вместе помогают подтвердить отправителя и защитить домен от подделки.
Что такое Return-Path и почему он важен?
Return-Path — это технический адрес, на который возвращаются ошибки доставки. Пользователь обычно видит From, а Return-Path используется почтовыми системами для bounce-сообщений и проверки маршрута отправки.
Например, пользователь может видеть:
From: Shop <orders@example.com>
А технический возврат может идти на адрес внешнего SMTP-сервиса.
Само по себе это нормально. Проблемы начинаются, если Return-Path, From, SPF и DMARC конфликтуют между собой. Тогда принимающий сервер может хуже доверять письму.
Поэтому после настройки SMTP важно проверять не только адрес отправителя в интерфейсе письма, но и технические заголовки.
Нужно ли прогревать новый IP для отправки писем?
Да, если сайт отправляет письма напрямую с нового VPS или выделенного IP. Новый IP без истории может выглядеть подозрительно, особенно если сразу начать отправлять большой объём писем.
Прогрев означает постепенное наращивание объёма отправки и контроль реакции получателей: bounce, жалобы, попадание в spam, открываемость и отписки.
Для небольшого сайта с редкими транзакционными письмами это менее заметно. Но для интернет-магазина, рассылок, SaaS-проекта или личного кабинета резкая смена IP может повлиять на доставляемость.
Если нет желания заниматься репутацией IP вручную, проще использовать внешний SMTP-сервис.
Когда лучше перейти на внешний SMTP-сервис?
На внешний SMTP-сервис стоит перейти, если письма важны для бизнеса и их нельзя терять: заказы, заявки, регистрация, восстановление пароля, чеки, уведомления клиентам и сообщения поддержки.
Внешний SMTP особенно полезен, если:
- VPS новый и без почтовой репутации;
- Провайдер блокирует исходящий SMTP;
- IP попал в blacklist;
- Письма WordPress часто попадают в spam;
- Нет времени администрировать почтовый сервер;
- Нужны логи, статистика, bounce-обработка и понятная диагностика.
Gmail в рекомендациях для отправителей подчёркивает важность аутентификации писем через SPF или DKIM, а для DMARC — совпадение домена в заголовке From с доменом, прошедшим SPF или DKIM.
Внешний SMTP не отменяет настройку домена. SPF, DKIM и DMARC всё равно нужны, но обычно сервис даёт понятные инструкции и готовые DNS-записи.
Список источников
1. Gmail Help — Email sender guidelines
