Каждой функции бизнеса нужен адрес: 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.
Решение: регистрировать всю инфраструктуру на постоянный алиас.
- Создайте
ops@company.comкак алиас текущего ответственного: технического директора, администратора или владельца инфраструктуры. - Регистрируйте DNS, AWS, Stripe, GitHub и Cloudflare на
ops@. - При смене ответственного направьте алиас новому сотруднику. Одно изменение займёт меньше минуты.
Данные у поставщиков не меняются. Нет простоя, циклов «забыли пароль» и звонков с доказательством владения.
Схема работает потому, что постоянным активом является сам адрес. Его внутренний маршрут можно менять в любое время, поставщику об этом знать не нужно.
Сценарий 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, без карты и срока действия. Начните там и обновитесь позже.