Настройка DNS-сервера для почты: пошаговый гайд

Не завершена. MX отвечает за маршрут входящей почты. SPF ограничивает разрешённых отправителей. DKIM подписывает сообщение. DMARC задаёт политику обработки поддельных писем. PTR связывает IP с именем MTA. Если хотя бы один слой отсутствует или противоречит остальным, домен теряет доставляемость и становится пригодным для спуфинга.

Базовая схема: какие DNS-записи нужны почтовому домену

Для рабочего почтового домена требуется не одна запись. Нужен согласованный набор. DNS должен отвечать на три вопроса:

1. Куда доставлять входящую почту для домена.

2. Кто имеет право отправлять почту от имени домена.

3. Как получатель должен обрабатывать сообщения, которые не прошли проверку.

Минимальный набор записей выглядит так:

Записи DNS почтового сервера не работают изолированно. MX может быть правильным, но исходящие письма будут отклоняться из-за пустого PTR. SPF может быть строгим, но бесполезным без DKIM при пересылках. DMARC может стоять в reject, но ломать легитимные рассылки, если не настроено выравнивание доменов.

Почтовый DNS — это не список записей. Это цепочка доказательств: маршрут, право отправки, подпись, политика.

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

Порядок работ:

1. Определите авторитетные NS для домена.

2. Проверьте текущие MX, A, TXT и CNAME.

3. Снизьте TTL перед миграцией или крупным изменением.

4. Настройте A/AAAA для имени почтового сервера.

5. Настройте MX на FQDN.

6. Настройте PTR у владельца IP.

7. Опубликуйте SPF.

8. Включите DKIM на MTA или у почтового провайдера.

9. Опубликуйте DMARC сначала в режиме мониторинга.

10. Проверьте прохождение SPF, DKIM, DMARC на реальной отправке.

Маршрутизация почты: MX, A и приоритеты

MX-запись сообщает внешним серверам, какой хост принимает почту для домена. Значение MX должно быть доменным именем. Не IP-адресом. Не URL. Не именем с протоколом. Только FQDN.

Корректная логика:

• домен example.com имеет MX 10 mail.example.com;
• имя mail.example.com имеет A-запись на публичный IPv4;
• если используется IPv6, есть AAAA-запись;
• MTA на этом адресе принимает SMTP на 25/TCP;
• имя в MX резолвится стабильно и не указывает на временный адрес.

Приоритет MX задаётся числом. Меньше число — выше приоритет. Диапазон технически широкий, часто используют значения вроде 10, 20, 30. Это удобно: между ними можно добавить новый сервер без пересборки всей схемы.

Пример рабочей модели:

Резервный MX не должен быть декоративным. Если он принимает почту, он обязан фильтровать спам, проверять получателей и корректно передавать сообщения на основной сервер. Иначе он станет обходным каналом. Спамеры проверяют MX с более низким приоритетом и отправляют туда, где меньше защиты.

Отдельно проверьте wildcard-записи. Они могут неожиданно резолвить несуществующие имена. Для почты это вредно. Если MX указывает на опечатанное имя, wildcard может скрыть ошибку: имя будет резолвиться, но SMTP окажется не там.

Типовые ошибки MX:

1. MX указывает на IP-адрес. Так делать нельзя. MX должен ссылаться на имя. Для IP используйте A/AAAA у этого имени.

2. MX указывает на CNAME. На практике это часто работает, но для почтовой инфраструктуры лучше не строить MX через CNAME. Держите прямой FQDN с A/AAAA.

3. Нет A-записи у MX-хоста. Внешний MTA получает маршрут, но не может получить адрес.

4. Одинаковые приоритеты без понимания балансировки. Если два MX имеют одинаковый приоритет, отправители могут распределять доставку между ними. Оба сервера должны быть равноценны.

5. Резервный MX принимает всё. Так создают backscatter и обход антиспама.

