Mail subdomain на shared-хостинге: когда выделять домен для почты и как это влияет на deliverability

Когда вы отправляете почту с shared-хостинга, вы почти всегда делите инфраструктуру с соседями: SMTP-пулы, IP-адреса, иногда общие ограничения по лимитам и очередям. Это не «плохо само по себе», но deliverability (доставляемость) становится зависимой не только от вашей дисциплины, но и от общей санитарии площадки.

Отсюда типовая дилемма админа/вебмастера: оставлять отправку с основного домена или вынести её на mail subdomain (например, mail.example.com) или вообще использовать отдельный домен для email (например, example-mail.com). На практике это выбор между управляемостью репутации/рисков и простотой «как привыкли».

Ниже разберём, что реально влияет на доменную репутацию, как устроены alignment и DMARC organizational domain, почему «поддомен для почты» не всегда изолирует риски, и какие практики дают заметный эффект именно на shared-хостинге.

Почему «mail subdomain + shared» почти всегда про deliverability

Почтовые провайдеры оценивают не только содержание письма. Они собирают сигналы по доменам, ключам DKIM, частоте отказов (bounces), жалобам пользователей, резким всплескам объёма и множеству поведенческих факторов. На shared-инфраструктуре отдельные сигналы могут быть «шумнее»: у вас меньше контроля над исходящим IP и его rDNS, а иногда и над политиками MTA.

Поэтому решение «поддомен или отдельный домен» стоит принимать не как косметику, а как часть стратегии: разделение потоков, настройка авторизации (SPF/DKIM/DMARC), и дисциплина базы адресов (bounce handling).

Быстрая карта понятий: что именно сравнивает DMARC

Чтобы не путаться, держите в голове четыре сущности — они участвуют в проверках и сильно влияют на результат.

• RFC5322.From — адрес в заголовке From:, который видит пользователь (например, no-reply@example.com).
• Envelope From (Return-Path) — адрес для возвратов и bounces (например, bounce@bounces.example.com).
• SPF domain — домен, который проверяется в SPF (обычно берётся из Envelope From).
• DKIM d= — домен, которым подписано письмо (например, d=example.com или d=mail.example.com).

Отдельно важен термин DMARC organizational domain — «организационный домен», определяемый по Public Suffix List. Например, для a.b.example.co.uk организационным будет example.co.uk. DMARC-политика обычно работает и наследуется вокруг этого уровня.

DMARC смотрит не на «какой сервер отправил», а на то, как соотносятся домены в From, SPF и DKIM, то есть на alignment.

Alignment: почему поддомен не даёт «магической изоляции»

Alignment в DMARC — это соответствие доменов между From: и доменами, которые прошли SPF и/или DKIM. Есть два режима: relaxed (по умолчанию) и strict.

• Relaxed: достаточно, чтобы домены совпадали на уровне organizational domain. То есть mail.example.com будет «согласован» с example.com.
• Strict: домены должны совпасть полностью (поддомен к поддомену).

Практические выводы:

• Если у вас From: @example.com, а DKIM подписывает d=mail.example.com, то при relaxed alignment DMARC обычно проходит. При strict — нет.
• Если вы надеетесь «отгородить репутацию» поддоменом, то изоляция будет частичной: ряд механизмов репутации и фильтрации работает на уровне organizational domain и поведения потока, а не только по конкретному FQDN.

Из полезной практики: если вы хотите предсказуемости DMARC, старайтесь, чтобы хотя бы один из механизмов (SPF или DKIM) проходил с доменом, согласованным с From. В shared-среде чаще проще сделать ставку на DKIM.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Mail subdomain: что он реально даёт в администрировании

Поддомен вида mail.example.com обычно используют в трёх сценариях:

• Хостнейм SMTP/IMAP — чтобы клиенты подключались к понятному имени.
• Домен DKIM-подписи — например, подписывать d=mail.example.com, чтобы отделить ключи и ротацию от основного домена.
• Bounce-домен — например, bounces.example.com для возвратов и автоматической обработки ошибок доставки.

Плюсы:

• Проще разделять роли: отдельные TXT, отдельные селекторы DKIM, отдельные сервисные записи.
• Можно делегировать управление поддоменом (например, сервису рассылок), не отдавая контроль над всей зоной.
• Удобнее диагностика: по заголовкам и логике адресов легче понимать, какой поток сломался.

