Transactional vs marketing: архитектура email domains, DKIM/DMARC и alignment без сюрпризов

Если у вас один домен и в нем живут и чек-письма, и массовые рассылки, и ответы поддержки — рискуете общей репутацией. Один неудачный выпуск рассылки с жалобами на спам или высокая доля бэунсов ударят по доставляемости критических уведомлений: восстановление пароля, OTP, чеки, транзакции. Правильная архитектура email domains, четкое разделение transactional и marketing потоков, плюс аккуратно настроенные SPF/DKIM/DMARC с корректным alignment — база, которой часто пренебрегают. В этой статье я покажу практическую схему, на что смотреть в DNS и почтовом стеке, как не потерять письма в промо или спам, и как безопасно ужесточать DMARC.

Transactional vs marketing: в чем техническая разница

Условимся в терминологии:

• Transactional — триггерные письма по действию пользователя или системы: регистрация, подтверждение email, OTP, смена пароля, уведомления о заказе/статусе, инвойсы.
• Marketing — промо, дайджесты, новостные и контентные рассылки, ретаргетинг, рекомендации.

Ключевое отличие — терпимость аудитории и метрики. Для transactional нормальны почти нулевые жалобы, а для маркетинга жалобы и отписки неизбежны. Поэтому смешивать потоки под одним доменом опасно: репутация домена и/или IP адреса у крупных провайдеров почты — агрегированная. Проблема в одном потоке снижает доставляемость другого. Разделение доменов и субдоменов позволяет локализовать репутацию и вводить разные политики.

Базовая архитектура email-доменов и поддоменов

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

• Корневой домен: example.com — сайт, корпоративная почта сотрудников.
• Transactional: t.example.com — триггерные письма продукта.
• Marketing: m.example.com — массовые рассылки/CRM.
• Support: support.example.com или help.example.com — тикет-система/ответы.
• Отдельный bounce/return-path домен: b.example.com — для SPF-выравнивания и обработки бэунсов.

Эта декомпозиция дает автономную репутацию и разные DMARC/SPF/DKIM прописи. Вы можете повышать строгость политики на transactional (строгий alignment, p=reject), а на marketing идти по пути постепенного ужесточения (p=none → quarantine → reject) с анализом отчетов. Если поднимаете свой MTA, удобнее делать это на выделенном сервере — например, на VDS, где у вас полный контроль над PTR, HELO и IP-пулами.

SPF, DKIM, DMARC: коротко и по делу

SPF (Sender Policy Framework) подтверждает, что IP или отправляющая система вправе отправлять письма от имени домена, но проверяется по домену из SMTP MAIL FROM (envelope), который попадает в Return-Path. DKIM (DomainKeys Identified Mail) подписывает контент письма, в подписи указывается домен d=, который можно выровнять с видимым From. DMARC (Domain-based Message Authentication, Reporting, and Conformance) добавляет политику и отчеты, и требует alignment минимум одного из SPF или DKIM с доменом из заголовка From.

Alignment — это совпадение доменов. В DMARC бывает relaxed (поддомен считается выровненным с корневым) и strict (требуется точное совпадение).

Alignment в деталях

Для DMARC выравниваются:

• SPF alignment: домен из MAIL FROM (Return-Path) с доменом в заголовке From.
• DKIM alignment: домен из DKIM-подписи (d=) с доменом в From.

Режимы:

• aspf=r или adkim=r — relaxed: news.example.com выровнен с example.com.
• aspf=s или adkim=s — strict: требуется буквальное совпадение, например From: user@t.example.com и DKIM d=t.example.com.

Практика: для transactional удобно сразу ставить strict по DKIM и relaxed по SPF, а для marketing начать с relaxed и постепенно ужесточать после стабилизации метрик. Подробнее про ротацию ключей и селекторов — в статье Ротация DKIM‑селекторов: TTL, план и безболезненные переключения.

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

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

Подробнее

Return-Path, SPF и собственный bounce-домен

Письмо может иметь From: no-reply@t.example.com, но Return-Path (MAIL FROM) — другой домен, например bounce.b.example.com. Если вы пользуетесь внешним ESP/SMTP, обычно вам предложат CNAME-алиасы для собственного домена бэунсов (чтобы их система принимала NDR и генерила события). Важно, чтобы SPF для домена в Return-Path и IP отправки были согласованы, иначе SPF сгорит и alignment не состоится.

Для строгого SPF alignment в transactional-потоке:

• From: no-reply@t.example.com
• Return-Path: something@b.example.com (ваш собственный домен для бэунсов)
• SPF публикуется на b.example.com с include на провайдера и/или нужные IP
• DMARC настраивается для t.example.com с aspf=s

