DNS и SMTP: как настроить MX, SPF, DKIM и DMARC для надёжной почты

Если у вас есть домен и вы отправляете письма — из веб-приложения, CRM, магазина или просто почтового ящика — вы уже зависите от DNS и SMTP, даже если никогда об этом не думали. Любая ошибка в MX, SPF, DKIM или DMARC легко превращается в невидимую катастрофу: письма формально «отправляются», но до получателя не доходят или стабильно падают в спам.

В этом разборе пройдём весь путь: от базовой теории DNS для почты до практической настройки записей под типичные сценарии. Фокус — на админах, девопсах и веб-мастерах, которые сами управляют DNS-зоной и интеграциями с почтовыми сервисами и SMTP-серверами.

Как DNS участвует в доставке почты

SMTP сам по себе не знает, куда доставлять письма для домена. Он опирается на DNS. Упрощённый алгоритм выглядит так:

1. Отправитель формирует письмо с адресом вида user@example.com.
2. SMTP-сервер-отправитель делает DNS-запрос MX для домена example.com.
3. Получает список MX-записей с приоритетами и для каждой MX-записи — A/AAAA-записи.
4. Устанавливает SMTP-соединение по порту 25 с выбранным хостом (submission-порты для авторизованной отправки — отдельная тема).

Вся магия выбора входящего сервера для домена завязана на MX-записи DNS. А доверие к исходящей почте и фильтрация спама — на TXT-записях SPF, DKIM и DMARC.

Какие типы DNS-записей нужны для почты

Минимальный набор DNS для нормальной работы SMTP с вашим доменом:

• MX — указывает хосты, принимающие почту для домена.
• A/AAAA — IP-адреса MX-хостов и исходящих SMTP-серверов.
• PTR (обратная зона, на стороне провайдера IP) — связывает IP с именем сервера, критично для репутации.
• TXT SPF — список источников, которым разрешено отправлять письма от имени домена.
• TXT DKIM — публичные ключи для проверки подписи исходящих писем.
• TXT DMARC — политика обработки писем, не прошедших SPF/DKIM, и параметры отчётности.

Плюс вспомогательные записи вроде _dmarc и selector._domainkey, а также служебные CNAME/SRV под автоконфиг почтовых клиентов — о них поговорим ниже.

MX-записи: базис почты в DNS

MX (Mail Exchanger) говорит всем серверам мира: «почту для домена принимай вот здесь». Ключевые моменты:

• MX всегда указывает на имя хоста, а не напрямую на IP.
• Для каждого MX-хоста должны быть корректные A/AAAA-записи.
• У MX есть приоритет (integer): меньше число — выше приоритет.

Пример простой MX-настройки

Классический случай: у вас один почтовый сервер mx1.example.com, принимающий почту за домен example.com:

example.com.       3600    IN MX  10 mx1.example.com.
mx1.example.com.   3600    IN A   203.0.113.10

Здесь 10 — приоритет MX. Дополнительные MX с бóльшим числом станут резервными.

Резервные MX и подводные камни

Многие старые руководства советуют обязательно заводить backup MX. На практике:

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

Лучше один корректно настроенный MX без резервных, чем сомнительный backup MX, который не проходит SPF/DKIM/DMARC или имеет плохую репутацию IP.

TTL MX и переключения

Обратите внимание на TTL записей MX и A/AAAA. Если вы планируете миграцию почты или смену почтового провайдера, имеет смысл заранее уменьшить TTL, чтобы переключение прошло быстрее. Однако слишком маленький TTL (например, 60 секунд) создаст лишнюю нагрузку на DNS и не даст существенной выгоды — достаточно 600–1800 секунд для планируемых работ.

Если вы размещаете почтовый сервер на VDS или на отдельном сервере для изоляции нагрузки, MX-домены всё равно должны указывать на стабильные FQDN, а не на «сырые» IP — так проще мигрировать и масштабироваться.

SPF: какие SMTP-сервера можно считать «своими»

SPF (Sender Policy Framework) описывает в TXT-записи, от каких IP-адресов или хостов можно отправлять почту с адресами вашего домена.

Проверка SPF выполняется для MAIL FROM (envelope from), а не только для заголовка From:. Это важно для DMARC и согласования доменов.

Простейший SPF для одного исходящего сервера

Допустим, у вас один SMTP-сервер с IP 203.0.113.20. SPF будет примерно таким:

example.com.  3600  IN TXT  "v=spf1 ip4:203.0.113.20 -all"