Минусы и ловушки на shared-хостинге:

• Не гарантирует изоляцию доменной репутации, если пользовательский From остаётся основным доменом.
• Часто нет возможности настроить стабильный PTR/rDNS «под ваш домен» для shared-IP, а для части фильтров это заметный сигнал.
• Если вынесли Return-Path на поддомен, но не наладили bounce handling, репутация будет деградировать «тихо»: база захламляется, hard-bounce растёт, inbox placement падает.

Если вы упираетесь в ограничения shared-инфраструктуры (лимиты, очереди, репутация IP, невозможность rDNS), то логичный шаг — перевести отправку на отдельную управляемую машину. В таких кейсах практичнее использовать VDS, где вы контролируете MTA и можете выстроить более предсказуемый контур (в рамках требований почтовых провайдеров).

Отдельный домен для email: когда он действительно нужен

Separate domain for email — это когда видимый From и/или технические домены (Return-Path, DKIM) уезжают на другой organizational domain. Пример: транзакционные письма остаются с no-reply@example.com, а маркетинговые идут с news@example-mail.com.

Зачем так делают:

• Жёсткая сегментация рисков: массовые рассылки и высокий процент жалоб не тянут вниз основной домен компании.
• Отдельный прогрев и независимая история отправок.
• Проще менять провайдера отправки для маркетинга без влияния на DMARC-политику и ключи основного домена.

Цена подхода:

• Тяжелее объяснять пользователю, почему письмо «не с основного домена» (важно для счетов, входов, reset-паролей).
• Если From остаётся на example.com, а SPF/DKIM уходят на другой organizational domain, DMARC может не пройти вообще.
• Нужно аккуратно выстроить брендирование и безопасность, иначе растут жалобы «похоже на фишинг».

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

Если вы планируете отдельный домен под рассылки, заранее продумайте регистрацию и защиту бренда (основной домен, запасные зоны, похожие написания). Для этого удобна регистрация доменов с быстрым управлением DNS.

Практичная матрица выбора: что делать в вашем случае

1) Только транзакционные письма (регистрация, чеки, уведомления)

• Обычно достаточно основного домена + поддомена(ов) для сервисных записей.
• Рекомендация: From = основной домен; DKIM — либо d=example.com, либо d=mail.example.com (следить за alignment); Return-Path — отдельный поддомен под bounces.

2) Транзакционные + небольшие рассылки (до десятков тысяч в месяц)

• Часто достаточно разделить потоки поддоменами в одном organizational domain: news.example.com, bounces.example.com.
• DMARC остаётся управляемым, а диагностика потоков становится проще.

3) Массовый маркетинг/промо, высокий риск жалоб

• Маркетинг лучше вынести на отдельный домен и не смешивать с основным доменом компании.
• Транзакционку оставить на основном домене, чтобы не терять доверие и узнаваемость.

DMARC и поддомены: как использовать sp= и наследование

DMARC по умолчанию распространяется на поддомены. Но вы можете задать отдельную политику для поддоменов через тег sp (subdomain policy). Это удобно, если вы хотите закрыть спуфинг поддоменов, которые точно не должны отправлять почту.

Модельная конфигурация (как логика, а не «копипаста на все случаи»):

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; sp=quarantine; adkim=r; aspf=r; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1"

Пояснение по смыслу:

• p=none на старте даёт мониторинг без жёсткого влияния на доставку.
• sp=quarantine делает поддомены строже (если вы уверены, что у поддоменов всё подписано и согласовано).
• adkim и aspf управляют strict/relaxed для DKIM и SPF.

Про практическую работу с отчётами DMARC и их влиянием на deliverability удобнее читать отдельно: как разбирать DMARC-отчёты и находить источники проблем.

Best practice на shared-хостинге: что даёт максимум эффекта

1) DKIM как основной «якорь» идентичности

В shared-среде SPF часто ограничен инфраструктурой (общие IP, пересекающиеся отправители). DKIM даёт более «персональную» криптографическую привязку домена к письму и обычно сильнее помогает прохождению DMARC.

• Делайте DKIM-подпись стабильной и понятной, с ротацией селекторов без хаоса.
• Следите, чтобы домен d= оставался согласованным с доменом в From (для DMARC alignment).