Если вы оставите Return-Path на чужом домене, SPF alignment с t.example.com не получится; тогда опирайтесь на DKIM alignment (для DMARC нужен хотя бы один из двух: SPF или DKIM).

DKIM: отдельные селекторы и ключи на поток

Держите DKIM-ключи per stream:

• Селекторы для transactional: s1-t, s2-t на t.example.com
• Селекторы для marketing: s1-m, s2-m на m.example.com

Рекомендации:

• Ключи 2048 бит, смена по расписанию, не реже 1–2 раз в год.
• Отдельные селекторы упрощают ротацию без даунтайма.
• DKIM d= должен совпадать с From-доменом с учетом выбранного режима alignment.
• Следите за размером DNS TXT (склейка строк по стандарту DNS допустима, это делает регистратор/панель).

DMARC: политики для корня и субдоменов

DMARC-политика публикуется в TXT по адресу _dmarc.<домен>. Можно задавать политику для субдоменов через sp=. Например, в корне example.com оставить более мягкую политику для будущих потоков, а в t.example.com — строгую. Если у вас пока нет отдельного домена под маркетинг — начните с поддомена и при необходимости оформите новый домен (см. регистрация доменов).

Старт безопасен с p=none, сбором rua-отчетов и постепенным повышением до quarantine и reject после исправления несоответствий. Подробный разбор, как читать и автоматизировать агрегированные отчеты, смотрите в материале Парсинг DMARC‑отчетов и метрики доставляемости.

Пример DNS для разделенных потоков

; Корневой домен (минимум для сайта/корп-почты, DMARC наблюдение)
example.com. 3600 IN TXT "v=spf1 a mx ~all"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; sp=quarantine; adkim=r; aspf=r; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; fo=1"

; Transactional поток
; From: *@t.example.com, Return-Path: *@b.example.com
; SPF для bounce-домена (включаем отправляющие IP/ESP записи)
b.example.com. 3600 IN TXT "v=spf1 include:_spf.txp.example.net ip4:203.0.113.10 -all"

; DMARC для t.example.com — строгий alignment и жесткая политика
t.example.com. 3600 IN TXT "v=spf1 -all" ; прямой SPF для From-домена не обязателен, но можно явно запретить
_dmarc.t.example.com. 3600 IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc-rua@t.example.com"

; DKIM селекторы для transactional
a1-t._domainkey.t.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"
a2-t._domainkey.t.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

; Marketing поток
; From: *@m.example.com, Return-Path: *@b.example.com (можно общий bounce-домен)
; SPF для marketing чаще шире из-за ESP
dmarc._report.m.example.com. 3600 IN TXT "v=DMARC1" ; служебные адреса для вендоров (пример-заглушка)
m.example.com. 3600 IN TXT "v=spf1 include:_spf.mkt.example.net ~all"
_dmarc.m.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; pct=50; rua=mailto:dmarc-rua@m.example.com"

; DKIM селекторы для marketing
s1-m._domainkey.m.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"
s2-m._domainkey.m.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

; PTR/HELO — на стороне почтового сервера. Желательно HELO/EHLO вида mail.example.com с PTR -> mail.example.com

Комментарии:

• Для transactional мы делаем упор на DKIM alignment (строгий adkim=s) и SPF alignment через собственный bounce-домен b.example.com (aspf=s в DMARC).
• Для marketing сначала оставляем relaxed alignment и мягкую политику, включаем pct=50 для частичного применения, а затем докручиваем.
• sp=quarantine в корневом DMARC — страховка для поддоменов без явной политики.

Как добиться выравнивания в реальной связке

1. Определите доменную схему: t.example.com, m.example.com, b.example.com.
2. Настройте собственный bounce/Return-Path домен. Если используете ESP, примите у них задание CNAME на их хосты для b.example.com. Проверьте, что входящие бэунсы уходят туда.
3. Опубликуйте SPF: для b.example.com (transactional SPF alignment) и для m.example.com.
4. Добавьте DKIM-ключи и подпись с d=t.example.com для transactional и d=m.example.com для marketing.
5. Включите DMARC: в корне p=none с отчетами, в t.example.com — строгая политика, в m.example.com — мягче.
6. Проверьте заголовки реальных писем: From, Return-Path, DKIM-Signature (d=), Authentication-Results (spf=pass, dkim=pass, dmarc=pass).
7. Смотрите агрегированные отчеты RUA, исправляйте несоответствия, поднимайте политику.

Где чаще всего ломается alignment

