Настройка DNS-записей почтового сервера: MX, SPF, DKIM, DMARC

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

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

MX указывает, какой сервер принимает почту для домена. SPF задает список IP-адресов, которым разрешено отправлять письма от имени домена. DKIM добавляет цифровую подпись, которую получатель проверяет через публичный ключ в DNS. DMARC объединяет SPF и DKIM и определяет, что делать с письмами, не прошедшими проверку.

В этом руководстве разобраны синтаксис каждой записи, пошаговые инструкции для популярных DNS-провайдеров, команды диагностики через dig и nslookup, типичные ошибки и рекомендации по мониторингу. Все примеры актуальны для 2026 года и проверены на практике.

Основы DNS и почтовых записей

DNS-зона домена хранит ресурсные записи разных типов. Для почты критичны четыре типа: MX, TXT (в котором размещаются SPF, DKIM и DMARC), A и AAAA. A-запись указывает IP-адрес почтового сервера, MX ссылается на его hostname, TXT-записи содержат политики аутентификации.

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

Как работает MX-запись

MX-запись определяет почтовые серверы, ответственные за прием почты для домена. Синтаксис состоит из двух полей: приоритет и hostname сервера.

example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN MX 20 backup.example.com.

Приоритет задается целым числом от 0 до 65535. Чем меньше число, тем выше приоритет. Отправляющий сервер сначала пытается доставить письмо на сервер с приоритетом 10. Если он недоступен, используется сервер с приоритетом 20. Одинаковые приоритеты означают случайный выбор между серверами для балансировки нагрузки.

Hostname в MX-записи должен указывать на A или AAAA-запись. Использовать IP-адрес напрямую в MX нельзя, это нарушение RFC 5321. Точка в конце hostname обязательна в зонных файлах, но в веб-панелях DNS она добавляется автоматически.

SPF: разрешенные отправители

SPF публикуется как TXT-запись и перечисляет механизмы, определяющие разрешенных отправителей. Запись начинается с версии v=spf1 и заканчивается квалификатором all.

example.com. 3600 IN TXT "v=spf1 mx ip4:192.0.2.10 include:_spf.example.net ~all"

Основные механизмы:

mx - разрешить отправку с серверов, указанных в MX-записях домена
ip4 и ip6 - разрешить конкретные IP-адреса или подсети
include - включить SPF-запись другого домена
a - разрешить отправку с IP-адреса A-записи домена
all - обрабатывать всех остальных отправителей

Квалификаторы перед механизмами: + (pass, по умолчанию), - (fail), ~ (softfail), ? (neutral). Рекомендация для production: использовать ~all на этапе внедрения, затем ужесточить до -all.

Ограничение SPF: суммарное количество DNS-запросов при проверке не должно превышать 10. Каждый include, mx, a и ptr генерирует дополнительные запросы. Превышение лимита приводит к ошибке SPF PermError, и письмо может быть отклонено.

DKIM: подпись писем

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

Публичный ключ публикуется в TXT-записи с именем, состоящим из селектора и домена:

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

Селектор - произвольная строка, позволяющая использовать несколько ключей для одного домена. Например, mail, google, 2026q1. При ротации ключей создается новый селектор, старый удаляется после переходного периода.

Параметр k=rsa указывает алгоритм шифрования. Длина ключа 2048 бит - текущий стандарт. Ключи 1024 бита считаются слабыми и не рекомендуются. Параметр p= содержит публичный ключ в Base64 без переносов строк.

DMARC: политика обработки

DMARC публикуется в TXT-записи с именем _dmarc.example.com и определяет, как получатель должен обрабатывать письма, не прошедшие SPF или DKIM.

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

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

v=DMARC1 - версия протокола, обязательный параметр
p= - политика для домена: none, quarantine или reject
sp= - политика для поддоменов, если отличается от основной
rua= - адрес для агрегированных отчетов
ruf= - адрес для forensic-отчетов о конкретных письмах
fo= - условия генерации forensic-отчетов
pct= - процент писем, к которым применяется политика

Политика p=none означает мониторинг без воздействия на доставку. p=quarantine отправляет подозрительные письма в спам. p=reject отклоняет письма на уровне SMTP. Внедрение должно идти постепенно: от none к quarantine, затем к reject.

Подготовка к настройке

Перед изменением DNS соберите информацию:

Доменное имя и доступ к панели управления DNS
IP-адрес и hostname почтового сервера
Список всех сервисов, отправляющих почту от имени домена: CRM, рассылки, мониторинг, сайт
Селектор DKIM, сгенерированный почтовым сервером
Адрес для получения DMARC-отчетов

Создайте резервную копию текущих записей. Экспортируйте зону в текстовый файл или сделайте скриншоты панели DNS. Это позволит быстро откатить изменения при ошибке.

Учитывайте TTL. Значение по умолчанию 3600 секунд означает, что изменения распространятся в течение часа. Для тестирования временно установите TTL 300 секунд, после проверки верните 3600 или выше. Полное распространение по мировым DNS-резолверам может занять до 48 часов.

Пошаговая настройка записей

Порядок настройки: сначала A-запись для почтового сервера, затем MX, SPF, DKIM и DMARC. Начинать с DMARC можно только после проверки SPF и DKIM.

Настройка MX-записи

В панели DNS создайте запись типа MX. Основные поля:

Host - обычно @ или пусто, означает корень домена
Value - hostname почтового сервера, например mail.example.com
Priority - 10 для основного сервера, 20 для резервного
TTL - 3600 или меньше на время тестирования

