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

Рассмотрим пример: вы настроили почтовые алиасы домена - sales@yourcompany.com направляется в ваш ящик, support@ в службу поддержки. В панели администратора всё выглядело правильно. Затем заявки перестали приходить, клиент сообщил о возврате письма, а вы обнаружили, что уже три недели отвечаете с личного адреса.

Если почтовый алиас домена не работает, проверьте не только опечатки, но и маршруты с аутентификацией. Старые правила пересылки могут конфликтовать с SPF, DKIM и DMARC, даже если при настройке это не было заметно.

Если вы видите 550 5.7.520, 554 5.4.14 или письма исчезают после вежливого 250 OK от вашего сервера, пора перейти от догадок к проверке. Здесь разобраны пять распространённых ошибок настройки, характерные коды и способы устранения.

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

Действительно ли алиас не работает? Начните здесь

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

Почему возникают сбои: проблема двух адресов отправителя

У письма есть несколько идентификаторов отправителя, и здесь важны два из них. Envelope Sender (RFC 5321 MAIL FROM) используется серверами для возвратов; SPF проверяет его домен или применимый идентификатор HELO. Header Sender (RFC 5322 From:) виден получателю в Gmail или Outlook. Для DMARC нужен хотя бы один успешно прошедший механизм SPF или DKIM с доменом, согласованным с этим From.

Внутренняя доставка - например, с sales@ на bob@ на том же сервере - не обязательно нарушает аутентификацию. При внешней пересылке сервер получателя видит IP пересылающего сервера. Если исходный Envelope Sender сохранён, а этот IP не разрешён его доменом, SPF может не пройти. При политике p=reject письмо может быть отклонено, если не сохранилась подходящая согласованная DKIM-подпись. Отклонение, карантин и уведомления о недоставке зависят от серверов и их политик; бесследное исчезновение не является обязательным исходом.

Ошибка настройки 1: внешняя пересылка без SRS

Пересылка с алиаса домена на Gmail, Yahoo или личный Outlook.com может нарушить проверку SPF. Строгая политика DMARC повышает риск, если нет другого согласованного способа аутентификации. В период 2025-2026 это важный сценарий диагностики, особенно для отправителей с p=reject.

Пример: клиент alice@bank.com пишет на contact@yourdomain.com. Ваш сервер пересылает письмо на you@gmail.com. Gmail проверяет SPF домена bank.com. IP пересылающего сервера не разрешён в этой записи, поэтому SPF может не пройти. У банка стоит p=reject. Если нет согласованной DKIM-подписи, Gmail может отклонить письмо. Ранее выданный вашим сервером 250 OK подтверждает только приём им сообщения, а не конечную доставку; последующее уведомление об ошибке всё ещё возможно.

Один из инструментов: Sender Rewriting Scheme (SRS). SRS переписывает Envelope Sender на ваш домен перед пересылкой:

Исходный адрес в конверте: alice@bank.com
После переписывания SRS: SRS0=hash=TT=bank.com=alice@yourdomain.com

Теперь Gmail проверяет SPF для yourdomain.com. Если сервер разрешён этой записью, SPF может пройти. SRS включается на уровне сервера вашим хостинг-провайдером или администратором почты. Для Postfix и Exim существуют интеграции SRS.

Важное ограничение: SRS может обеспечить прохождение SPF для нового домена конверта, но не восстанавливает исходное согласование DMARC. Для согласования DMARC может быть достаточно сохранившейся действительной DKIM-подписи, согласованной с исходным доменом From. ARC (Authenticated Received Chain) предоставляет дополнительные сведения при действительной цепочке и доверии к проверенному подписывающему посреднику. Их использование остаётся на усмотрение получателя и не создаёт согласования. Новая DKIM-подпись другого домена также не устраняет это несоответствие.

Более простая архитектура: по возможности не пересылайте почту внешнему провайдеру. Используйте настоящий IMAP-ящик своего домена и открывайте его мобильным клиентом. Внешняя пересылка, распространённая ещё в 2012, требует особой аккуратности при современной аутентификации, но не является заведомо неработоспособной.

Ошибка настройки 2: Microsoft 365 блокирует внешнюю пересылку

Если алиас пересылает письма наружу, а отправители получают 550 5.7.520 Access denied, проверьте политики Microsoft. Стандартное значение «Automatic - System-controlled» в фильтре исходящего спама Exchange Online блокирует автоматическую внешнюю пересылку. Это ограничение помогает предотвращать утечки данных; на результат могут влиять и другие политики.