• Return-Path указывает на чужой домен ESP, а DMARC требует SPF alignment с From вашего домена. Решение: собственный bounce-домен или ставка на DKIM alignment.
• DKIM подписывает d=example.com, а From — user@t.example.com при adkim=s. Решение: подписывать d=t.example.com либо ослабить до adkim=r.
• Случайно общая подпись DKIM для разных потоков. Решение: разные селекторы/ключи per stream.
• SPF «раздулся»: больше 10 include, DNS-lookup лимит исчерпан. Решение: оптимизация и «сплющивание» записей, удаление неиспользуемых источников.
• Нет PTR или HELO не совпадает с PTR. Это не DMARC, но влияет на фильтры и оценку. Решение: согласовать hostname, PTR и HELO.
• Ответы пользователей в поддержку идут на From из transactional, а не на реальный адрес. Решение: для transactional используйте no-reply или корректный Reply-To.

Маркетинг-рассылки: особенности домена и политики

Даже при хорошей сегментации маркетинг-поток всегда шумнее: отписки, жалобы, «усталость» базы. Поэтому:

• Отдельный домен или поддомен с собственной репутацией.
• Собственный DKIM d= и отчетность DMARC на отдельные ящики.
• Постепенное повышение DMARC политики после теплого периода и стабилизации метрик доставляемости.
• Готовность откатить до p=none при сбое.
• Слежение за спам-триггерами в контенте и частотой отправки.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Transactional: приоритет надежности

Для transactional цель — идеальные метрики:

• Строгий DKIM alignment (adkim=s) и зачастую строгий SPF alignment (aspf=s) с собственным Return-Path доменом.
• Жесткая DMARC политика p=reject после верификации.
• Минимальные изменения контента и стабильные заголовки.
• Мониторинг задержек доставки и процента попаданий в «Промо» у крупных провайдеров.

Примеры проверки и отладки

Проверяйте реальные письма из ящика-получателя:

• Authentication-Results: ищем spf=pass, dkim=pass, dmarc=pass.
• DKIM-Signature: поле d= и селектор s= соответствуют домену потока и опубликованной TXT записи.
• Return-Path и From соответствуют выбранной схеме выравнивания.

Если на своей инфраструктуре, ключевой минимум для OpenDKIM:

# Генерация ключа DKIM (пример)
opendkim-genkey -s a1-t -d t.example.com
# Положить приватный ключ в конфиг и опубликовать TXT для a1-t._domainkey.t.example.com

И не забывайте привести HELO к виду, который совпадает с PTR, например mail.example.com, и прописать его в MTA.

Зрелая эволюция DMARC

Практичный маршрут:

1. Наблюдение: p=none глобально, сбор RUA, исправление источников, подключение DKIM там, где его нет.
2. Пилот: на поддомены t.example.com и m.example.com вводим собственные DMARC. Для transactional — сразу p=quarantine или даже p=reject, если все проходит. Для marketing — p=quarantine с pct=10 и постепенным ростом.
3. Продакшн: t.example.com держим p=reject, m.example.com доводим до p=reject только после длительной стабилизации.

Кейсы и компромиссы

• Только transactional: Один поддомен t.example.com, строгий alignment по DKIM и SPF, p=reject. Marketing отсутствует — проще и надежнее.
• Добавили маркетинг позже: Создайте m.example.com, отдельные DKIM, выделите поток у ESP, мягкий DMARC с постепенным ужесточением. Не меняйте схему transactional.
• Мультибренд: Используйте симметричные поддомены на каждом бренде, не смешивайте селекторы. Введите общий шаблон имен: t.brand.tld, m.brand.tld, b.brand.tld.

Чек-лист внедрения

• Разделены домены/поддомены по потокам.
• Есть собственный bounce/Return-Path домен и SPF на нем.
• DKIM подписывает d= в нужном домене, селекторы разделены, ключи 2048 бит.
• DMARC в корне и на поддоменах, для transactional — строгий, для marketing — ступенчатый.
• PTR и HELO согласованы.
• RUA отчеты читаются, алерты настроены.
• План ротации DKIM-ключей и ревизии SPF.

Безопасность и комплаенс

DKIM-приватные ключи храните ограниченно (права, аудит, шифрование на диске). Доступ к DNS минимальный и журналируемый. Избегайте утечек ключей в репозитории. При возможности включайте DNSSEC на домене и следите за валидностью записей. Для маркетинга — корректная реализация отписки, заголовок List-Unsubscribe и реакция на жалобы — это тоже вклад в репутацию домена.

Итоги

Разделение email domains на transactional и marketing, отдельный Bounce/Return-Path домен, собственные DKIM селекторы и аккуратные DMARC-политики с корректным alignment — рабочая стратегия, которая спасает доставляемость критичных писем и делает маркетинг предсказуемым. Начните с ясной схемы поддоменов, проверьте выравнивание SPF/DKIM, включите DMARC с отчетами и доведите до строгого режима там, где это оправдано. Чем раньше вы разведете потоки, тем меньше вероятность, что промо-эксперименты сорвут доставку OTP и чеков.