На FirstVDS вы настроили PTR, но письма собственного сервера продолжают попадать в Спам. Это не означает, что обратная запись не нужна или что следует менять её при каждой жалобе. Сначала проверьте, к какому IP относится запись и с какого адреса действительно ушла исследуемая копия.
PTR описывает связь адреса сервера с именем. Он не подтверждает автоматически видимый From, подпись письма или отношение получателя к содержимому. Для полезной диагностики нужно разделить сетевую идентичность сервера, аутентификацию домена и наблюдаемую папку.
Установите реальный исходящий IP
У VDS могут быть несколько адресов, IPv6 и внешний relay. Если приложение подключается к стороннему SMTP, получатель может видеть почтовый IP этого сервиса, а не вашего VDS. Изменение PTR веб-сервера тогда не описывает конечный исходящий маршрут.
Для прямой отправки сопоставьте журнал MTA и доступные заголовки полученной копии. Не выбирайте любой адрес из Received: промежуточных узлов может быть несколько. Если источник IP не установлен надёжно, обозначьте неопределённость и уточните маршрут до правки обратной зоны.
Проверьте обе стороны DNS-связи
FirstVDS описывает проверку PTR при проблемах почты и управление обратной записью через настройки IP в кабинете. После изменения проверьте, что адрес разрешается в нужное имя, а A или AAAA этого имени возвращает тот же адрес. Одной непустой PTR недостаточно для проверки согласованности.
Имя может выглядеть как mail.example.org и обслуживать несколько почтовых доменов. Оно не обязано совпадать с каждым From. Важна корректная связь сервера, а не попытка назначить один IP именем каждого клиента. Прямую запись публикуют у DNS-провайдера домена, обратную — через владельца IP.
Не добавляйте PTR в обычную зону домена
Таблица DNS домена и обратная зона адреса — разные области управления. Если панель позволяет создать запись типа PTR среди обычных записей, это ещё не изменяет публичное обратное разрешение IP. Используйте механизм, предусмотренный провайдером адреса.
Сохраните время изменения и результаты запросов. Из-за кэша разные ответы могут временно расходиться. Не назначайте точную минуту, когда все принимающие системы обязаны увидеть новое значение. Для следующей проверки используйте новую отправку после подтверждения опубликованной конфигурации.
Учитывайте IPv6 и имя SMTP-сервера
Если часть сообщений уходит по IPv6, проверьте соответствующую обратную запись и прямую AAAA. Настройка IPv4 не исправляет автоматически другой путь. Не отключайте семейство адресов только ради случайного удачного теста без понимания рабочей схемы и последствий.
HELO или EHLO — имя, которое представляет SMTP-сервер. Его настройка связана с идентичностью сервера, но не заменяет результат PTR. Проверяйте доступные сведения отдельно. Если в отчёте нет данных о HELO, нельзя считать его соответствие подтверждённым по одной обратной записи.
После PTR проверьте аутентификацию письма
В новой копии найдите технический домен возвратов, DKIM d= и s=, видимый From. SPF, DKIM и DMARC решают другие задачи, чем обратное разрешение IP. Успешный PTR не компенсирует ошибку подписи и не доказывает право отправлять от выбранного домена.
Если сообщение отклонено, сохраните полный ответ сервера. Он может указывать конкретный дефект, но общий текст о спаме ещё не раскрывает все правила фильтра. Если копия принята и лежит в Спаме, это другой результат: сервер доставки работает, а размещение требует отдельного исследования.
Проведите контрольное сравнение
Отправьте рабочий шаблон через свой MTA на адреса проверки Check. Зафиксируйте источник IP, результат PTR и папки доступных копий. Если вы исправляете обратный DNS, сохраняйте содержимое и From, чтобы не смешивать опыт с изменением письма.
При успешных технических проверках и Спаме используйте дальнейший разбор аутентифицированного письма. Следующая гипотеза должна быть отдельной. Не объявляйте IP «плохим» только по одной папке и не обещайте, что его замена гарантирует успех.
Методология Check определяет PTR через связку IP и имени и сохраняет ограничения источника. Наблюдение контрольного ящика относится к конкретному времени. Сохраните оба результата — исправленную техническую конфигурацию и фактическую папку — даже если ожидание Входящих не оправдалось.
В документации сервера оставьте владельца IP, способ настройки PTR и используемые адреса обоих семейств. При замене VDS это позволит восстановить почтовую идентичность осознанно, а не переносить старую обратную запись на новый маршрут по привычке.
Видео-памятка: что проверить
Видео без звука, 24 секунды. Текстовая версия краткого плана:
- PTR управляется через владельца IP, а не обычную DNS-зону.
- Проверяйте IP → имя → тот же IP.
- Корректный PTR не гарантирует папку Входящие.