Изменение в административном портале:

1. Откройте портал Microsoft 365 Defender
2. Перейдите в: Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. Проверьте Anti-spam outbound policy (Default); её изменение действует на всю организацию, поэтому предпочтительна отдельная политика для согласованных аккаунтов
4. Установите для «Automatic forwarding rules» значение On - Forwarding is enabled только в одобренной политике

Разрешайте пересылку только при наличии необходимых полномочий и для согласованных аккаунтов. Для них лучше создать отдельную исходящую политику. Следующая команда PowerShell меняет настройки по умолчанию для всей организации; предварительно проверьте требования безопасности и дополнительные ограничения.

Вариант через PowerShell:

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

Ошибка настройки 3: петля маршрутизации

Петля маршрутизации может вызвать 554 5.4.14 Hop Count Exceeded. Письмо перемещается между адресами, пока сервер не достигнет настроенного предела переходов - например, 15-20 в конкретной среде, а не как универсальная норма. После этого отправитель может получить уведомление о недоставке, а в вашем ящике письмо так и не появится.

Частая причина петли - забытое правило входящих в конечном ящике:

Алиас на сервере: info@ → admin@
Правило ящика admin@: пересылать всё на info@ для архива
Результат: цикл до превышения числа переходов

Проверьте, например, автоответчик, настроенный два года назад, или забытое правило «пересылать всё на info@ для архива». Это возможные причины, а не однозначный диагноз. Нужно проверить и серверные алиасы, и правила входящих в клиенте. В Exchange изучите Transport Rules в центре администрирования. В Google Workspace проверьте «Filters and Blocked Addresses» каждого затронутого аккаунта.

Структурное решение - исключить повторную обработку того же алиаса. Уточните, когда сервер раскрывает алиасы и выполняет пользовательские правила. Перенаправление с сохранением исходного получателя может в некоторых схемах снова задействовать тот же алиас. Организуйте однозначный маршрут доставки и проверьте его фактическое поведение, а не полагайтесь только на название действия «redirect» или «deliver to».

Ошибка настройки 4: неверный адрес отправителя

Алиас, который только принимает почту, подходит не для всех задач. Если вы отвечаете на письмо, адресованное sales@yourcompany.com, а получатель видит bob.smith@yourcompany.com в поле From, он не видит адрес отдела, с которого вы хотели ответить. В собственном интерфейсе это легко не заметить.

Проверка Google Workspace:

1. Откройте User Settings → Accounts → «Send mail as»
2. Добавьте адрес алиаса
3. Выберите состояние «Treat as an alias» исходя из задачи. Для другого собственного адреса опция может быть уместна, а для отдельной идентичности может требоваться иное поведение. Снятие флажка не гарантирует скрытия основного адреса; проверьте From, Reply-To и полные заголовки тестового письма.

Проверка Microsoft 365:

M365 различает отправку с алиаса ящика, разрешения «Send As» и «Send on behalf». Надпись «Bob от имени Sales» зависит от разрешений и клиента. Чтобы разрешить отправку с адресов-алиасов, администратор может включить эту настройку организации:

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

Это настройка Exchange Online, а не локального Exchange. Она не заменяет разрешения «Send As» и не является универсальным способом убрать надпись об отправке от имени другого пользователя; необходимо проверить поддержку в используемом клиенте.

Ошибка настройки 5: конфликт с catch-all

Catch-all (*@domain.com) принимает письма на адреса без отдельного соответствия. Если ваша логика маршрутизации выбирает общее правило раньше подходящего точного, сообщение может попасть не в тот ящик без явной ошибки.

В индексированных таблицах Postfix для virtual_alias_maps обычно сначала выполняется точный поиск адреса, а затем поиск catch-all домена. Это не простое чтение файла сверху вниз. Порядок ниже приведён для наглядности:

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

Последняя строка с catch-all делает пример понятнее, но не задаёт универсальное правило приоритета. В упорядоченных картах PCRE порядок важен; в таблицах алиасов на MySQL результат определяется реальным запросом и механизмом поиска. Убедитесь, что точные адреса получают приоритет перед catch-all; одного порядка строк может быть недостаточно. Перед сборкой карты и перезагрузкой уполномоченный администратор должен создать резервные копии, сохранить существующие карты и проверить поддерживаемый тип, совпадения и конфигурацию.

Углублённая диагностика: прочитайте полные заголовки

