Пересылка почты

Почтовый алиас: сценарии, маршрутизация и ограничения

Автор: Alexey Bulygin
Схема маршрутизации писем через почтовый алиас

Каждой функции бизнеса нужен адрес: sales@, billing@, abuse@, legal@. Список растёт быстро. В Google Workspace или Microsoft 365 каждый адрес занимает платное место. Это $6-$12/month за каждую роль, каждый месяц. Фактически это налог на порядок при оплате за пользователя.

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

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

Настройка DNS, MX и пересылки описана в руководстве о пересылке через почтовые алиасы.

Что такое почтовый адрес-алиас?

Это дополнительный входящий адрес, направляющий почту в настоящий ящик. У него нет собственной папки входящих, пароля и хранилища. При получении письма сервер переписывает получателя конверта: RCPT TO: sales@domain.com превращается в RCPT TO: alice@domain.com, после чего выполняется доставка. Отправитель видит sales@, а письмо получает Алиса. Подмена незаметна, и именно в этом её смысл.

Сценарий 1. Маршрутизация по ролям

Главная задача алиаса состоит в закреплении функциональной ответственности: публичная роль связывается с человеком, который отвечает за неё сейчас. Один алиас, один получатель. Именно эту схему один к одному закрепляет RFC 2142: каждый домен должен иметь стандартные ролевые адреса независимо от конкретных сотрудников.

АлиасФункцияПолучатель
sales@Входящие обращенияОснователь или руководитель продаж
billing@Счета и квитанцииФинансовый директор или офис-менеджер
abuse@Соблюдение RFC 2142Технический директор или системный администратор
legal@Договоры и NDAОснователь или внешний юрист
no-reply@Системные уведомленияАрхивный ящик или /dev/null

Отдельные аккаунты им не нужны. Каждый адрес является алиасом существующего ящика. В Postfix вся конфигурация занимает несколько строк в /etc/postfix/virtual:

sales@company.com     alice@company.com
billing@company.com   bob@company.com
abuse@company.com     cto@company.com
legal@company.com     alice@company.com

Postfix проверяет таблицу алиасов для каждого входящего письма и переписывает конверт до доставки. Если Алиса переходит на другую должность, измените одну строку и перезагрузите конфигурацию:

postmap /etc/postfix/virtual
systemctl reload postfix

Без заявок провайдеру, миграции аккаунтов и правил пересылки, разбросанных по трём клиентам.

Сценарий 2. Передача ответственности за инфраструктуру

Это самая недооценённая область применения алиаса и самый сложный для восстановления сбой. Любой важный SaaS-сервис, зарегистрированный на личный рабочий адрес, становится риском после ухода сотрудника.

Сценарий всегда одинаков. Стив регистрирует доменного регистратора, корневой аккаунт AWS и Stripe на steve@company.com. Он увольняется, а через 90 дней ИТ-отдел блокирует ящик. Платёжные письма возвращаются, сбросы паролей исчезают, коды 2FA от AWS недоступны. Теперь приходится доказывать владение созданным пять лет назад аккаунтом службе поддержки без SLA.

Решение: регистрировать всю инфраструктуру на постоянный алиас.

  1. Создайте ops@company.com как алиас текущего ответственного: технического директора, администратора или владельца инфраструктуры.
  2. Регистрируйте DNS, AWS, Stripe, GitHub и Cloudflare на ops@.
  3. При смене ответственного направьте алиас новому сотруднику. Одно изменение займёт меньше минуты.

Данные у поставщиков не меняются. Нет простоя, циклов «забыли пароль» и звонков с доказательством владения.

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

Сценарий 3. Отслеживание и фильтрация входящих писем

Алиасы позволяют помечать и сортировать входящий поток без новых аккаунтов, сложных правил и постоянной правки сервера. Большинство задач покрывают выделенные отслеживающие алиасы и plus addressing.

Выделенные алиасы для отслеживания

На конференции, при пробной регистрации у поставщика или подписке на сомнительную рассылку используйте адрес источника, например conf2026@company.com или acme-vendor@company.com. Если он попадёт в спам-базу или начнёт создавать шум, удалите алиас, и поток сразу прекратится. Основной адрес невозможно выборочно отозвать.

Это удобно сочетать с ящиком catch-all: любой адрес домена приходит в один ящик, а алиас можно создать позже, увидев поступающие метки.

Plus addressing, или субадресация по RFC 5233

Большинство современных серверов поддерживает субадресацию RFC 5233 через разделитель +. Создавать такие адреса не нужно, они автоматически работают на совместимом сервере.

alice+jira@company.com        → delivers to alice@company.com
alice+shopify@company.com     → delivers to alice@company.com
alice+newsletters@company.com → delivers to alice@company.com

Одно правило по метке направит все сообщения в нужную папку без административных затрат. Алиас уже существует, вы лишь добавляете к нему метаданные.

