DMARC “не сломал” рассылки: как Aviasales перевела домены в p=quarantine без падения выручки и жалоб

DMARC “не сломал” рассылки: как Aviasales перевела домены в p=quarantine без падения выручки и жалоб

В 2026 году “прогрев” уже не воспринимается как разогрев недельной важности. В B2C и особенно в travel ценность — в предсказуемой доставляемости и стабильной доле распознанных писем, потому что retention и LTV (возврат и суммарная ценность) важнее, чем одноразовый всплеск первой покупки.

Контекст
Aviasales — компания с большим числом доменов под разные продуктовые линии и партнёрские интеграции. Как обычно, часть потока уходила через внешние сервисы (ESP), часть — через внутренние шаблоны, часть — через интеграции “на событии” (триггеры по поиску/бронь-событиям). Риски для доставки:
— отклонения SPF/DKIM по некоторым доменам
— рост доли “серых” маршрутов (forwarding, списки рассылки, межсистемные пересылки)
— усиление требований почтовиков к аутентификации (DMARC policy становится не рекомендацией, а фильтром)

Задача
Перевести домены в более жёсткую политику DMARC (цель: защититься от подмены и повысить долю pass), не допустив:
— падения inbox rate (доставки в “входящие”)
— всплеска жалоб (complaints)
— “тихой” деградации — когда письма продолжают уходить, но пользователь видит меньше писем из-за фильтрации

Решение (что сделали по этапам)
1) Сняли реальную картину аутентификационных источников
— собрали все отправляющие IP/хосты и идентификаторы, включая “сквозные” сервисы
— сопоставили From-domain с фактическим отправителем (берём только факты из логов и отчётов)
— настроили сбор DMARC aggregate reports и сопоставили “кто проходит/кто падает” по доменам

2) Разнесли управление по доменам и подсетям
Вместо “включим везде сразу” сделали управляемый план:
— основной домен оставили в режимах наблюдения, для части доменов подняли чувствительность политики
— для доменов, где были сомнительные маршруты, сначала починили SPF/DKIM, а потом только меняли DMARC

3) Включили атаку на причину, а не на симптом
Проблема обычно не в том, что “DMARC плохой”. Проблема в том, что реальные отправители не подписывают DKIM/SPF согласованно с From. Поэтому:
— привели DKIM селекторы к стабильному набору для каждого ESP/интеграции
— выровняли SPF: убрали “лишние” include там, где они больше не использовались, и добавили только фактические отправители
— там, где невозможно было добиться 100% согласованности, добавили коррекцию через алиасинг/настройки пересылки (чтобы pass считался корректно, а не “потому что повезло”)

4) Сначала использовали мониторинг, затем quarantine
DMARC подняли не одним щелчком. По внутренней логике компании этап выглядел так:
— период мониторинга: собираем отчёты, ловим “непривязанные” маршруты
— затем p=quarantine на доменах с подтверждённым соответствием (alignment)
— параллельно ужесточили контроль: ошибки в DKIM/списках отправителей перестали проходить как “фоновые”

Результат
После перехода в p=quarantine не было “обнуления” рассылок — ключевые метрики остались в рабочем коридоре за счёт того, что исправляли причины, а не гасили последствия:
— доля писем, проходящих DMARC (pass), выросла на **15–20%** на доменах, где до этого были разъезды по DKIM/SPF
— жалобы (complaints) не ушли вверх: рост был статистически незначимым, за счёт очистки маршрутов и стабильного signing
— inbox rate сохранился, потому что политика вводилась только там, где согласованность фактически подтверждалась отчётами

Локально “провисания” были, но их отлавливали на этапе мониторинга: несколько сегментов, которые уходили через старый связанный маршрут, сначала стали fail, их быстро откатили/переподключили, после чего возвращение в quarantine прошло чисто.
…