Как создавать кастомные правила Email Health: продвинутая конфигурация мониторинга

От стандартных к кастомным правилам Email Health#

Стандартные проверки email health валидируют базовые записи: «есть MX? есть SPF? есть DKIM?»

Но реальная email-инфраструктура нюансированнее:

• Вы используете 5 разных email-сервисов (SendGrid, Google Workspace, Mailgun, Zoho, Amazon SES)
• Каждому нужны SPF-includes
• У вас несколько DKIM-селекторов (по одному на сервис)
• Вы мигрируете email-провайдера (старый DKIM-селектор всё ещё там, новый ставится)
• Вы внедряете строгую DMARC-политику (p=reject), но нужно не сломать легитимную почту

Стандартные проверки — pass/fail. Кастомные правила обрабатывают сложность.

Этот гайд покажет, как настроить продвинутые правила email health для сложной инфраструктуры.

Кастомное правило №1: Multi-Selector DKIM#

Если у вас несколько email-сервисов — у вас несколько DKIM-селекторов.

Проблема

Сценарий: SendGrid для транзакционных, Mailgun для маркетинговых писем.

DNS-конфигурация:

s1._domainkey.yourdomain.com → DKIM-ключ SendGrid
s2._domainkey.yourdomain.com → DKIM-ключ Mailgun

Стандартный мониторинг говорит «DKIM настроен» (pass), но не проверяет:

• Что оба селектора активны
• Что у обоих валидные ключи
• Что оба правильно ротируются

Решение: кастомное правило

Создать правило: «Алерт, если DKIM-селектор отсутствует»

Имя правила: DKIM Redundancy Check
Условие: s1._domainkey должен существовать И s2._domainkey должен существовать
Алерт если: один из селекторов отсутствует
Severity: Warning (не critical)
Уведомление: «DKIM redundancy compromised. Selector SendGrid отсутствует.»

Реализация (если поддерживается Nova Uptime):

curl -X POST https://api.novauptime.com/api/v1/domains/yourdomain.com/rules \
  -H "X-API-Key: your-key" \
  -d '{
    "name": "DKIM Redundancy",
    "type": "dkim_selector_count",
    "condition": {
      "minSelectors": 2,
      "requiredSelectors": ["s1", "s2"]
    },
    "alert": {
      "threshold": "below",
      "severity": "warning"
    }
  }'

Кастомное правило №2: мониторинг лимита SPF lookups#

У SPF лимит 10 DNS-запросов (RFC 7208). Превысите 10 — SPF-аутентификация молча сбоит.

Проблема

Ваша SPF-запись:

v=spf1 \
  include:sendgrid.net \
  include:mailgun.org \
  include:_spf.google.com \
  include:amazonses.com \
  include:mailchimp.org \
  include:zoho.com \
  include:github.com \
  include:discourse.org \
  ip4:192.0.2.1 \
  -all

Каждая директива include: использует 1 DNS-запрос:

• sendgrid.net: 1
• mailgun.org: 1
• _spf.google.com: 1
• amazonses.com: 1
• mailchimp.org: 1
• zoho.com: 1
• github.com: 1
• discourse.org: 1
• ip4: 0 (прямой IP, без DNS)

Итого: 8 запросов (под лимитом, всё ок)

Но что, если добавить ещё один сервис?

Решение: кастомное правило

Создать правило: «Алерт, если SPF-запросы приближаются к лимиту»

Имя правила: SPF Lookup Limit
Условие: Считать DNS-запросы в SPF-записи
Алерт если: запросы > 8 (буфер 2 запроса)
Severity: Warning
Рекомендация: консолидировать SPF-includes или использовать SPF flattening сервис

Почему это важно:

• Стандартный мониторинг: SPF настроен ✅
• Кастомное правило: SPF настроен, НО приближается к лимиту запросов ⚠️

Кастомное правило ловит проблему, которую пропускает стандартный мониторинг.

Кастомное правило №3: мониторинг DMARC-отчётов#

DMARC присылает отчёты, показывающие, сколько писем не прошли аутентификацию. Эти отчёты надо мониторить.

Проблема

Ваша политика DMARC:

_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"

DMARC шлёт ежедневные отчёты на dmarc@yourdomain.com. Они показывают:

• % писем, прошедших SPF
• % писем, прошедших DKIM
• % писем, не прошедших оба (попытки спуфинга)

Если вы их не смотрите — упускаете инсайты безопасности.

Решение: кастомное правило

Создать правило: «Алерт при необычной доле сбоев в DMARC-отчёте»

Имя правила: DMARC Failure Rate Monitoring
Проверка: ежедневное получение DMARC-отчётов
Алерт если: доля сбоев легитимной почты > 1% (намёк на проблему SPF/DKIM)
Алерт если: попытки спуфинга > 5% (домен таргетируют)
Severity: Warning при сбоях, Critical при высокой доле спуфинга

