Собственный почтовый сервер отличается от готового ящика на домене. Вы отвечаете за службу приема, отправку клиентом, хранение, доступ, обновления и восстановление. До аренды определите, какие части выполняет ваша команда, а какие остаются у внешнего почтового сервиса.
Прием, submission и хранение - разные задачи
RFC 6409 разделяет submission от межсерверного relay. Для передачи между почтовыми серверами используется SMTP на порту 25, submission обычно работает на 587. У этих служб разные правила авторизации и обработки.
Поэтому успешное подключение клиента к 587 не доказывает возможность приема и прямой отправки через 25. Уточните входящие и исходящие ограничения конкретного VPS до оплаты. В нашем реестре разрешение SMTP не присвоено тарифам по одному наличию root.
| Часть системы | Что подтвердить |
|---|---|
| Межсерверный SMTP | Входящий и исходящий доступ, правила провайдера |
| Submission | Авторизацию клиента и обязательную защиту канала |
| Ящики | Протокол доступа, квоты и сохранность писем |
| DNS отправителя | Управление именем и обратной записью IP |
| Восстановление | Письма, настройки, ключи и доступ к архивам |
Если нужен только готовый ящик, сравните почтовый хостинг. Если задача - отправка уведомлений приложения, не считайте ее автоматически задачей обслуживания всех ящиков. Выбор VPS и выбор внешнего релея тоже требуют разных условий.
465 и 587: важен режим TLS
RFC 8314 описывает submission с implicit TLS на 465: защищенное соединение начинается сразу. Для 587 рассматривается STARTTLS. При корректной реализации и обязательном успешном TLS до submission документ не видит существенной разницы свойств безопасности этих вариантов.
Проверяйте сочетание имени сервера, порта, режима и доверия к сертификату, а не только надпись SSL в панели. Неверный режим клиента не исправляется отключением проверки сертификата. Submission с аутентификацией не универсальное разрешение пересылать письма кому угодно без входа.
Получите согласованную схему доступа и восстановления до ограничений сети. Пароли, ключи и содержимое писем не включайте в публичные отчеты. В этой работе порты, firewall, сертификаты и учетные записи не менялись.
PTR и требования Gmail относятся к отправке
На 6 октября 2026 года правила Gmail для отправителей относятся к личным адресам Gmail. Для всех отправителей указаны SPF или DKIM, корректные прямые и обратные DNS-записи и TLS. PTR должен возвращать имя, которое своей A или AAAA-записью указывает на тот же отправляющий IP.
В отдельной группе массовых отправителей нужны SPF и DKIM, DMARC и согласование домена From с SPF либо DKIM. Для маркетинговых и подписных сообщений предусмотрена простая отписка, включая one-click. Это требования конкретного получателя, не универсальная настройка для всех почтовых систем.
Не выдавайте наличие DNS-записей за гарантию попадания во входящие. Google также учитывает репутацию и жалобы; соседние отправители на общем IP влияют на общую репутацию. Ни репутация, ни доставляемость наших тарифов не измерены.
До заказа выясните, кто управляет PTR и именем, какой адрес реально будет использоваться для отправки и какие ограничения действуют. Факт выделенного IP сам по себе не ответ на эти вопросы.
Релей должен проверяться отдельно от обычного входа
Согласуйте, каким пользователям разрешена отправка и какие домены обслуживаются. Не превращайте ошибку авторизации в открытый релей. Для приемки нужна проверка отказа неавторизованному клиенту, а не только успешный вход администратора.
Проверку выполняет ответственный специалист в согласованной среде и без рассылки посторонним. Здесь письма не отправлялись, адреса получателей не собирались, аккаунты не создавались. Журнал должен показывать фактическую причину отказа, не только сообщение интерфейса.
Настройки DNS, TLS и авторизации рассматривайте вместе, сохраняя возможность отката. Кнопка почтового модуля Webmin не подтверждает готовую безопасную конфигурацию или включенное администрирование.
Backup ящиков не только файл конфигурации
Составьте опись писем и папок, учетных данных, конфигурации служб и необходимых ключей. Уточните, какие данные сохраняет выбранный инструмент и где находится завершенная копия. Архив настроек без писем не возвращает содержимое ящика.
На изолированной копии проверьте возврат контрольного сообщения, вложения и нужной папки. Рабочие ящики и изображения не удаляйте ради демонстрации. Восстановление должно учитывать права файлов и соответствующую версию службы, а не просто распаковку неизвестного архива.
Общий порядок независимого хранения есть на странице backup. Для технического доступа смотрите SSH. Эти руководства не заменяют паспорт почтового продукта.
Для IPv6-only VPS входящие соединения, исходящая передача и доступ клиента проверяются раздельно. Работа веб-прокси не подтверждает почтовую сеть.
Что получить от поставщика до оплаты
Запросите сетевые условия 25 и submission, адрес и PTR, ответственность за TLS и обновления, квоты ящиков, ограничения отправки и восстановление. Любое неизвестное условие оставьте вопросом. Не подставляйте лимиты писем или цену внешнего релея из другого предложения.
Проверенной тарифной матрицы почтовых VPS пока нет. Каталог VPS сравнивает ресурсы, но возможность SMTP, администрирование и условия использования почты нужно подтвердить отдельно. Эта страница не тест доставляемости и не обещание отсутствия спама.

Вывод относится к сценарию этой страницы и не заменяет проверку конкретного тарифа.