Для одного сервера достаточно одной MX-записи. Для отказоустойчивости добавьте второй сервер с приоритетом 20. Убедитесь, что hostname в MX-записи имеет A-запись с корректным IP-адресом.

В Cloudflare тип записи MX выбирается в выпадающем списке, поле Priority заполняется отдельно. В GoDaddy и Яндекс.Доменах приоритет указывается в поле Value перед hostname: 10 mail.example.com.

Настройка SPF-записи

Создайте TXT-запись с host @ и значением SPF. Базовый вариант для собственного почтового сервера:

v=spf1 mx -all

Если почта отправляется с конкретного IP-адреса:

v=spf1 ip4:192.0.2.10 -all

При использовании внешних сервисов добавьте include:

v=spf1 mx include:_spf.google.com include:spf.mailjet.com -all

Домен может иметь только одну SPF-запись. Несколько TXT-записей с v=spf1 приводят к ошибке PermError. Объединяйте все механизмы в одной строке.

Настройка DKIM-записи

Сначала сгенерируйте пару ключей. В Postfix с OpenDKIM:

opendkim-genkey -b 2048 -d example.com -s mail -D /etc/opendkim/keys

Команда создаст два файла: mail.private и mail.txt. Приватный ключ размещается на почтовом сервере, публичный ключ из файла mail.txt добавляется в DNS.

В панели DNS создайте TXT-запись с host mail._domainkey и значением из файла mail.txt. Значение содержит параметры v, k и p. Удалите переносы строк и кавычки, если панель их не принимает.

Для Microsoft 365 селектор по умолчанию selector1 или selector2. Для Google Workspace - google. Значение DKIM-записи можно скопировать из административной панели сервиса.

Настройка DMARC-записи

Создайте TXT-запись с host _dmarc. Начните с политики мониторинга:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Через 2-4 недели анализа отчетов перейдите к карантину:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=50

Параметр pct=50 применяет политику к 50% писем. Постепенно увеличивайте процент до 100, затем ужесточайте политику до reject:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Для поддоменов можно задать отдельную политику через параметр sp=. Если поддомены не отправляют почту, установите sp=reject для защиты от подделки.

Проверка настроек

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

Использование dig и nslookup

Проверка MX-записей:

dig MX example.com +short
10 mail.example.com.

Проверка SPF:

dig TXT example.com +short
"v=spf1 mx -all"

Проверка DKIM:

dig TXT mail._domainkey.example.com +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Проверка DMARC:

dig TXT _dmarc.example.com +short
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

nslookup работает аналогично:

nslookup -type=MX example.com
nslookup -type=TXT _dmarc.example.com

Ожидаемый вывод: запись с корректным значением и TTL. Пустой ответ означает, что запись не создана или еще не распространилась. Используйте публичные DNS-резолверы 8.8.8.8 или 1.1.1.1 для проверки распространения.

Онлайн-инструменты проверки

Специализированные сервисы выполняют комплексную проверку и показывают ошибки в удобном виде. MXToolbox проверяет MX, SPF, DKIM и DMARC, показывает статус каждой записи и предупреждения. DKIMValidator проверяет подпись конкретного письма. DMARC Inspector анализирует DMARC-запись и отчеты.

Для комплексной проверки отправьте тестовое письмо на адрес, который показывает результаты аутентификации. Gmail отображает статус SPF, DKIM и DMARC в заголовках письма: кнопка «Показать оригинал» показывает все проверки.

Типичные ошибки и их решение

Несколько SPF-записей. Симптом: проверка SPF возвращает PermError, письма отклоняются. Решение: объединить все механизмы в одну TXT-запись. Удалить лишние записи с v=spf1.

Неправильный приоритет MX. Симптом: почта уходит на резервный сервер или не доставляется. Решение: убедиться, что основной сервер имеет наименьшее числовое значение приоритета. Проверить, что hostname в MX-записи резолвится в корректный IP.

Неверный селектор DKIM. Симптом: DKIM-подпись не проверяется, письма попадают в спам. Решение: сравнить селектор в заголовке DKIM-Signature письма с селектором в DNS-записи. Они должны совпадать.

Слишком строгая политика DMARC. Симптом: легитимные письма отклоняются. Решение: временно вернуть политику p=none, проанализировать отчеты, найти источники легитимной почты, добавить их в SPF и DKIM, затем снова ужесточить политику.

Превышение лимита DNS-запросов в SPF. Симптом: SPF PermError при проверке. Решение: сократить количество include, использовать ip4 вместо hostname, объединить механизмы. Максимум 10 DNS-запросов на проверку.

Отсутствие PTR-записи. Симптом: письма отклоняются некоторыми получателями. Решение: настроить обратную DNS-зону у провайдера, PTR-запись должна указывать на hostname почтового сервера, а hostname должен резолвиться в тот же IP.

Заключение

Корректные MX, SPF, DKIM и DMARC записи обеспечивают доставку писем во входящие и защищают домен от подделки. Настройка занимает 30-60 минут, но требует внимания к деталям: синтаксис, приоритеты, селекторы и политики.

Проверьте свои записи прямо сейчас: выполните dig MX example.com, dig TXT example.com, dig TXT _dmarc.example.com. Сравните результаты с рекомендациями из этого руководства. Если записи отсутствуют или настроены с ошибками, исправьте их по шагам из разделов выше.

Для размещения почтового сервера и DNS-инфраструктуры рассмотрите облачные серверы Timeweb Cloud с гибким масштабированием ресурсов. Если нужно автоматизировать создание сайта с каталогом услуг, обратите внимание на сервис генерации SEO-сайтов.