Почтовые сервера mail: что это такое и как они работают

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

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

Архитектура почтового сервера: четыре роли на пути письма

Каждое письмо — от первого клика «Отправить» в вашем Outlook до момента, когда коллега открывает его в Gmail, — проходит через несколько программных ролей. Их принято описывать через модель Internet Mail Architecture: пользовательский клиент, узел отправки, транспортные агенты и компонент, который помещает письмо в конкретный ящик.

• MUA (Mail User Agent) — клиентское приложение, через которое человек пишет и читает письма: Outlook, Thunderbird, Apple Mail, веб-интерфейс Яндекс Почты или другой сервис. MUA отвечает за пользовательский интерфейс и обмен с сервером, но сам по себе не является полноценным маршрутизатором почты.
• MSA (Mail Submission Agent) — принимает письмо от пользовательского клиента. На этом этапе сервер проверяет учётные данные, применяет ограничения отправки, добавляет служебные заголовки и передаёт сообщение дальше. В некоторых конфигурациях здесь же или рядом выполняется DKIM-подпись.
• MTA (Mail Transfer Agent) — транспортный агент, который передаёт письмо между почтовыми серверами по SMTP. Он определяет, куда направить сообщение, обращается к DNS, находит MX-записи домена получателя и повторяет попытку доставки, если удалённый сервер временно недоступен. Postfix, Exim, Sendmail и Microsoft Exchange — примеры программ, которые могут выполнять роль MTA.
• MDA (Mail Delivery Agent) — принимает сообщение от транспортного агента и помещает его в почтовый ящик конкретного пользователя. В такой роли могут работать Dovecot, Courier, Procmail и другие компоненты, в зависимости от архитектуры сервера.

Почтовый сервер не обязательно представляет собой одну программу. В небольших готовых решениях несколько ролей скрыты внутри единой платформы. В собственной инфраструктуре их, напротив, часто разделяют: Postfix отвечает за SMTP, Dovecot — за доступ к ящикам по IMAP, отдельные фильтры — за спам и вредоносные вложения, а DNS и система мониторинга обеспечивают внешнюю связность и контроль.

Воронка выглядит так: MUA пишет → MSA принимает → MTA передаёт → удалённый MTA принимает → MDA сохраняет → MUA читает. На каждом переходе письмо можно задержать, отклонить или отправить на дополнительную проверку.

Зачем маркетологу эта схема? Потому что проблемы с доставляемостью обычно прячутся на стыках ролей. Если на этапе отправки DKIM сформирована некорректно, принимающая сторона может снизить доверие к письму или направить его в «Спам». Точное поведение зависит от политики DMARC, репутации домена, истории отправок и особенностей конкретного провайдера.

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

Серверы входящей и исходящей почты — не одно и то же

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

Исходящая почта проходит через SMTP-сервер. Он принимает сообщение от авторизованного клиента или приложения, проверяет, имеет ли отправитель право использовать указанный адрес, и передаёт письмо дальше. Для массовых рассылок к этому добавляются очереди, ограничение скорости, обработка отказов, статистика и контроль жалоб.

Входящая почта приходит на сервер, указанный в MX-записях домена. После SMTP-приёма сообщение проходит фильтрацию, попадает в ящик и становится доступным через IMAP, POP3 или веб-интерфейс. Один сервер может обслуживать оба направления, но логика, правила доступа и требования к безопасности у них разные.

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

Сетевые протоколы и порты: от SMTP до IMAP

Почта работает поверх TCP/IP, и у каждого протокола есть своё назначение. Порт сам по себе не делает соединение безопасным: защищённость зависит от режима TLS, проверки сертификата, аутентификации и политики сервера. Но понимать базовое распределение портов необходимо каждому, кто настраивает корпоративный домен или подключает почтовый сервис к CRM.

SMTP и порты отправки

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