Если домен использует сторонний почтовый сервис, не смешивайте его MX со своим сервером без проектирования маршрута. Два разных провайдера в MX не означают отказоустойчивость. Часто это означает разрыв почтовых ящиков: часть писем уйдёт в одну систему, часть — в другую.

Идентификация отправителя: SPF и PTR

SPF публикуется как TXT-запись. Он определяет, какие IP-адреса или домены имеют право отправлять почту от имени домена. Получатель берёт домен из envelope sender, запрашивает SPF и проверяет IP подключившегося SMTP-сервера.

Простая запись SPF для одного сервера обычно выглядит концептуально так: версия SPF, разрешённый IP или MX, затем финальный механизм. В DNS это TXT у корня домена.

Логика выбора финального механизма:

+all равен отказу от SPF. Такая запись сообщает получателям, что любой IP может отправлять почту от имени домена. Для рабочего домена это дефект конфигурации.

Перед публикацией SPF перечислите все источники исходящей почты:

• основной MTA организации;
• резервный MTA, если он отправляет;
• почтовый провайдер;
• CRM, helpdesk, billing-система;
• сервис рассылок;
• сайт, который отправляет транзакционные письма;
• облачные функции и приложения, если они отправляют напрямую.

Не добавляйте в SPF всё подряд. Каждый include расширяет доверенную поверхность. У SPF есть ограничение по DNS-lookup. При сложной записи с большим количеством include можно получить PermError. Тогда SPF перестанет выполнять свою функцию.

PTR — другой слой. Он не публикуется в зоне домена обычным администратором, если IP принадлежит провайдеру. PTR настраивается в reverse DNS-зоне у владельца адресного блока: хостера, ISP, облачного провайдера. Для почтового сервера PTR обязателен.

Схема должна быть симметричной:

1. mail.example.com указывает A-записью на IP MTA.

2. PTR для этого IP указывает обратно на mail.example.com.

3. MTA использует это имя в HELO/EHLO.

4. Имя резолвится вперёд в тот же IP.

Отсутствие PTR — частая причина блокировки. Несовпадающий PTR — такая же причина. Особенно для новых IP, VPS и облачных адресов. Получатель видит SMTP-соединение от адреса, который не имеет обратного имени или имеет generic PTR вида vps-123-45.provider.tld. Для антиспама это плохой сигнал.

SPF говорит, кто имеет право отправлять. PTR говорит, что сервер не прячется за случайным адресом.

Не используйте один IP для разных почтовых доменов без контроля HELO, SPF, DKIM и репутации. Технически это возможно. Операционно — риск. Один скомпрометированный домен портит репутацию общего исходящего адреса.

DKIM: подпись, селекторы и проверка целостности

DKIM добавляет цифровую подпись к заголовкам письма. Получатель берёт селектор и домен из DKIM-Signature, запрашивает публичный ключ в DNS и проверяет, что сообщение не изменено после подписи.

DKIM не заменяет SPF. Это другой механизм. SPF привязан к IP отправителя. DKIM привязан к подписи домена. При пересылке SPF часто ломается, потому что письмо приходит с нового IP. DKIM при корректной пересылке может сохраниться. Поэтому для DMARC нужен хотя бы один проходящий механизм с выравниванием домена.

Селектор — это имя ключа. Например, если селектор s1, публичный ключ публикуется в TXT-записи вида s1._domainkey.example.com. В самой записи хранится версия DKIM, тип ключа и публичный ключ. Закрытый ключ остаётся на стороне MTA или почтового сервиса. Не публикуйте закрытый ключ. Не пересылайте его в тикетах. Не храните его в общей документации без контроля доступа.

Рабочая процедура внедрения DKIM:

1. Сгенерируйте ключ на MTA или в панели почтового провайдера.

2. Выберите селектор. Не используйте одинаковый селектор для разных платформ, если они не используют один и тот же ключ.

3. Опубликуйте TXT-запись селектора в DNS.

4. Дождитесь ответа авторитетных NS.

5. Включите подпись исходящих писем.

6. Отправьте тестовое письмо на внешний ящик.