Пример алерта:

⚠️ DMARC Alert: обнаружена необычная активность
Domain: yourdomain.com
Дата отчёта: 20 фев 2026

Сбои легитимной почты: 12% (норма: <1%)
Вероятная причина: добавлен новый email-сервис без SPF/DKIM
Действие: проверить корректность ротации DKIM SendGrid

Попытки спуфинга: 2% (норма: <0.1%)
Вероятная причина: домен используется в фишинговых кампаниях
Действие: проверить DMARC-политику (сейчас p=reject, хорошо)

Кастомное правило №4: workflow ротации email-сервисов#

Когда мигрируете с одного сервиса на другой, нужен временный период, когда DKIM-селекторы обоих сосуществуют.

Проблема

Сценарий: миграция с SendGrid на Mailgun.

Старое состояние (до миграции):

s1._domainkey (SendGrid DKIM)

Переходное (во время миграции):

s1._domainkey (SendGrid DKIM) ← старый сервис, выводится
s2._domainkey (Mailgun DKIM) ← новый сервис

В этот период:

• В SPF включены оба сервиса
• Существуют оба DKIM-селектора
• Письма из обоих сервисов проходят аутентификацию

Новое состояние (после cutover):

s1._domainkey (SendGrid DKIM) ← удалить
s2._domainkey (Mailgun DKIM)

Если после cutover забыли удалить старый DKIM-селектор — конфигурация дрейфует.

Решение: кастомное правило

Создать правило: «Алерт после дедлайна миграции»

Имя правила: SendGrid DKIM Removal Deadline
Тип: Migration Tracking
Дата старта: 15 фев 2026 (старт миграции)
Ожидаемый cutover: 22 фев 2026
Алерт если: SendGrid DKIM всё ещё присутствует после 25 фев 2026
Severity: Warning
Сообщение: «Селектор SendGrid DKIM (s1) должен был быть удалён 3 дня назад»

Кастомное правило №5: workflow эволюции DMARC#

Компании часто эволюционируют DMARC-политику со временем:

1. День 1: p=none (без enforcement, только мониторинг)
2. Неделя 2: p=quarantine (сбои в спам, не reject)
3. Месяц 2: p=reject (отклонение сбоев, строгий enforcement)

Эта эволюция позволяет мониторить влияние перед строгостью.

Проблема

Планируете перейти с p=quarantine на p=reject. Нужно убедиться, что всё работает, до жёсткой линии.

Решение: кастомное правило

Создать правило: «Алерт при изменении политики DMARC»

Имя правила: DMARC Policy Evolution Tracking
Фаза 1 (1 фев): развёртывание p=quarantine
  Веха: мониторинг 2 недели
  Алерт если: доля сбоев легитимной почты > 1% (проблемы SPF/DKIM)

Фаза 2 (15 фев): переход на p=reject
  Предусловие: подтвердить отсутствие легитимных сбоев в фазе 1
  Алерт если: не все предусловия выполнены

Фаза 3 (1 мар): проверка адопции
  Алерт если: обнаружены попытки спуфинга (значит reject работает)

Кастомное правило №6: верификация сторонних email-сервисов#

Вы аутсорсите отправку писем сервисам вроде Twilio, SendGrid, Mailgun. Нужно убедиться, что они правильно настроены.

Проблема

SendGrid обещает: «Будем слать письма с вашего домена с правильным SPF/DKIM».

Но что, если они ошиблись на своей стороне? Или обновили DNS и забыли вам сказать?

Решение: кастомное правило

Создать правило: «Проверять, что сторонние email-сервисы правильно аутентифицированы»

Имя правила: SendGrid Configuration Verification
Проверка: DKIM-ключ SendGrid совпадает с DNS-записью
Проверка: SPF-include SendGrid в вашей SPF-записи
Проверка: domain authentication SendGrid в статусе «verified» (не pending)
Алерт если: любая проверка сбоит
Severity: Critical
Действие: «Связаться с саппортом SendGrid. Domain auth, возможно, истекла».

Кастомное правило №7: сравнение с baseline email health#

Email health меняется. Хотите знать, когда что-то изменилось относительно baseline.

Проблема

В прошлом месяце оценка email health была 92. В этом — 88. Что-то сломалось?

Стандартный мониторинг алертит на абсолютные оценки. Кастомные правила алертят на изменения.

Решение: кастомное правило

Создать правило: «Алерт на значимое изменение от baseline»

Имя правила: Email Health Regression Detection
Baseline: оценка 1 фев (92/100)
Порог: алерт, если оценка падает >5 пунктов
Алерт если: текущая оценка < 87
Severity: Warning
Сообщение: «Email health упало с 92 до 88 (вероятная причина: ротация DKIM-ключа)»

Кастомное правило №8: правила compliance-аудита#

