В 2026 году корпоративный адрес на собственном домене должен соответствовать большему числу требований, чем три года назад. Правила Gmail и Yahoo для массовых отправителей, более строгая проверка согласования у Microsoft и постепенный переход DMARC от p=none к p=reject приводят к тому, что адреса, годами работавшие без заметных проблем, теперь получают отказы или попадают в спам.
Большинство команд узнает о правилах по одному, обычно после сбоя доставки, из-за которого теряются ответы, прежде чем кто-либо замечает проблему. Эти правила не секретны, но разрозненно описаны у регистратора, DNS-провайдера и почтового сервиса. В этом руководстве они собраны вместе.
Ниже перечислены семь правил, которым корпоративный адрес на своем домене должен соответствовать в 2026 году для надежной доставки во входящие при масштабном отправлении. Каждое правило представляет собой решение, которое принимают один раз, а затем применяют последовательно. Вопрос доверия к адресу подробнее разобран в материале про корпоративный почтовый адрес.
Почему требования ужесточились в 2024-2026 годах
Требования к корпоративным адресам на собственном домене ужесточились в 2024 году, когда Gmail и Yahoo объявили новые правила для массовых отправителей. Тем, кто отправляет более 5,000 сообщений в сутки на адреса Gmail, теперь необходимы рабочая подпись DKIM, корректная запись SPF и политика DMARC не слабее p=none с поступающими отчетами. В 2025 году Microsoft также усилила проверку согласования при p=quarantine.
Последствия ощутимы и для небольших отправителей, хотя пороговые значения рассчитаны на массовые рассылки. Алгоритмы размещения во входящих считают неаутентифицированную почту подозрительной независимо от объема. Поэтому адрес, отправляющий 50 сообщений в день с неисправным DKIM, чаще попадает в спам, чем тот же адрес с корректной аутентификацией. Новые требования просто сделали цену отсутствия аутентификации заметнее.
Семь правил вкратце
Семь правил определяют, окажется корпоративное письмо во входящих или в спаме в 2026 году. Первые четыре относятся к технической части, а именно аутентификации и согласованию. Следующие два посвящены формату имен и управлению алиасами. Последнее правило касается безопасного восстановления. Чтобы адрес вызывал доверие, все семь должны соблюдаться одновременно.
- SPF, DKIM и DMARC настроены и проходят проверку. Без исключений и обещаний добавить DMARC позднее. Все три механизма нужны с первого дня.
- Согласование DMARC соблюдается. Домен в видимом заголовке From должен согласовываться с доменом подписи DKIM и желательно с доменом SPF в Return-Path.
- Локальная часть адреса создается по документированному шаблону. firstname.lastname остается наиболее универсальным вариантом, а смешанные схемы подрывают единообразие.
- Ролевые адреса работают как алиасы. support@, sales@ и billing@ перенаправляют почту в реальные ящики сотрудников, а не становятся отдельными входящими.
- Для восстановления не используется личный Gmail. Администратор использует платный ящик у другого провайдера и защищает его аппаратным ключом 2FA.
- У каждого сервиса свой ключ DKIM. Внешнему сервису, подписывающему письма вашим доменом, назначается отдельный селектор DKIM.
- Отчеты DMARC проверяются ежемесячно. Сводные отчеты показывают легитимных отправителей и попытки подделки. Игнорировать их значит лишать политику важной части пользы.
Каждое правило можно применять с первого дня настройки. Пропуск любого из них создает отдельный риск: техническая ошибка сразу ухудшает доставляемость, организационная годами снижает доверие, а слабый канал восстановления может стоить доступа ко всему аккаунту при компрометации резервной почты.
Правило 1: три механизма аутентификации должны работать
SPF, DKIM и DMARC составляют обязательную тройку аутентификации для каждого корпоративного адреса на своем домене. SPF указывает, каким серверам разрешено отправлять от имени домена. DKIM криптографически подписывает исходящие письма. DMARC сообщает принимающей стороне, что делать при ошибке SPF или DKIM. Все три механизма публикуются в DNS, и в 2026 году ни один из них нельзя считать необязательным.
Проще всего нарушить работу SPF. Каждая директива include учитывается в лимите из 10 DNS-запросов. Если со временем без проверки добавлять новых отправителей, лимит можно незаметно превысить. Тогда SPF начнет выдавать ошибку у принимающих систем, которые соблюдают это ограничение. Проверяйте запись SPF каждый квартал и объединяйте include, использующие одного вышестоящего провайдера. Связанный путь диагностики описан в статье про согласование DMARC.
Правило 2: согласование DMARC должно соблюдаться
Согласование DMARC часто нарушается в настройках корпоративной почты незаметно для владельца. Домен в видимом заголовке From должен соответствовать домену подписи DKIM при нестрогом согласовании или полностью совпадать с ним при строгом. Если маркетинговая платформа отправляет письма от вашего домена, но подписывает их своим, согласование не выполняется. DMARC считает такое письмо не прошедшим проверку, даже если сама подпись DKIM технически корректна.
Решение заключается в отдельных ключах DKIM: каждый внешний сервис, который подписывает письма за ваш домен, получает собственный селектор в DNS. После настройки домен From согласуется с доменом подписи DKIM при каждой отправке. Маркетинговой платформе, сервису транзакционных писем и системе поддержки нужен отдельный селектор.
Если корпоративный адрес начинает проваливать согласование, диагностировать причину помогает сводный отчет DMARC. В нем перечислены все IP-адреса, отправлявшие почту от имени вашего домена за последние 24 часа, результаты DKIM и SPF, а также статус согласования. Если сервис указан как d=mailgun.com при From=yourdomain.com, причина очевидна: он подписал письмо собственным доменом. После настройки селектора ошибка должна исчезнуть в течение нескольких часов после распространения DNS и обработки новых сообщений.
Правило 3: единый формат локальной части адреса
Единый формат локальной части помогает внешним получателям отличить корпоративный адрес от любительского. Схема firstname.lastname безопаснее всего масштабируется при штате свыше 30 сотрудников. Только имя подходит командам меньше 30 человек, но создает проблему, когда появляется второй сотрудник с тем же именем. Смешанные схемы в одном домене чаще всего выглядят непрофессионально.
Важно не только выбрать шаблон, но и задокументировать и последовательно применять его. Определите формат при запуске, начните с основателя и используйте его для каждого нового сотрудника. Исключения быстро накапливаются: если основатели сохраняют короткие адреса, а команда использует firstname.lastname, клиенты видят несогласованность. Подробная схема имен приведена в материале про профессиональный почтовый адрес.
Правило 4: ролевые адреса должны быть алиасами
Ролевые адреса support@, sales@, billing@ и hello@ лучше создавать как алиасы, ведущие в реальные ящики сотрудников. Отдельные ящики требуют постоянной проверки, а забытые входящие со временем наполняются непрочитанными обращениями. Именно алиасы позволяют корпоративной почте расти без потери клиентских сообщений.
Тарифные лимиты TrekMail на алиасы поддерживают эту модель: 30 на ящик в Starter, 50 в Pro и 100 в Agency. Команда из 10 человек на Pro может использовать 10 реальных ящиков и 500 алиасов за $96/year. Каждый алиас перенаправляется сотруднику, который сейчас отвечает за функцию. При смене ответственного адрес перенастраивается за 30 seconds без миграции почтового ящика.
Правило 5: личный Gmail не подходит для восстановления
Способ восстановления административного аккаунта определяет безопасность всех корпоративных адресов домена. Если резервным адресом служит личный Gmail со слабой 2FA, весь аккаунт наследует эту уязвимость. Злоумышленники часто сначала атакуют почту восстановления как наиболее простой путь к захвату аккаунта, а личный Gmail представляет собой предсказуемую цель.
Решение невелико по стоимости: назначьте для восстановления администратора платный ящик у другого провайдера, чтобы сбой одного сервиса не лишил вас доступа, защитите его аппаратным ключом 2FA и не используйте в цепочке бесплатный потребительский Gmail. Аппаратный ключ стоит около $25 один раз и при правильной настройке делает фишинговую атаку значительно сложнее.
Еще одна важная деталь: резервный ящик не должен находиться в том же домене, который восстанавливает. Если оба адреса работают на yourcompany.com, а домен заблокирован или перехвачен у регистратора, доступ к ним будет потерян одновременно. Восстановление через другой домен защищает от сбоя одного домена, который может оказаться вероятнее полного отказа отдельного провайдера.
Как TrekMail помогает соблюдать семь правил
Мастер настройки TrekMail автоматизирует техническую часть: для каждого нового домена формируются записи SPF, DKIM и DMARC. Согласно опубликованным возможностям сервиса, отдельные ключи DKIM клиентов меняются по расписанию на всех тарифах без ручного вмешательства администратора. Сводные отчеты DMARC направляются в назначенный для домена ящик.
Единые имена, управление алиасами и способ восстановления относятся к внутренним политикам, которые TrekMail поддерживает, но не может выбрать за команду. По опубликованным условиям Pro за $10/month предоставляет 50 алиасов и 10 почтовых правил на ящик для настройки пересылки. Agency за $29/month добавляет редактор исходных правил Sieve для сложного хранения и маршрутизации. Для большинства типовых пересылок достаточно редактора правил Pro без работы с синтаксисом Sieve. Основы согласования разобраны в статье про DMARC.
Следующие шаги
Корпоративный адрес, выполняющий все семь правил в 2026 году, создается правильной настройкой, а не покупкой максимального набора функций. Технические правила начинают действовать после публикации и распространения DNS-записей. Для организационных и административных правил нужна письменная политика, которую команда применяет последовательно. Первичная работа занимает примерно половину дня и помогает избежать многих проблем с доставляемостью и доверием в последующие годы.
По опубликованным условиям TrekMail Pro за $96/year подходит многим растущим командам: в него входят 50 алиасов, 10 почтовых правил на ящик и полный доступ к API. Сначала бесплатно проверьте процесс на Nano. Регистрация доступна на trekmail.net/pricing. Более широкий вопрос доверия разобран в руководстве про профессиональный почтовый адрес.