7. Проверьте заголовки: должен быть dkim=pass.

8. Проверьте доменное выравнивание для DMARC.

Ротация ключей должна быть плановой. Используйте два селектора: текущий и следующий. Сначала публикуйте новый публичный ключ. Затем переключайте подпись на новый селектор. После завершения периода доставки и кэширования удаляйте старый. Не удаляйте старую TXT-запись сразу после переключения: письма, уже находящиеся в очередях, ещё могут проверяться по старому селектору.

Типовые ошибки DKIM:

• TXT-запись разбита панелью DNS некорректно;
• селектор в DNS не совпадает с селектором в заголовке;
• подпись включена только для части исходящих потоков;
• промежуточный шлюз меняет тело письма после подписи;
• footer, disclaimer или антивирусный шлюз модифицирует сообщение;
• используется домен подписи, не выровненный с From.

Если корпоративный шлюз добавляет юридический дисклеймер уже после DKIM-подписи, подпись может стать недействительной. Правильный порядок: сформировать письмо, внести все изменения, затем подписать DKIM на последнем исходящем узле перед интернетом. Либо исключить модификацию подписанных частей. В реальной почтовой инфраструктуре это не косметика, а причина массовых dkim=fail.

DMARC: политика для домена, а не декоративная TXT-запись

DMARC использует результаты SPF и DKIM. Он проверяет не только факт прохождения, но и выравнивание доменов с видимым полем From. Это принципиально. Письмо может пройти SPF по домену технического отправителя, но не пройти DMARC, если From показывает другой домен.

Политики DMARC:

Начинайте с none, если домен ранее не контролировался. Но не оставляйте none навсегда. Это режим наблюдения, а не защита. Его задача — показать, кто отправляет от имени домена и какие потоки ломаются.

Порядок перехода к enforcement:

1. Опубликуйте DMARC с p=none.

2. Соберите отчёты и выявите все легитимные источники.

3. Исправьте SPF и DKIM для каждого источника.

4. Проверьте alignment для From.

5. Переведите часть домена на quarantine, если используется pct.

6. После стабилизации включите reject.

Для домена, который не отправляет почту, DMARC тоже нужен. Конфигурация должна запрещать использование домена в From. Такой домен обычно получает SPF с запретом отправки и DMARC с reject. Иначе его можно использовать для спуфинга, даже если на нём нет почтовых ящиков.

Отдельно настройте политику поддоменов. Если основной домен защищён, а поддомены оставлены без политики, злоумышленник может использовать anything.example.com. Для этого в DMARC есть параметр политики поддоменов. Не оставляйте его без внимания при крупной доменной зоне.

DMARC не исправляет плохую маршрутизацию. Он только задаёт поведение получателей при провале проверок. Если SPF не содержит реальных отправителей, DKIM не подписывает письма, а PTR отсутствует, включение p=reject приведёт к отказам легитимной почты. Сначала инвентаризация. Потом enforcement.

TTL и распространение DNS: как не устроить простой

TTL определяет, сколько времени резолверы могут кэшировать запись. При изменении почтовой инфраструктуры это критично. Рекомендуемый рабочий диапазон при смене настроек — 300–3600 секунд. Ниже 300 не всегда имеет смысл. Выше 3600 усложняет откат.

Не путайте TTL с гарантированным временем глобального обновления. DNS — кэшируемая система. Даже если авторитетный NS уже отдаёт новую запись, промежуточные резолверы могут держать старую до истечения TTL. Отдельные провайдеры могут вести себя консервативно. Время распространения зависит от TTL и кэширования. В реальности это может быть от минут до длительного периода, вплоть до десятков часов.

Правильный порядок миграции почты:

1. За 24–48 часов до изменения снизьте TTL для MX, SPF, DKIM, DMARC и A-записей почтовых хостов, если текущие TTL высокие.

2. Поднимите новый MTA и проверьте SMTP-доступность.

3. Настройте PTR до переключения MX, а не после.