Если хостер блокирует исходящие соединения на 25-м порту, это не обязательно означает неисправность сервера. Такая блокировка часто используется как мера против массового спама с новых виртуальных машин. Владелец сервера может запросить разблокировку, подтвердить назначение адреса и описать предполагаемые объёмы отправки. Иногда проще направить исходящую почту через SMTP-релей провайдера или специализированный ESP.

Порт 587 предназначен для клиентской отправки, то есть для submission. Когда пользователь нажимает «Отправить» в Outlook или приложение передаёт письмо через авторизованный SMTP, соединение обычно устанавливается именно с этим сервисом. Он поддерживает STARTTLS: сначала создаётся соединение, затем оно переводится в защищённый режим. Сервер при этом должен требовать аутентификацию и не позволять анонимную пересылку писем на внешние адреса.

Порт 465 использует SMTPS с немедленным установлением TLS. Исторически его статус менялся, но на практике он по-прежнему поддерживается многими почтовыми платформами и интеграциями. Главное — не путать режимы: для 587 обычно настраивают STARTTLS, а для 465 — TLS с самого начала соединения. Если выбрать неправильный режим, клиент не сможет пройти подключение даже при верных логине и пароле.

POP3 и IMAP

Порты 110 и 995 относятся к POP3, а 143 и 993 — к IMAP. Оба протокола используются для получения писем, но работают по разной логике.

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

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

Для командной и маркетинговой работы POP3 часто становится источником лишних проблем. Если письма скачаны на один ноутбук, а копии на сервере не сохраняются, легко потерять историю, ответы клиентов и содержимое общей папки «Отправленные».

Именно поэтому мы для рабочих ящиков команды используем IMAPS на 993-м порту. Это не универсальная страховка от всех инцидентов, но нормальная основа для синхронизации, резервного копирования и контроля переписки. При этом IMAP не заменяет резервную копию: удалённое письмо или повреждённый ящик могут синхронно исчезнуть со всех подключённых устройств.

DNS как маршрутизатор: MX-записи и доставка

Когда MTA отправляет письмо на адрес домена, он сначала обращается к DNS. Там хранится MX-запись (Mail Exchange), которая указывает, какой узел принимает почту для этого домена.

MX-запись содержит имя хоста, а не IP-адрес. Например, домен может указывать на mx1.mail-nation.com, а уже для этого имени в DNS должна существовать A-запись для IPv4 или AAAA-запись для IPv6. Такая двухступенчатая схема позволяет менять адрес сервера, не переписывая MX во всех зависимых системах.

Приоритет MX задаётся числом: чем оно меньше, тем раньше отправляющий сервер попробует соответствующий узел. Резервный сервер имеет большее значение и используется, если основной недоступен или не принимает почту.

Резервный MX — не всегда полноценная копия основного сервера. В некоторых архитектурах он только принимает сообщения и временно удерживает их до восстановления главного узла. Если резервный сервис настроен неправильно, он может стать источником дополнительной уязвимости или принять почту, которая затем не будет доставлена пользователю. Поэтому при добавлении нескольких MX нужно понимать, какую роль играет каждый из них и как он обменивается данными с основным сервером.

Если MX-запись отсутствует, RFC 5321 допускает fallback на A-запись или AAAA-запись домена: отправляющий сервер может попытаться доставить письмо напрямую на IP-адрес домена. На практике этот механизм не стоит считать надёжным планом. Многие провайдеры относятся к такой конфигурации настороженно или вообще не используют fallback в ожидаемом владельцем сценарии. Отсутствие MX может привести к сбоям доставки и снижению доверия; для бизнес-почты запись следует настроить явно. Клиенты в этом случае действительно могут не получить подтверждение, ответ или уведомление и решить, что компания недоступна.

PTR и обратная проверка адреса

Помимо прямой записи MX, важна обратная DNS-зона — PTR-запись. Она связывает IP-адрес исходящего сервера с его каноническим именем. Для IPv4 записи хранятся в зоне in-addr.arpa, для IPv6 используется отдельная обратная зона.