Если письмо исчезло без заметного возврата, изучите полные заголовки сообщения, найденного, например, в спаме. Заголовок Authentication-Results показывает результаты аутентификации, полученные конкретным сервером получателя. Сопоставляйте их с журналами доставки и состоянием карантина.

В Gmail: откройте письмо → меню с тремя точками → «Show original». Найдите блок аутентификации:

Пример сбоя - SRS отсутствует:

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

smtp.mailfrom по-прежнему содержит alice@bank.com. Если IP принадлежит вашему пересылающему серверу, на этом пути SRS не переписал адрес конверта.

Пример успешной обработки - SRS включён:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

Адрес конверта переписан, и SPF проходит для yourdomain.com. Показанный успех DMARC требует другого согласованного результата, например сохранившейся действительной DKIM-подписи исходного домена From. В сокращённом заголовке она не показана; одного SRS недостаточно, чтобы объяснить прохождение DMARC.

Для проверки приёма адреса-алиаса по SMTP можно использовать swaks. Следующая команда может отправить тестовое письмо. Замените условные значения разрешёнными адресами и серверами под вашим контролем, не используя чужие данные отправителя:

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK в ответ на команду получателя подтверждает лишь приём этого адресата, а не окончательное принятие сообщения после DATA, существование алиаса или конечную доставку. 550 User Unknown указывает, что сервер отклоняет получателя; проверьте таблицу алиасов и правила проверки адресатов.

Профилактика: упростите маршруты и сократите переходы

Простая архитектура позволяет избежать многих ошибок алиасов. Два принципа помогают уменьшить число типичных точек отказа.

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

Правило 2: сокращайте цепочку алиасов до одного перехода.

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

Для временных адресов и кампаний можно использовать плюс-адресацию - bob+newsletter@domain.com - вместо нового алиаса каждый раз. Поддержка и необходимость настройки в TrekMail, Gmail и Exchange зависят от провайдера и параметров аккаунта; сверяйтесь с актуальной документацией. Некоторые веб-формы отклоняют символ +, поэтому способ подходит не везде.

Подробное сравнение алиасов и пересылки есть в статье пересылка почты через алиас.

Когда проблема связана с моделью оплаты

Оплата за пользователя может делать отдельные ящики дорогими. Вы создаёте алиасы, чтобы не покупать ещё одну лицензию, а затем можете потратить часы на SRS, заголовки и политики пересылки в PowerShell. Это возможный компромисс, но не объяснение любой сложной схемы алиасов. Адрес отдела не обязательно требует отдельной лицензии: проверьте возможности алиасов, групп и общих ящиков по условиям провайдера.

TrekMail использует тарифы аккаунта, а не универсальную отдельную плату за домен или ящик. В историческом примере Starter ($3.50/месяц) адреса sales@, support@ и billing@ можно создать в пределах тарифа как отдельные IMAP-ящики со своими учётными данными и адресами отправителя. Общее хранилище на уровне аккаунта может сочетаться с отдельными квотами ящиков. Проверьте актуальные ограничения и функции. Правильный отправитель по-прежнему зависит от клиента. Только в описанной модели Nano для всех исходящих писем, включая ответы, нужен собственный SMTP-провайдер; управляемая отправка в платных тарифах зависит от фактических прав.

Для агентств в этом историческом примере Pro ($10/месяц) рассчитан на 100 доменов. Проверьте текущие лимиты доменов, ящиков и хранения. Доступный инструмент IMAP-миграции может копировать письма из Gmail или cPanel при разрешённом доступе и совместимом источнике. Проверьте резервные копии, папки и сообщения, а перед переключением DNS выполните последнюю синхронизацию изменений. Контакты и календари требуют отдельного плана переноса. Отсутствие воздействия на рабочую среду не гарантируется.

Если вы впервые настраиваете почту домена, статья как создать почту на своём домене объясняет весь процесс. Актуальные тарифы аккаунта, права и ограничения смотрите на странице тарифов TrekMail. Указанный в исходной статье 14-дневный пробный период платного тарифа с обязательной банковской картой не гарантирует сегодняшних условий.

Итоги

Пять распространённых сценариев: сбой SPF при внешней пересылке без SRS, ограничения Microsoft 365, петли из-за забытых правил, неверный адрес отправителя и конфликты catch-all. Коды ошибок помогают ориентироваться, но решение зависит от маршрутизации, аутентификации и политики получателя.

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

Более широкий разбор архитектуры и диагностики пересылки начинается со статьи настройка и исправление почтовой пересылки.