4. Опубликуйте SPF с учётом старого и нового исходящего источника на время миграции.

5. Опубликуйте DKIM для нового сервиса заранее.

6. Переключите MX.

7. Наблюдайте очереди на старом и новом MTA.

8. После стабилизации удалите старые отправители из SPF.

9. Верните TTL к штатному значению, если низкий TTL больше не нужен.

Низкий TTL не должен быть постоянной заменой дисциплины. Он увеличивает частоту обращений к авторитетным NS. Для небольших зон это редко проблема, но в крупной инфраструктуре лишняя нагрузка и шум в логах не нужны. Держите низкий TTL на период изменений. Потом возвращайте нормальные значения.

Особенно аккуратно меняйте SPF. Старые письма могут ещё идти через прежний сервис. Если удалить старый include или IP сразу после переключения, часть легитимной почты получит SPF fail. При наличии DKIM и корректного DMARC это может не сломать доставку. Но рассчитывать на это нельзя.

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

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

Шаг 1. Проверьте авторитетные NS

Убедитесь, что редактируете правильную DNS-зону. Если домен делегирован на NS провайдера DNS, изменения у регистратора не будут влиять на ответы. Если зона обслуживается Cloud DNS или CDN, правьте там.

Проверьте:

• какие NS указаны у регистратора;
• какие NS отвечают авторитетно;
• нет ли split-brain, когда разные NS отдают разные версии зоны;
• совпадает ли SOA serial после изменения зоны.

Для SaaS-панелей это часто скрыто. Но результат должен проверяться внешними запросами, а не только зелёной галкой в интерфейсе.

Шаг 2. Создайте имя почтового сервера

Назначьте MTA стабильное имя. Например, mail.example.com. На это имя создайте A-запись. Если IPv6 реально используется и MTA принимает/отправляет по IPv6, добавьте AAAA. Если IPv6 не настроен корректно, не публикуйте AAAA. Полурабочий IPv6 ломает доставку хуже, чем его отсутствие.

Проверьте, что SMTP слушает нужные порты:

• 25/TCP для межсерверной доставки;
• 587/TCP для submission с аутентификацией;
• 465/TCP, если используется SMTPS;
• 993/TCP для IMAPS, если сервер также обслуживает ящики.

DNS не открывает порты. DNS только указывает адрес. Фаервол, NAT и MTA должны быть настроены отдельно.

Шаг 3. Настройте MX

Создайте MX у основного домена. Значение — FQDN почтового сервера. Приоритет — целое число, где меньше значит выше.

Если есть один сервер, не добавляйте фиктивный резервный MX. Один корректный MX лучше, чем два, где второй принимает мусор и не знает пользователей.

Если есть два сервера, оба должны:

• принимать почту для домена;
• знать действующих получателей или проверять их через общий backend;
• использовать совместимую антиспам-политику;
• иметь очереди и корректную ретрансляцию;
• не быть open relay.

Шаг 4. Настройте PTR

Откройте панель владельца IP или запросите reverse DNS через поддержку провайдера. PTR должен указывать на имя MTA. Затем проверьте forward-confirmed reverse DNS: обратное имя должно резолвиться обратно в тот же IP.

Не ставьте PTR на корневой домен, если MTA называется иначе. Не используйте PTR провайдера по умолчанию. Не меняйте HELO/EHLO на имя, которое не соответствует DNS.

Шаг 5. Опубликуйте SPF

Соберите все исходящие источники. Не начинайте с копирования чужой SPF-записи. Для домена с одним MTA достаточно разрешить IP или MX-механизм и закрыть остальное -all после тестов.

На этапе внедрения допустим ~all, если не все источники известны. Но это временное состояние. После инвентаризации переходите к жёсткой политике.

Контролируйте длину и количество include. SPF-запись должна быть читаемой. Если в ней пять маркетинговых платформ, старый helpdesk и два отключённых сервиса, это не настройка. Это накопленный долг.

Шаг 6. Включите DKIM