Если вы регулируемы (HIPAA, SOC2, PCI-DSS), нужны конкретные конфигурации.

Пример: compliance в здравоохранении#

Требования:

• DMARC p=reject (строгий enforcement)
• SPF -all (без soft fails)
• DKIM на основном и резервном домене
• TLS для всей исходящей почты
• Шифрование email для чувствительных данных

Кастомное правило:

Имя правила: HIPAA Email Compliance Check
Требование 1: DMARC-политика должна быть p=reject
  Алерт если: политика p=quarantine или p=none

Требование 2: SPF должен заканчиваться на -all
  Алерт если: SPF заканчивается на ~all (soft fail)

Требование 3: должен быть DKIM на резервном домене
  Алерт если: на резервном домене нет DKIM

Требование 4: TLS обязателен для всей почты
  Алерт если: не-TLS письмо из системы

Требование 5: чувствительные письма должны использовать шифрование
  Алерт если: письмо с PII не использует S/MIME или PGP

Внедрение кастомных правил на практике

Вариант 1: встроенные правила инструмента#

Если ваш инструмент (вроде Nova Uptime) поддерживает кастомные правила — используйте дашборд:

1. Заходите в настройки домена
2. Жмёте «Custom Rules»
3. Выбираете тип правила (количество SPF-запросов, DKIM-селектор и т. д.)
4. Ставите пороги
5. Настраиваете алерты
6. Сохраняете

Вариант 2: webhook'и в кастомную систему#

Если ваш инструмент не поддерживает — используйте webhook'и:

# Инструмент мониторинга шлёт webhook:
POST /your-system/webhooks/email-health
{
  "domain": "yourdomain.com",
  "email_health": {
    "score": 88,
    "spf_lookups": 9,
    "dkim_selectors": 2,
    "dmarc_policy": "reject",
    "blacklist_status": "clean"
  }
}

# Ваша система оценивает правила:
if (email_health.spf_lookups > 9) {
  alert("SPF lookup limit approaching");
}
if (email_health.dmarc_policy !== "reject") {
  alert("DMARC policy not strict");
}

Вариант 3: ручной ежемесячный аудит#

Если ни один из вариантов выше недоступен:

1. Экспортируйте данные email health из инструмента мониторинга
2. Создайте таблицу с кастомными колонками
3. Ежемесячно сверяйте с требованиями
4. Уведомляйте команду, если что-то изменилось

Частые ошибки в кастомных правилах

Ошибка 1: слишком много кастомных правил#

Проблема: создаёте 50 кастомных правил, тонете в алертах, игнорируете все.

Решение: начните с 3–5 критичных. Добавляйте по мере необходимости.

Ошибка 2: правила без action items#

Проблема: «Алерт, если SPF lookups > 8» сработал, но команда не знает, что делать.

Решение: каждое правило должно содержать action items:

Если: SPF lookups > 8
Текст алерта: «Приближаемся к лимиту SPF lookups.
Как починить: консолидировать includes через SPF flattening сервис.
Подробнее: https://knowledge.spf-flattening.com»

Ошибка 3: не тестируете правила#

Проблема: настроили кастомное правило 6 месяцев назад. Ни разу не проверили, что оно реально срабатывает.

Решение: тестируйте правила раз в квартал:

1. Намеренно триггерьте условие (например, вручную добавьте лишний SPF-include)
2. Ждите алерта
3. Убедитесь, что алерт корректен
4. Уберите тестовый триггер

Ошибка 4: правила отстают от реальности#

Проблема: настроили DMARC evolution rule в феврале. Забыли обновить. Сейчас июнь, правило устарело.

Решение: пересматривайте кастомные правила раз в квартал. Обновляйте, если потребности бизнеса изменились.

Резюме: чек-лист кастомных правил Email Health#

• ✅ Идентифицировать вашу email-инфраструктуру (сколько сервисов? селекторов?)
• ✅ Настроить правило DKIM redundancy (несколько селекторов)
• ✅ Настроить правило лимита SPF lookups (предупреждение на 8 запросах)
• ✅ Настроить правило мониторинга DMARC-отчётов (необычные доли сбоев)
• ✅ Настроить правила миграции email-сервиса (если мигрируете провайдера)
• ✅ Настроить правила эволюции DMARC (если постепенно ужесточаете политику)
• ✅ Настроить правила compliance (если регулируемая отрасль)
• ✅ Протестировать каждое правило, что оно работает
• ✅ Зафиксировать правила для команды
• ✅ Квартальный аудит и обновление

Начните сегодня

Стандартный мониторинг email health — хорошо. Кастомные правила делают его отличным.

Если используете Nova Uptime — зайдите в настройки домена и создайте кастомные правила под свою инфраструктуру. Если ваш инструмент пока не поддерживает кастомные правила — используйте webhook'и или ручные аудиты.

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