Настройка сети DNS: база для стабильной работы бизнес-почты

Параллельно в логах Postfix фиксировались отказы SPF: домен отправителя не публиковал политику авторизации, и принимающая сторона применяла жесткую reject-директиву. Два фактора, один источник — DNS. Корректная настройка сети DNS закрывает обе проблемы: маршрутизация входящей корреспонденции и подлинность исходящих сообщений опираются на одни и те же TXT- и MX-записи в зоне домена.

Без рабочего DNS-фундамента бизнес-почта превращается в черный ящик. MX указывает на недоступный хост — входящие теряются. SPF не описывает пул отправителей — письма летят в спам. DKIM-ключ отсутствует — принимающая сторона не может криптографически подтвердить целостность заголовков. DMARC не задан — домен остается открытым для спуфинга. Каждый из этих векторов управляется через DNS, и ошибка на любом этапе конфигурации немедленно проявляется в метриках доставляемости.

Маршрутизация входящей почты через MX-записи: приоритеты и отказоустойчивость

MX-запись (Mail Exchange) — единственная DNS-инструкция, определяющая, какие MTA принимают почту для домена. Запись содержит два поля: числовой приоритет и имя хоста. Приоритет работает по принципу обратной сортировки: меньшее значение предпочтительнее. Сервер с приоритетом 10 принимает корреспонденцию первым, сервер с приоритетом 20 — резервным, активируется при недоступности основного.

Минимальная рабочая конфигурация включает одну MX-запись. Отказоустойчивая — минимум две, на разных IP-подсетях и, в идеале, у разных провайдеров. Пример для зоны example.com:

MX-запись должна указывать на A или AAAA-запись, не на CNAME. RFC 1035 прямо запрещает цепочку CNAME в зонах с MX — большинство публичных резолверов возвращают SERVFAIL при попытке разрешить такой домен. Проверьте разрешимость цепочки заранее: dig MX example.com +short, затем dig A mx1.example.com +short для каждого хоста.

Резервный MX не обязан находиться в той же автономной системе. Распределение по разным площадкам снижает риск одновременного отказа при инциденте у одного хостера. При этом backup-MX без антиспам-фильтрации — уязвимость: он принимает корреспонденцию, которую основной сервер мог бы отклонить на этапе SMTP-сессии. Контролируйте содержимое очереди резервного узла и не держите на нем нефильтрованный поток дольше, чем позволяет SLA восстановления основного.

MX отвечает только за входящую корреспонденцию. Исходящая маршрутизация определяется локальной конфигурацией MTA и SPF, а не MX.

Авторизация отправителя по стандарту RFC 7208: настройка SPF-записей

SPF (Sender Policy Framework) описан в RFC 7208 и публикуется как TXT-запись в зоне домена. Запись содержит директивы, определяющие, каким узлам разрешено отправлять почту с обратным адресом в данном домене. Синтаксис: v=spf1 плюс набор механизмов и модификаторов.

Базовые механизмы:

• ip4: и ip6: — разрешение конкретных адресов или подсетей.
• a и mx — автоматическое включение адресов из A/AAAA и MX-записей домена.
• include: — подключение политики другого домена (используется для сторонних ESP).
• all — завершающий модификатор с префиксом: +all (разрешить всё, недопустимо для продакшена), -all (жёсткий запрет), ~all (мягкий отказ), ?all (нейтральная позиция).

Рабочая политика для домена, отправляющего через собственный MTA и Google Workspace:

example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Ошибки конфигурации, которые встречаются регулярно:

• Более 10 DNS-обращений при раскрытии include-цепочек — RFC 7208 устанавливает лимит в 10 lookup. Превышение приводит к результату permerror, и принимающая сторона обязана трактовать его как fail. Подсчитайте глубину: каждый include, a, mx, ptr, exists, redirect считается за одно обращение.
• Отсутствие терминатора -all или ~all. Без завершающего модификатора нейтральная позиция по умолчанию фактически разрешает отправку с любого IP.
• Дублирование SPF-записей в одной зоне. RFC устанавливает: один домен — одна SPF-запись. Несколько TXT-записей с v=spf1 вызывают permerror у строгих резолверов. Проверьте: dig TXT example.com | grep spf должен вернуть ровно одну строку.

SPF защищает envelope-from (MAIL FROM), а не заголовок From. Это разные доменные имена, и подделка только одного из них обходит проверку.

Криптографическая подпись DKIM: размещение публичных ключей в DNS

DKIM добавляет цифровую подпись в заголовки исходящих писем. Подпись формируется закрытым ключом на стороне MTA, проверяется открытым ключом, который публикуется в DNS как TXT-запись по селектору. Стандарт описан в RFC 6376, расширения — в RFC 8301 и RFC 8463.

Структура записи: <selector>._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=<base64-ключ>". Селектор позволяет ротировать ключи без простоя: новая пара генерируется, публикуется под новым селектором, MTA переключается, старый ключ остается в DNS до истечения периода хранения у получателей.

Процедура генерации и публикации:

1. Сгенерируйте RSA-пару длиной не менее 2048 бит. ECDSA допустим, но поддерживается не всеми ESP и MTA на принимающей стороне.

2. Опубликуйте открытый ключ в TXT-записи селектора. Пример для селектора mail:

mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

3. Настройте подписывающий агент (OpenDKIM, dkimpy, встроенные средства Postfix через milter) на использование закрытого ключа и селектора.

