SavePearlHarbor

Своя почта против Gmail

—

от автора

admin

Ответы на комментарии к статье «Как мы с внуком подняли свой сервер вместо Gmail в деревне»

Своя почта против Gmail: ответы на вопросы из комментариев

Во второй части разбираю практические вопросы к «деревенскому» почтовому серверу: от «SMTP нонейма» и спама до 25‑го порта, динамических IP и смысла собственного сервера для обычного пользователя.

В первой статье я описал, как для семьи завёл почту на своём домене и VPS‑сервере вместо привычного Gmail, используя образ «деда из деревни» и его внука для объяснения базовых вещей простым языком. В комментариях закономерно появилась масса уточнений и возражений — от «гугл вообще не примет письмо с SMTP нонейма» до споров о том, где сегодня живёт «адекватный» бизнес: на своих серверах или у крупных почтовых провайдеров.

В этом тексте я отвечаю на самые частые вопросы из той ветки и сознательно убираю художественную часть: ниже в основном практика, с опорой на конфигурацию моего небольшого сервера и типовые сценарии. Цель — не доказать, что «свой сервер лучше Gmail», а честно показать, что происходит с письмами от маленького домена, какие ограничения есть у «самодельной» почты и в каких случаях такой подход вообще имеет смысл.

1. Что происходит с письмом от «SMTP нонейма»

Принимают ли его вообще и почему оно часто оказывается в спаме

В комментариях прозвучали полярные оценки поведения крупных почтовых сервисов: одни уверены, что «они просто не примут письмо с нонейм‑SMTP», другие приводят примеры, когда письма принимаются даже без PTR‑записи, но стабильно попадают в спам. На практике возможны оба сценария: часть провайдеров режет соединение ещё на уровне SMTP, другие письмо принимают, но сразу помечают как подозрительное и отправляют в папку «Спам».

На то, будет ли письмо вообще принято и где оно окажется, влияет несколько факторов:

  • MX‑ и A‑записи домена;

  • наличие и корректность SPF, DKIM, DMARC;

  • обратная PTR‑запись (reverse DNS);

  • репутация IP‑адреса и домена;

  • поведение отправителя (объёмы, содержимое, жалобы пользователей).

В моём случае стартовая конфигурация с базовым набором DNS‑записей приводила к тому, что тестовые письма до крупных сервисов доходили, но нередко оказывались в спаме. После включения DKIM, добавления DMARC и аккуратной отправки небольших, «не спам» писем они начали чаще попадать во «Входящие», что типично для малых доменов без массовых рассылок.

2. Свой сервер против крупного провайдера: где это вообще оправдано

В обсуждении столкнулись две крайности:

  • «Почти весь бизнес уже у крупных почтовых провайдеров».

  • «Весь адекватный бизнес уходит на свои сервера, чтобы не ловить утечки».

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

Крупные сервисы дают:

  • готовую инфраструктуру и SLA;

  • фильтрацию спама и антивирус;

  • регулярные обновления и мониторинг.

Но взамен требуют:

  • доверить им хранение и обработку переписки;

  • работать по их правилам (политика спама, лимиты, формальные требования к отправителю).

Собственный сервер, наоборот, даёт максимум контроля, но:

  • ответственность за отказоустойчивость, бэкапы и безопасность ложится на администратора;

  • нужно заниматься репутацией IP‑адреса;

  • важны своевременные обновления и закрытие уязвимостей (почта — популярная цель атак).

В моём проекте мотивация была не «увести корпоративную почту из облака», а отработать реальный сценарий небольшой семейной почты и получить живой стенд: посмотреть, как маленький доменный сервер ведёт себя в мире крупных провайдеров, какие проверки проходит и где начинаются ограничения. Для большинства малых компаний и частных пользователей задача «просто рабочий почтовый ящик» действительно дешевле и спокойнее решается через готовый почтовый хостинг или облачный сервис. Свой сервер имеет смысл там, где есть повышенные требования к контролю за данными или ресурсы и интерес поддерживать эту инфраструктуру собственными силами.

3. Домашний сервер, 25‑й порт и динамический IP: что реально мешает

Отдельная линия обсуждения касалась вопроса: почему я не повесил почтовый сервер прямо дома и почему считаю это рискованным с точки зрения доставки. Классические проблемы домашнего сервера:

  • исходящий трафик на порт 25 часто блокируется провайдерами;

  • выдаются динамические IP‑адреса, которые по умолчанию считаются недоверенными;

  • часть принимающих серверов отклоняет письма из известных динамических диапазонов или без PTR‑записи.

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