Принимающий сервер может выполнить reverse DNS lookup и проверить, соответствует ли имя отправителя ожидаемой конфигурации. Обычно оценивается не одна запись, а согласованность нескольких элементов:

• IP-адрес отправителя имеет PTR;
• имя из PTR разрешается обратно в тот же IP через A или AAAA;
• имя выглядит как полноценное имя почтового узла, а не случайный адрес виртуального сервера;
• SMTP-сервер представляет себя тем же или согласованным именем в приветствии EHLO;
• адрес не имеет плохой истории и не числится в известных списках блокировок.

PTR не гарантирует попадание во «Входящие», но его отсутствие или явная несогласованность ухудшают положение нового отправителя. Это особенно заметно у собственного сервера, где владелец должен самостоятельно запросить обратную запись у хостера. В облачных ESP подобные параметры обычно настраиваются через панель домена или инструкцию сервиса.

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

Аутентификация отправителя: SPF, DKIM и DMARC

Если MX отвечает за то, чтобы письмо нашли, то SPF, DKIM и DMARC помогают принимающей стороне понять, имеет ли отправитель право использовать домен и что делать при нарушении политики. Это не три взаимозаменяемых флажка, а разные уровни проверки.

SPF: кто имеет право отправлять

SPF (Sender Policy Framework) — TXT-запись DNS, в которой перечислены серверы и сервисы, имеющие право отправлять почту от имени домена. Получатель сравнивает IP отправителя с этой политикой.

Пример записи:

v=spf1 ip4:192.0.2.1 include:_spf.google.com -all

Здесь ip4 добавляет конкретный IPv4-адрес, include подключает правила стороннего отправляющего сервиса, а -all означает, что остальные источники не авторизованы. Мягкий вариант ~all не даёт такой жёсткой оценки и чаще используется на этапе настройки, когда владельцу ещё нужно проверить все легитимные источники.

Главная практическая ошибка — создавать отдельную SPF-запись для каждого сервиса. У домена должна быть одна SPF-политика, в которую аккуратно включены CRM, ESP, корпоративная почта и другие разрешённые отправители. Если сервисов становится много, запись усложняется, а лимиты DNS-запросов могут стать отдельной проблемой. Поэтому SPF лучше проектировать заранее, а не дописывать случайные include после каждого инцидента с доставкой.

SPF проверяет путь передачи, но не делает подпись письма и не защищает видимый адрес отправителя от всех видов подмены. Поэтому одного SPF для серьёзной инфраструктуры недостаточно.

DKIM: подпись содержимого

DKIM (DomainKeys Identified Mail) — криптографическая подпись, которая добавляется к письму на стороне отправляющего сервера. В заголовке DKIM-Signature указываются домен подписи, селектор и набор подписанных заголовков. Приватный ключ хранится у отправляющей стороны, а открытый публикуется в DNS по адресу вроде selector._domainkey.example.com.

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

Селекторы позволяют менять ключи без мгновенного отключения всей почты. Новый ключ публикуют под отдельным селектором, переводят отправку на него, проверяют результаты и только затем удаляют старую запись. Для компаний с несколькими сервисами отправки это удобнее, чем использовать один ключ для всего домена.

DMARC: политика и отчёты

DMARC (Domain-based Message Authentication, Reporting & Conformance) связывает результаты SPF и DKIM с доменом в адресе отправителя и задаёт политику для писем, которые не проходят проверку. В общем виде владелец домена сообщает принимающему серверу, как поступать с подозрительными сообщениями и куда отправлять отчёты.

DMARC также поддерживает выравнивание доменов: домен, видимый пользователю в поле From, должен быть согласован с доменом, прошедшим SPF или DKIM. Именно здесь часто обнаруживается проблема с CRM или ESP: сервис технически отправляет письмо от разрешённого домена, но домен в видимом адресе не совпадает с доменом аутентификации.