4. Проверьте подпись на исходящем письме: заголовок DKIM-Signature должен присутствовать, проверка через dkimverify или online-сервисы должна возвращать pass.

Распространенная ошибка — публикация ключа с устаревшим параметром k=rsa-sha1. SHA-1 снят с поддержки большинством крупных провайдеров. Используйте sha256 (по умолчанию в современных реализациях) или явно указывайте в подписи через h= механизм.

Длина ключа влияет на размер DNS-ответа. 2048-битный RSA в base64 превышает 255 байт — запись разбивается на несколько строковых сегментов в кавычках. Проверьте длину через dig TXT и убедитесь, что резолвер корректно собирает фрагменты.

Политики DMARC: связка SPF и DKIM для защиты доменного имени

DMARC (Domain-based Message Authentication, Reporting, and Conformance) описан в RFC 7489. Запись публикуется в TXT на хосте _dmarc и связывает результаты проверок SPF и DKIM с доменным именем в поле From. Без DMARC подмена заголовка From остается неконтролируемой: SPF и DKIM могут пройти на техническом домене, но визуально получатель видит поддельный адрес.

Запись имеет три ключевых тега:

• v=DMARC1 — версия протокола.
• p= — политика для домена: none (только отчёты), quarantine (помещать в спам), reject (отклонять на SMTP-уровне).
• rua= и ruf= — URI для агрегированных и криминалистических отчётов соответственно.

Поэтапное внедрение:

1. Опубликуйте запись с p=none и подключите приём отчётов на собственный почтовый ящик или специализированный сервис. Период наблюдения — минимум две недели.

2. Проанализируйте отчёты: какие легитимные источники не проходят SPF/DKIM. Устраните расхождения.

3. Переведите политику на p=quarantine. Контролируйте поток ложных срабатываний.

4. Перейдите на p=reject после подтверждения стабильности. Жёсткий отказ снижает процент фишинга, использующего ваш домен, до статистической погрешности.

Пример записи:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; fo=1; aspf=s; adkim=s"

Параметры aspf и adkim определяют режим выравнивания: s — strict (требуется точное совпадение доменов), r — relaxed (допускается совпадение поддоменов). Strict рекомендуется для продакшена.

DMARC работает только при корректной связке: SPF или DKIM должны пройти проверку на домене, выровненном с From. Изолированная запись без рабочего SPF/DKIM бесполезна.

Управление TTL и планирование миграции почтовых серверов

TTL (Time To Live) определяет время кэширования DNS-записи на резолверах. Значение задается в секундах в самой записи. При миграции почтовых серверов параметр критичен: высокий TTL на старой MX-записи приведет к тому, что часть отправителей продолжит разрешать домен по устаревшему адресу в течение всего периода кэширования.

Стандартная процедура смены MX:

1. За 24–48 часов до переключения снизьте TTL на текущей MX-записи до 300–900 секунд. Это ускорит распространение изменений по кэшам публичных резолверов.

2. Подготовьте новую MX-запись. Не публикуйте до момента переключения — преждевременная публикация активирует резолверы с коротким TTL раньше срока.

3. В момент миграции опубликуйте новую запись с приоритетом 10. Старую оставьте с приоритетом 20 на период до 48 часов. Это обеспечивает плавный переход: новые запросы идут на новый сервер, устаревшие кэши — на старый, но через fallback на резервную запись.

4. Через 48 часов удалите старую MX-запись. Верните TTL на рабочее значение (обычно 3600–14400 секунд).

Игнорирование TTL приводит к характерному симптому: часть корреспонденции продолжает поступать на старый сервер в течение 24–48 часов после миграции, несмотря на корректную публикацию новой записи. Это не ошибка DNS, а штатное поведение кэширования.

Отдельные резолверы игнорируют стандартный TTL и применяют собственные политики удержания записей. Точные сроки обновления кэша для каждого публичного резолвера не документированы — закладывайте максимальное окно в 48 часов при планировании даунтайма.

Миграция без снижения TTL — операция с непредсказуемым результатом. Часть сессий потеряется, часть задержится на часы. Снижение TTL — управляемый параметр, пренебрегать им нельзя.

Контрольный алгоритм диагностики DNS для почты

При сбоях доставки отправляйте запросы в строгой последовательности. Хаотичная проверка записей не выявит корневую причину.

1. dig MX example.com +short — проверьте MX-записи. Убедитесь в наличии и разрешимости хостов.

2. dig A mx1.example.com +short — подтвердите A-запись для каждого MX-хоста.

3. dig TXT example.com +short — извлеките SPF. Подсчитайте длину и количество lookup-операций.

4. dig TXT mail._domainkey.example.com +short — проверьте DKIM-ключ для каждого активного селектора.

5. dig TXT _dmarc.example.com +short — подтвердите DMARC-политику.

6. nslookup -type=mx example.com 8.8.8.8 — повторите проверки через публичный резолвер. Расхождения между авторитативным и публичным ответом указывают на проблемы кэширования или DNSSEC.

7. Отправьте тестовое письмо на внешний ящик (Gmail, Outlook.com) и проанализируйте заголовки Authentication-Results. Записи spf=pass, dkim=pass, dmarc=pass — обязательный минимум для продакшена.

Ошибка в одной записи каскадно влияет на остальные. Отсутствующая SPF ломает выравнивание DMARC. Невалидный DKIM-ключ исключает второй путь аутентификации. Неразрешимый MX-хост блокирует входящую маршрутизацию. Диагностируйте послойно: сначала MX, затем авторизация, затем политика.