Сценарий 4. Отправка от имени алиаса и точка отказа

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

Клиент пишет на sales@company.com, письмо приходит в alice@company.com, Алиса отвечает. Клиент видит отправителя alice@company.com. Профессиональная роль исчезает, а личный рабочий адрес навсегда остаётся в контактах.

У алиасов нет учётных данных. Чтобы отправлять от их имени, настройте в клиенте отдельную исходящую личность:

  • Стандартные клиенты (Outlook, Thunderbird, Apple Mail): добавьте личность с алиасом в поле From. Используйте SMTP основного ящика. Клиент отправит через ваш аккаунт, но укажет алиас.
  • Свой SMTP (TrekMail Free или Starter с Amazon SES либо SendGrid): сначала подтвердите алиас или весь домен у SMTP-провайдера. Иначе письмо будет отклонено: 554 Message rejected: Email address is not verified. Полная схема приведена в руководстве TrekMail по своему SMTP.

Когда алиас перестаёт работать

Алиас предназначен для маршрута один к одному. Он работает, пока ведёт в один ящик. Если одновременно пересылать support@ Алисе, Бобу и Чарли, возникает рассинхронизированный общий ящик, который однажды будет стоить клиента.

Алиса решает вопрос и отвечает, но письмо сохраняется только в её Sent. Боб ответа не видит и спустя три часа отправляет противоречивую информацию. Клиент раздражён и запомнит это.

Это структурное ограничение, а не ошибка настройки. Подробное сравнение: алиас домена или почтовый ящик.

Правильное решение для общего ящика: создайте отдельный support@company.com, передайте пароль через менеджер. Алиса и Боб добавят аккаунт по IMAP. Ответ сохранится в серверной папке Sent и синхронизируется обоим. Состояние общее, ответы не пересекаются и ничего не теряется.

СценарийИнструментПричина
Роль ведёт один человекАлиасНе нужен отдельный аккаунт
Инфраструктурные аккаунтыАлиасНе зависит от смены сотрудников
Отслеживание источникаАлиасУдаляется по запросу, не занимает место
Одноразовый адрес для сомнительных регистрацийАлиасМгновенно отзывается после утечки
Читают и отвечают несколько человекЯщикОбщее состояние IMAP без конфликтов
Долгосрочная ответственность командыЯщикЖурнал и делегированный доступ

Оплата за пользователя подталкивает к неправильной архитектуре

В Google Workspace и Microsoft 365 каждый ящик платный. Поэтому команды используют алиас как общий ящик ради экономии $6/month, а затем сталкиваются с описанным сбоем. Это рациональная реакция на цену, а не лень.

У TrekMail фиксированная цена, а хранилище общее. Нет платы за ящик или алиас. Starter стоит $3.50/month за 50 доменов и 15GB общего места. Цена одинакова для 3 ящиков и 10 алиасов или 20 ящиков и 200 алиасов.

Экономика больше не заставляет выбирать неправильный инструмент. Создайте ящик support@, постоянный алиас ops@ и отдельные алиасы для конференций. Настраивайте процесс по реальной задаче.

Если начинаете с нуля, прочитайте как создать почту на своём домене: от подключения домена и DNS до первого ящика.

Кратко об адресах-алиасах

Алиас это маршрут один к одному для ролей, передачи инфраструктуры и отслеживания. Plus addressing подходит для бесплатной маркировки. Как только читать и отвечать должны несколько человек, нужен отдельный ящик. Первые три сценария подходят алиасу, четвёртому требуется общее состояние IMAP.

Перестаньте платить за каждое место

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

Starter за $3.50/month:

  • 50 собственных доменов в одном аккаунте
  • 15GB общего хранилища
  • Неограниченные алиасы
  • Маршрутизация catch-all
  • Управляемый SMTP без внешнего провайдера
  • Мастер SPF, DKIM и DMARC

За $3.50/month вы платите меньше одного места Google Workspace и получаете 50 доменов со всеми нужными алиасами.

14-дневная пробная версия доступна на trekmail.net, для запуска нужна банковская карта. Для предварительного теста есть бесплатный Nano: 10 доменов, 5GB общего места и свой SMTP, без карты и срока действия. Начните там и обновитесь позже.

Сравнить тарифы и цены →

Поделиться статьёй

Мы используем необходимые технологии для работы и защиты TrekMail. Подтверждая это, вы также разрешаете ограниченную аналитику и измерение рекламы, описанные в Политике cookie.

Вход в TrekMail

Доступ к панели, ящикам и DNS.

или

12 символов пароли совпадают

или

Письмо отправлено

Если для этого адреса есть аккаунт, мы отправили инструкции по сбросу пароля.

Продолжая, вы принимаете Условия и Политику конфиденциальности TrekMail.