Агрегированные отчёты rua показывают, какие источники отправляли письма от имени домена и как они прошли проверки. Обычно это XML-файлы, которые затем обрабатываются специальными сервисами или внутренними инструментами. Forensic-отчёты ruf могут содержать больше сведений о отдельных сбоях, но их поддержка и объём данных зависят от политики принимающего провайдера. Полагаться только на ruf не стоит: для регулярного контроля чаще используют агрегированные отчёты.

Перед переходом к жёсткой политике полезно начать с p=none, собрать данные по CRM, Helpdesk, сайту и другим источникам отправки, а затем постепенно усиливать правила. Резкий переход к reject без инвентаризации сервисов способен заблокировать не чужую подделку, а собственные транзакционные письма.

В команде мы используем Mailgun и собственный домен, а DMARC-политику выбираем с учётом конкретного проекта, его источников отправки и готовности отслеживать отчёты. Само наличие p=quarantine или p=reject не заменяет контроля базы, обработки отписок и мониторинга жалоб. Аутентификация подтверждает происхождение письма, но не заставляет получателя любить его содержание.

Сколько ресурсов нужно собственному почтовому узлу

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

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

Условная конфигурация для связки Postfix, Dovecot, SpamAssassin и ClamAV может выглядеть так:

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

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

На этапе прогрева нового домена или IP-адреса отправитель должен действовать постепенно и следить за bounce-рейтами, жалобами и реакцией принимающих провайдеров. Ресурсы VPS сами по себе не прогревают репутацию. Можно купить мощную машину, но всё равно получить плохую доставляемость из-за некачественной базы, резкого роста объёмов или отсутствия нормальной аутентификации.

Из инфраструктурных требований особенно важны:

• стабильная работа и понятные условия доступности у хостера;
• возможность настроить PTR-запись и изменить её при переносе сервера;
• выделенный IP с чистой историей;
• корректные A, AAAA, MX, SPF, DKIM и DMARC;
• резервное копирование почтовых ящиков и конфигураций;
• мониторинг очередей, диска, сертификатов, авторизации и отказов;
• ограничение исходящей отправки, чтобы взломанный ящик не превратил сервер в открытый спам-узел;
• отдельная политика хранения и удаления писем.

KVM-виртуализация часто удобнее для почтового сервера, чем окружения, где провайдер жёстко ограничивает сетевые настройки. Но тип виртуализации не решает автоматически вопросы репутации, резервирования и безопасности. Перед заказом нужно уточнить, разрешены ли нужные сетевые правила, можно ли управлять PTR и как хостер реагирует на жалобы на abuse.

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

Что выбрать: свой узел или облачный ESP

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

Собственный узел имеет смысл, когда важны:

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

Облачный ESP удобнее, когда нужны:

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

Мы в команде чаще разделяем роли, чем пытаемся отправить всё через один канал. Корпоративная почта живёт в специализированной почтовой системе, транзакционные сообщения могут идти через отдельный отправляющий сервис, а маркетинговые кампании — через ESP с нужной аналитикой. Такая схема позволяет не смешивать пользовательскую переписку, автоматические уведомления и массовые рассылки.

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

Понимание того, что стоит за вашим mx1.company.com, — не серверный эзотеризм, а рабочий инструмент. Почтовые сервера mail связывают пользовательские клиенты, DNS, SMTP, хранилище и системы аутентификации в одну цепочку. Если хотя бы одно звено настроено небрежно, письмо может не дойти, задержаться или попасть под фильтр.

Маркетологу не обязательно самостоятельно поднимать Postfix и отлаживать TLS. Но ему полезно знать, где заканчивается проблема контента и начинается инфраструктура: проверять домен отправителя, понимать назначение MX, отличать IMAP от SMTP, запрашивать отчёты DMARC и не считать «Спам» случайностью. Тогда разговор с администратором становится предметным, а доставляемость — управляемым параметром, а не поводом разводить руками перед падающими цифрами в дашборде.