Сгенерируйте ключ. Опубликуйте TXT по селектору. Включите подпись на исходящем MTA. Проверьте внешним получателем, что подпись проходит.

Если отправляют несколько систем, у каждой может быть свой селектор. Это нормально. Не требуйте один ключ на всю организацию. Требуйте, чтобы каждый легитимный поток подписывался доменом, выровненным с From, либо проходил SPF alignment.

Шаг 7. Введите DMARC

Опубликуйте DMARC у _dmarc.example.com. Начните с мониторинга. Разберите отчёты. Исправьте источники. Затем включайте quarantine и reject.

Для доменов без отправки применяйте запретительную модель. Пустой домен тоже нуждается в SPF и DMARC. Иначе его можно использовать как видимый From в фишинге.

Шаг 8. Проверьте доставку на реальном письме

Не ограничивайтесь DNS-запросами. Отправьте письмо на внешний ящик и изучите заголовки. Нужны результаты:

• spf=pass;
• dkim=pass;
• dmarc=pass;
• корректный smtp.mailfrom;
• корректный header.from;
• ожидаемый DKIM selector;
• отсутствие подмены маршрута.

Если один тестовый сервис показывает зелёный статус, это не полная проверка. Проверяйте на нескольких получателях. Разные крупные провайдеры по-разному взвешивают PTR, репутацию IP, DMARC, возраст домена и историю жалоб.

Типовые отказы после настройки

После изменения DNS проблемы обычно выглядят одинаково. Диагностируйте по слою, а не по симптомам в интерфейсе пользователя.

Не лечите доставляемость добавлением новых записей без удаления старых. В DNS часто остаются хвосты: старые DKIM-селекторы, include отключённых сервисов, лишние MX, забытые верификационные TXT. Они не всегда ломают доставку сразу. Но они расширяют поверхность атаки и усложняют аудит.

Отдельная проблема — домены, где сайт отправляет почту напрямую через PHP mail или локальный sendmail на веб-хостинге. Такой поток часто не попадает в SPF, не подписывается DKIM и использует чужой HELO. Переведите сайт на authenticated SMTP через основной MTA или транзакционный сервис. Не оставляйте неконтролируемую отправку с веб-сервера.

Контроль после запуска

Настройка DNS для почты не заканчивается публикацией записей. Нужен период наблюдения. Минимум — несколько дней обычного трафика. Для доменов с большим количеством систем — дольше.

Контролируйте:

• очереди исходящей почты на MTA;
• bounce-сообщения от крупных провайдеров;
• отчёты DMARC;
• изменение репутации IP;
• появление новых источников в SPF;
• несанкционированные DKIM-селекторы;
• соответствие PTR после смены IP;
• срок жизни старых записей после миграции.

После завершения миграции закройте временные допуски. Удалите старые IP из SPF. Уберите неиспользуемые MX. Отключите старые DKIM-селекторы после безопасного периода. Переведите DMARC из мониторинга в enforcement. Верните TTL к штатным значениям.

Финальная проверка выполняется не в панели DNS. Она выполняется снаружи.

Используйте команды:

• dig NS example.com — проверьте авторитетные серверы;
• dig MX example.com — проверьте маршрут входящей почты;
• dig A mail.example.com — проверьте адрес MTA;
• dig -x 203.0.113.10 — проверьте PTR;
• dig TXT example.com — проверьте SPF;
• dig TXT selector._domainkey.example.com — проверьте DKIM;
• dig TXT _dmarc.example.com — проверьте DMARC;
• swaks --to user@example.com --server mail.example.com — проверьте SMTP-диалог;
• openssl s_client -starttls smtp -connect mail.example.com:587 — проверьте TLS на submission.

Настройка DNS-сервера для почты считается рабочей только после прохождения полного цикла: MX принимает, PTR совпадает, SPF ограничивает, DKIM подписывает, DMARC управляет отказами, TTL не мешает изменениям. Всё остальное — частичная конфигурация. Для почтовой инфраструктуры частичная конфигурация равна техническому долгу.