На примере Postfix логика примерно такая:

  • queue_run_delay — как часто обрабатывается отложенная очередь;

  • minimal_backoff_time — минимальная пауза перед повторной попыткой;

  • maximal_backoff_time — максимальная пауза между попытками;

  • maximal_queue_lifetime — сколько письмо живёт в очереди, прежде чем вернуться отправителю.

То есть кратковременное отключение интернета или света — не гарантированная потеря писем. Но чем менее предсказуемы электричество и связь, тем больше риск того, что в какой‑то момент окно повторных попыток не совпадёт с «живым» состоянием сервера.

Разница между домашним сервером и VPS в моём случае в том, что для VPS стабильность питания, канала и статического IP — норма, а для деревенского дома с периодическими отключениями электричества и мобильного интернета это уже не гарантируется. Поэтому выбранная схема:

  • основной сервер на VPS — туда приходит и оттуда отправляется внешняя почта;

  • домашняя машина — лаборатория, бэкапы и эксперименты, которые не ломают внешний контур.

4. Почему облака блокируют 25‑й порт и что с этим делать

В комментариях был пример: «пойдите расскажите про “платим за открытый порт” крупным облачным провайдерам — там 25‑й закрыт без разговоров». Такая политика действительно типична: исходящий трафик на 25‑й порт по умолчанию блокируется для виртуальных машин и похожих сервисов, чтобы:

  • не допустить массовый спам из облака;

  • не портить репутацию их IP‑пулов в глазах других почтовых систем.

Типовые сценарии работы с почтой в таком облаке выглядят так:

  • использование внешних почтовых провайдеров — сервер в облаке подключается к ним по 587/2525, а не по 25;

  • использование собственного сервера только как клиента (SMTP‑relay наружу, а не полноценный MTA для всего мира);

  • подача заявки в поддержку на снятие ограничения с 25‑го порта с описанием сценария и готовностью выполнять их требования.

Для небольшого «самостоятельного» отправителя, который хочет полный контроль над SMTP с нуля, эта модель бывает неудобна: проще взять VPS‑хостинг, где 25‑й порт открывается по договорённости, а не по исключению.

5. Почему не почтовый хостинг с доменом

Логичный вопрос: если основная почта всё равно живёт на VPS в дата‑центре, почему не взять готовый почтовый хостинг, привязать к нему домен и не заниматься тонкой настройкой сервера вообще.

Почтовый хостинг обычно даёт:

  • готовый веб‑интерфейс и IMAP/SMTP;

  • антиспам и антивирус «из коробки»;

  • регулярные обновления, мониторинг и бэкапы;

  • работу с репутацией IP на своей стороне.

И оставляет администратору только:

  • управление доменом (A/MX/…);

  • создание ящиков и общие политики.

В рамках этого проекта задача другая: использовать живой домен и сервер как учебную площадку, на которой можно руками пройти все шаги — от A/MX‑записей до DKIM/DMARC, посмотреть, как меняется отношение крупных провайдеров к письмам от домена по мере улучшения конфигурации, и показать этот путь читателям. Почтовый хостинг отлично решает задачу «просто работать и не думать», но почти полностью прячет технические детали; здесь же важно было именно столкнуться с ними — от первых писем в спаме до более‑менее предсказуемых «Входящих» — и понимать, за счёт чего происходят эти изменения.

6. Мини‑FAQ по репликам из комментариев

«MX не обязателен, если есть A‑запись»

Стандарт допускает сценарий, когда у домена нет MX‑записей, и тогда отправляющий сервер может попытаться доставить почту на A‑запись домена, рассматривая её как почтовый хост. Но на практике корректно настроенный MX считают базовым элементом почтовой инфраструктуры:

  • MX явно указывает серверы, отвечающие за приём почты;

  • через MX можно задать приоритеты и резервные хосты;

  • корректный MX снижает риск странных маршрутов и неоднозначной трактовки.

Для небольшого домена с одним сервером прописать MX несложно, и логично считать это нормой, а не опцией «по желанию».

«Платит за DKIM» и откуда берётся такой образ

Ремарка про «предприятие платит за DKIM» отражает реальность старых стеков, где поддержка современных технологий могла требовать платных модулей или обновлений (как у некоторых устаревших версий корпоративных серверов). Если разложить по слоям:

  • DKIM как стандарт — открытый протокол, спецификация доступна всем;

  • современный open‑source‑стек (Postfix, Dovecot и т.п.) реализует DKIM через свободные компоненты и TXT‑записи в DNS;

  • «платим за DKIM» в реальности означает: платим за обновление/поддержку устаревшей платформы, а не за право использовать сам протокол.

То есть проблема не в DKIM как таковом, а в том, что кто‑то до сих пор живёт на очень старом ПО, где любая новая возможность стоит денег.