Расшифровка:

• v=spf1 — версия SPF.
• ip4:203.0.113.20 — этот IPv4-адрес может отправлять почту.
• -all — всё остальное жёстко запрещено.

Если у вас несколько IP или подсеть — добавляете дополнительные механизмы: ip4:203.0.113.21, ip4:203.0.113.0/24, a, mx и так далее.

SPF для сайта, почтового сервиса и CRM

Реальные сценарии сложнее: домен используется:

• для транзакционных писем с сайта (с собственного сервера или хостинга);
• для ящиков у стороннего провайдера (почтовый хостинг, корпоративная почта);
• для e-mail маркетинга (рассылочный сервис);
• для писем из CRM/Helpdesk.

Для этого используют include: в SPF. Например:

example.com.  3600  IN TXT  "v=spf1 a mx ip4:203.0.113.20 include:spf.mailprovider.tld include:_spf.crmsystem.tld -all"

Здесь:

• a — разрешить IP, указанные в A-записи домена;
• mx — разрешить IP, указанные в MX-записях;
• ip4:203.0.113.20 — отдельный исходящий сервер;
• include:... — довериться политикам внешних провайдеров.

Типичные ошибки с SPF

• Несколько SPF-записей для одного домена: валидатор SPF будет считать их невалидными. Всегда только одна TXT-запись SPF.
• Превышение лимита 10 DNS-запросов внутри SPF (для механизмов include, a, mx, ptr, exists): приводит к permerror и игнорированию SPF.
• Слишком мягкий модификатор — ~all вместо -all на боевом домене, когда политика уже отлажена.
• Забытый старый IP/сервис после миграции — формально всё «проходит», но открывает окно для подделки почты.

Если у вас много сторонних сервисов, стоит заранее продумать стратегию: вынести часть трафика в поддомены (mail.example.com, news.example.com) и не завязывать всё на один SPF основного домена.

Для проектов, где веб-приложение работает на общем виртуальном хостинге, а почта — у отдельного провайдера, особенно важно аккуратно описать в SPF именно тот IP или hostname, с которого реально выходит SMTP-трафик (часто это не совпадает с A-записью сайта).

DKIM: криптографическая целостность и подлинность

DKIM (DomainKeys Identified Mail) подписывает исходящие письма криптографической подписью. Сервер-отправитель добавляет заголовок DKIM-Signature, а получатель проверяет его, используя публичный ключ в DNS.

DKIM для домена задаётся TXT-записями вида:

selector._domainkey.example.com.  3600  IN TXT  "v=DKIM1; k=rsa; p=..."

selector — произвольное имя (например, mail2025), позволяющее иметь несколько ключей и ротацию без простоя.

Подробно про ротацию ключей DKIM, выбор TTL для селекторов и типичные ошибки с DNS мы разбирали в материале Ротация DKIM-селекторов и выбор TTL — он хорошо дополняет эту статью.

Как DKIM работает в связке с SMTP

Когда ваш SMTP-сервер (или облачный почтовый сервис) отправляет письмо:

1. Он вычисляет хеш по ключевым заголовкам (From, Subject и т.д.) и телу письма.
2. Подписывает хеш приватным ключом.
3. Записывает в заголовок DKIM-Signature информацию о селекторе, домене, списке подписанных заголовков и саму подпись.
4. Получающий сервер делает DNS-запрос по имени selector._domainkey.example.com, получает публичный ключ и проверяет подпись.

Если подпись проходит, получатель понимает: письмо действительно прошло через сервер, владеющий приватным ключом, а содержимое не изменялось.

Практика: где генерить ключи и как не сломать DNS

Чаще всего ключи DKIM генерируются либо самим почтовым сервером (Postfix/OpenDKIM, Exim и т.п.), либо сторонним сервисом. Он же отдаёт вам текст TXT-записи. Важно:

• Не ломать формат: многие панели переносят строки, добавляют лишние кавычки или пробелы.
• Не сокращать и не модифицировать значение p= — это base64-представление публичного ключа.
• Следить за TTL при ротации ключей: сначала добавляете новый ключ с новым селектором, меняете конфиг MTA на новый селектор, потом удаляете старый.

Старайтесь не использовать слишком долгоживущие ключи без ротации: утечка приватного ключа позволит злоумышленникам отправлять подписанные письма от вашего домена.

DMARC: политика и отчёты

DMARC (Domain-based Message Authentication, Reporting and Conformance) — это слой над SPF и DKIM. Он:

• определяет политику, что делать с письмами, не прошедшими SPF/DKIM;
• проверяет согласование домена в From с доменами SPF и DKIM;
• отправляет агрегированные отчёты на указанный e-mail.

DMARC задаётся в виде TXT-записи особого имени:

_dmarc.example.com.  3600  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1"

Основные параметры:

• p=none|quarantine|reject — политика (наблюдать, отправлять в спам, отклонять).
• rua= — адрес для агрегированных отчётов.
• ruf= — адрес для форенсик-отчётов (обычно сильно шумные, аккуратнее).
• pct= — процент писем, на которые применять политику.

Согласование доменов: как DMARC стыкует SPF и DKIM

DMARC считает письмо валидным, если:

• либо SPF прошёл и домен в SPF (envelope-from / HELO) согласован с доменом в заголовке From: (relaxed или strict align);
• либо DKIM прошёл и домен в подписи DKIM согласован с доменом в From:.

То есть само по себе прохождение SPF или DKIM без согласования домена может не спасти письмо при строгой политике DMARC.

Пошаговый переход к строгому DMARC

Безболезненный сценарий внедрения DMARC обычно выглядит так:

1. Включить DMARC с p=none, задать rua= и анализировать отчёты: кто шлёт от вашего домена и откуда.
2. Почистить и легализовать все законные источники отправки: обновить SPF, настроить DKIM.
3. Перейти на p=quarantine с pct=10, постепенно увеличивая процент до 100.
4. После уверенности, что всё легитимное проходит SPF или DKIM и домены согласованы, включить p=reject (также через pct= по нарастающей).

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

Практический сценарий: домен, веб-сайт и почта у разных провайдеров

Типовой для админа сценарий:

• домен зарегистрирован у одного регистратора, DNS-зоной вы управляете самостоятельно;
• сайт крутится на одном хостинге или VDS, отправляет транзакционные письма (заказы, регистрации);
• почтовые ящики живут у отдельного провайдера (например, корпоративная почта);
• рассылки/маркетинг ведёт сторонний e-mail-сервис.

Нужно:

• сделать так, чтобы входящая почта приходила на правильный почтовый сервис (MX);
• настроить исходящую почту со всех трёх источников (сайт, ящики, рассылки) так, чтобы они проходили SPF, DKIM, DMARC.

Шаг 1: MX на провайдера ящиков

Обычно почтовый сервис даёт готовый набор MX-записей. Вы просто прописываете их в своей DNS-зоне домена:

example.com.  3600  IN MX  10 mx1.mailprovider.tld.
example.com.  3600  IN MX  20 mx2.mailprovider.tld.

И следите, чтобы не осталось старых MX (например, у хостинга сайта), если они больше не принимают почту.

Шаг 2: SPF для всех источников

Собираете все источники отправки:

• IP сервера с сайтом или его A-запись;
• SPF-политику почтового провайдера (через include:);
• SPF-политику рассылочного сервиса (через include: или CNAME-делегирование).

Формируете единственную SPF-запись для корневого домена. Пример:

example.com.  3600  IN TXT  "v=spf1 a:web.example.com include:spf.mailprovider.tld include:_spf.mktgservice.tld -all"

Здесь:

• a:web.example.com — разрешаем серверу сайта отправлять почту;
• include:spf.mailprovider.tld — почтовые ящики;
• include:_spf.mktgservice.tld — маркетинговый сервис.

Шаг 3: DKIM для каждого источника

Каждый отправитель будет использовать свой DKIM-селектор и свой домен:

• почтовый сервис — отдельные TXT-записи вида selector1._domainkey.example.com;
• рассылочный сервис — свои селекторы вида mktg1._domainkey.example.com и так далее;
• сайт / транзакционные письма — свой селектор через OpenDKIM или встроенную функциональность SMTP-сервера.

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

Шаг 4: DMARC и отчёты

Когда SPF и DKIM завернуты со всех сторон, включаем DMARC на мониторинг:

_dmarc.example.com.  3600  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

После стабилизации и анализа отчётов — усиливаем политику, вплоть до p=reject, при необходимости через pct=.

SMTP, PTR и репутация: нюансы для своих серверов

Если вы поднимаете собственный SMTP-сервер (на хостинге или VDS), одной только настройки DNS на своей стороне недостаточно. Есть ещё несколько критичных моментов:

• PTR (обратная DNS-запись) на IP сервера должен указывать на полное доменное имя (FQDN), которое сервер объявляет в HELO/EHLO.
• FQDN из PTR должен иметь A/AAAA-записи назад на тот же IP (forward-confirmed reverse DNS).
• Сервер должен поддерживать современный TLS на SMTP (в том числе STARTTLS на порту 25) и не иметь просроченных или заведомо недоверенных сертификатов.

Без корректного PTR и адекватного TLS многие крупные провайдеры могут сильно занижать оценку писем либо блокировать соединения.

Проверка связки DNS и SMTP

Минимальный чек-лист диагностики с рабочей станции или отдельного тестового хоста:

• dig MX example.com — MX указывает на нужные хосты.
• dig A mx1.example.com — MX-имена резолвятся в корректные IP.
• dig TXT example.com — SPF присутствует и единственный.
• dig TXT selector._domainkey.example.com — DKIM-запись доступна.
• dig TXT _dmarc.example.com — DMARC-запись существует.
• dig -x 203.0.113.10 — PTR указывает на FQDN SMTP-сервера.

После этого имеет смысл отправить тестовые письма на внешние ящики (например, крупные публичные сервисы) и проверить заголовки: там будет видно, как прошли SPF, DKIM и DMARC, какие домены участвовали в проверке и какая политика была применена.

Типичные проблемы и как их диагностировать

Чаще всего админы сталкиваются не с полным отсутствием записей, а с тонкими несогласованностями.

SPF/DKIM проходят, а DMARC всё равно ругается

Проверьте:

• совпадают ли домены в From: и в SPF-домене (envelope-from, HELO);
• какой домен указан в теге d= подписи DKIM и согласован ли он с From;
• не используете ли вы другой домен для технического отправителя (например, bounces@sub.example.com) при From = info@example.com без соответствующей DMARC-политики на субдомене.

Письма от веб-приложения стабильно в спаме

Проверяйте по шагам:

1. С какого IP реально уходит SMTP-трафик? Это может быть не тот сервер, где крутится приложение (например, используется smarthost).
2. Занесён ли этот IP (или его домен) в SPF-запись?
3. Подписываются ли эти письма DKIM и совпадает ли домен подписи с From?
4. Есть ли PTR-запись у IP и совпадает ли она с FQDN сервера, объявляемым в HELO/EHLO?

Перенос домена или SMTP — и внезапные сбои почты

Классическая ситуация: сменили хостинг, DNS-провайдера или почтовый сервис, а:

• остался старый MX, указывающий на бывший почтовый сервер;
• SPF всё ещё ссылается на старый IP или старый include;
• DKIM-селектор удалён или изменён на стороне сервиса, но DNS-запись не обновлена;
• DMARC с жёсткой политикой начинает отклонять «легитимные» письма из-за рассинхрона.

Перед миграцией заведите чек-лист DNS-параметров и используйте поэтапное переключение с пониженным TTL. При сложных переездах иногда полезно временно ослабить DMARC до p=none на время активной фазы.

Рекомендованная стратегия для нового домена

Если вы только подключаете домен к почте и рассылкам, логичная пошаговая стратегия выглядит так:

1. Зарегистрировать домен и настроить базовые A/AAAA и NS-записи.
2. Выбрать почтового провайдера для ящиков и настроить MX-записи.
3. Настроить SPF на мягкую политику с перечислением основного почтового сервиса и IP сайта.
4. Включить DKIM на всех источниках исходящей почты (почтовый сервис, маркетинг, транзакционные письма).
5. Подключить DMARC с p=none и сбором отчётов, пару недель наблюдать.
6. После стабилизации ужесточить SPF (-all) и DMARC (quarantine/reject с постепенным увеличением pct).

Это снизит риск, что первые же клиенты не увидят ваши письма — при этом вы с самого начала заложите правильный фундамент DNS+SMTP для домена и сможете дальше спокойно масштабировать инфраструктуру.

Выводы

DNS для SMTP — это не только MX-запись. Чтобы письма стабильно доходили и не тонули в спаме, нужно правильно выстроить связку MX + A/AAAA + PTR + SPF + DKIM + DMARC и следить за ней при любой миграции, смене хостинга или подключении новых сервисов.

Подходите к этому как к инфраструктурному проекту: документируйте все источники исходящей почты, контролируйте изменения в DNS, используйте DMARC-отчёты как мониторинг, а не как «галочку». Тогда домен будет иметь предсказуемую репутацию, а ваши письма — максимальную доставляемость.