Если вы планируете ротацию DKIM и хотите сделать её предсказуемой (TTL, параллельные селекторы, период перекрытия), пригодится материал: ротация DKIM: селекторы и TTL без потери доставляемости.

2) SPF — минимальный и контролируемый

SPF чаще ломается не «потому что не нужен», а из-за перегруза include и превышения лимита DNS lookup. Если у вас много сервисов отправки, не пытайтесь впихнуть всё в одну запись ради удобства.

• Держите SPF кратким и актуальным.
• Отдельные сервисы отправки лучше разводить по поддоменам/доменам, чем копить бесконечные include.

3) Bounce handling — не опция

Если не удалять или не подавлять плохие адреса, вы копите hard-bounce, и провайдеры начинают резать доставку даже на хорошие ящики. На shared-хостинге это проявляется особенно быстро, потому что «запас доверия» к инфраструктуре обычно ниже.

• Разделяйте возвраты (Return-Path) на отдельный поддомен, чтобы проще маршрутизировать и анализировать ошибки.
• Hard-bounce (ящика не существует) выводите из базы быстро; soft-bounce анализируйте по повторяемости.
• Следите за шумом: автоответчики, переадресации и циклические ответы могут портить статистику.

4) Consistent identity: один поток — один «образ»

Частая ошибка: письмо уходит с одного SMTP, DKIM подписывает другим доменом, Return-Path третьим, а From вообще четвёртым. Фильтры видят «сборную солянку» и начинают относиться подозрительно.

• Для транзакционки выберите один доменный набор: From, Return-Path, DKIM d=.
• Для маркетинга — отдельный набор (поддомен или отдельный домен), без пересечений.

5) Предсказуемый объём и прогрев

Резкий всплеск объёма, особенно с shared-IP, часто воспринимается как подозрительная активность. Планируйте рост отправок и прогревайте потоки.

• Увеличивайте объём постепенно.
• Не делайте «вчера 50 писем, сегодня 50 000» без стратегии прогрева домена/потока и контроля жалоб.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Типовые схемы доменов и поддоменов (шаблоны, не догма)

Несколько практичных схем, которые обычно упрощают поддержку:

• Транзакционные: From: no-reply@example.com, DKIM d=example.com (или d=mail.example.com), Return-Path на поддомене bounces.example.com.
• Маркетинг (поддомен): From: news@news.example.com, DKIM d=news.example.com, Return-Path bounces.news.example.com.
• Маркетинг (отдельный домен): From: news@example-mail.com, DKIM d=example-mail.com, Return-Path bounces.example-mail.com.

Важный нюанс: для маркетинга From на поддомене формально работает, но иногда вызывает вопросы у пользователей. В транзакционке лучше держать From максимально «узнаваемым».

Чек-лист: что чаще всего ломает deliverability на shared

Если письма начали падать в спам или «теряться», идите по порядку:

1. DMARC alignment: совпадает ли домен From с доменом, который прошёл SPF или DKIM (хотя бы один должен быть aligned).
2. DKIM: валидируется ли подпись, не меняет ли письмо промежуточный обработчик (перекодировка, подписи внизу, правка тела письма).
3. SPF: правильный ли домен проверяется (Envelope From), нет ли превышения DNS lookup, нет ли конфликтующих записей.
4. Bounce handling: растёт ли доля hard-bounce, как быстро чистится база, не идут ли повторные попытки на «мёртвые» адреса.
5. Сегментация потоков: транзакционка не должна отправляться тем же потоком, что и «промо по всем».

Итог: поддомен или отдельный домен?

Mail subdomain — отличный инструмент структурирования: удобнее управлять DNS, ключами DKIM, bounce-доменами и ролями. Но ожидать, что он полностью отделит domain reputation от основного домена, не стоит: для DMARC и многих антиспам-сигналов важнее alignment, поведение потока и качество базы.

Отдельный домен для email — стратегия управления риском. Она оправдана, когда у вас есть массовые рассылки и вероятность жалоб, и вы хотите защитить основной домен компании. Главное — не потерять доверие пользователей и не сломать DMARC из-за несогласованных доменов.

Если вы на shared-хостинге и хотите быстрый прирост доставляемости, начните с трёх вещей: DKIM + DMARC с правильным alignment, аккуратный bounce handling и разделение потоков (хотя бы поддоменами). Это обычно даёт эффект заметнее, чем любые «секретные настройки».