Exchange 2003 в 2026 году

Вопрос «кто в здравом уме в 2026 использует Exchange 2003» возникает не на пустом месте: официальная поддержка таких версий давно завершена, а эксплуатация их как фронтовых почтовых серверов создаёт повышенные риски из‑за накопленных уязвимостей. Почтовые серверы — лакомая цель для атак, поэтому старые, не обновляемые системы оказываются особенно уязвимыми.

Если подобные системы всё ещё используются, разумные пути:

  • плановая миграция на более современные решения;

  • вынос внешнего контура (приём/отправка из интернета) на отдельные, актуальные узлы, чтобы старый сервер не торчал напрямую в сеть.

«Онлайн‑сервисы проверки почтового сервера» и DNSBL: насколько они реально помогают

Онлайн‑сервисы проверки почтового сервера полезны как быстрый диагностический инструмент. Они показывают:

  • есть ли ошибки в SPF/DKIM/DMARC;

  • корректны ли MX‑записи;

  • нет ли проблем с TLS/сертификатами;

  • числится ли IP в популярных DNSBL‑списках.

Но важно понимать их границы:

  • сервис только указывает на проблему;

  • администратор решает её, меняя конфигурацию и поведение сервера;

  • «выписка» из чёрных списков — отдельный процесс, который может занимать время и не всегда успешен.

Для небольшого семейного сервера такие сервисы — полезный индикатор, но основу репутации всё равно составляют:

  • отсутствие спама и сомнительных рассылок;

  • умеренные объёмы отправки;

  • корректные DNS‑записи и аккуратная конфигурация сервера.

7. Технический блок: конфигурация в разрезе

VPS и базовое ПО

  • Платформа: VPS.

  • Ресурсы:

    • 1–2 vCPU;

    • 2–4 ГБ RAM;

    • 40–60 ГБ SSD.

  • ОС: Linux на базе Debian.

  • Почтовое ПО: готовый «комбайн», который включает:

    • MTA (на базе Postfix или аналогичного);

    • IMAP/POP3‑сервер (типичный вариант — Dovecot);

    • веб‑интерфейс для пользователя и администрирования;

    • антиспам/антивирусные модули.

Упрощённо поток выглядит так:

textИнтернет → MX-сервер на VPS → почтовые ящики домена                           → IMAP/SMTP → почтовые клиенты и веб-интерфейс

Интернет → MX-сервер на VPS → почтовые ящики домена → IMAP/SMTP → почтовые клиенты и веб-интерфейс

DNS‑записи домена

Минимальный набор настроек:

  • A — указывает на IP‑адрес VPS;

  • MX — говорит, на какой хост доставлять почту для домена;

  • SPF (TXT) — перечисляет источники, с которых разрешено отправлять почту от имени домена;

  • DKIM (TXT) — публикует открытый ключ для проверки подписи исходящих писем;

  • DMARC (TXT) — задаёт политику обработки «подозрительных» писем и адрес для отчётов.

Логика прохождения письма:

textОтправка письма →  принимающий сервер смотрит MX →    проверяет SPF / DKIM →      применяет политику DMARC →        принимает / помечает / отклоняет.

Отправка письма → принимающий сервер смотрит MX → проверяет SPF / DKIM → применяет политику DMARC → принимает / помечает / отклоняет.

Пример минимального набора (схематично, без реальных имён):

textexample.ru.      IN A    203.0.113.10example.ru.      IN MX 10 mail.example.ru.example.ru.      IN TXT "v=spf1 mx -all"default._domainkey.example.ru. IN TXT "v=DKIM1; k=rsa; p=ПУБЛИЧНЫЙ_КЛЮЧ"_dmarc.example.ru. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.ru"

example.ru. IN A 203.0.113.10 example.ru. IN MX 10 mail.example.ru. example.ru. IN TXT "v=spf1 mx -all" default._domainkey.example.ru. IN TXT "v=DKIM1; k=rsa; p=ПУБЛИЧНЫЙ_КЛЮЧ" _dmarc.example.ru. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.ru"

Очереди доставки и устойчивость

На стороне MTA (например, Postfix) важны параметры, влияющие на устойчивость к сбоям:

  • queue_run_delay — период обработки отложенной очереди писем;

  • minimal_backoff_time — минимальная пауза до следующей попытки доставки;

  • maximal_backoff_time — максимальная пауза между повторными попытками;

  • maximal_queue_lifetime — максимальное время жизни письма в очереди до возврата отправителю.

Именно это позволяет серверу не «ронять» письма при кратковременных сбоях связи, а аккуратно пытаться доставить их позднее.

ссылка на оригинал статьи https://habr.com/ru/articles/1027950/