Настройка DNS для почты: MX, SPF, DKIM, DMARC записи

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

Проверить текущую конфигурацию можно через инструмент проверки email и DNS Lookup. Дополнительно: руководство по SPF, DKIM, DMARC и доставляемость писем.

MX-записи (Mail Exchange)

Назначение

MX (Mail Exchange) указывает серверы, принимающие почту для домена. При отправке письма на user@example.com отправитель делает DNS-запрос MX для example.com и получает список серверов с приоритетами.

Формат записи

example.com.  IN  MX  10  mail.example.com.

Поле	Значение	Описание
Имя	example.com	Домен (часто оставляют пустым или @)
Тип	MX	Тип записи
Приоритет	10	Меньше = выше приоритет (0–65535)
Значение	mail.example.com	Хост почтового сервера

Несколько MX-серверов

Для отказоустойчивости настраивают несколько записей с разными приоритетами:

example.com.  IN  MX  10  mail1.example.com.
example.com.  IN  MX  20  mail2.example.com.

Сначала используется mail1; при недоступности — mail2.

A-запись для почтового сервера

MX указывает на hostname. Нужна A-запись (или AAAA для IPv6):

mail.example.com.  IN  A  192.0.2.10

Примеры для популярных провайдеров

Google Workspace:

example.com.  IN  MX  5  gmail-smtp-in.l.google.com.
example.com.  IN  MX  10  alt1.gmail-smtp-in.l.google.com.
example.com.  IN  MX  20  alt2.gmail-smtp-in.l.google.com.
example.com.  IN  MX  30  alt3.gmail-smtp-in.l.google.com.
example.com.  IN  MX  40  alt4.gmail-smtp-in.l.google.com.

Яндекс 360:

example.com.  IN  MX  10  mx.yandex.ru.

Mail.ru для бизнеса:

example.com.  IN  MX  10  mx1.mail.ru.
example.com.  IN  MX  20  mx2.mail.ru.

Microsoft 365:

example.com.  IN  MX  0  example-com.mail.protection.outlook.com.

Проверка MX

dig MX example.com +short
# или
nslookup -type=MX example.com

Через DNS Lookup — введите домен, выберите тип MX.

SPF (Sender Policy Framework)

Назначение

SPF указывает, какие серверы могут отправлять почту от имени домена. Принимающий сервер проверяет IP отправителя по SPF-записи. Запись — TXT с особым форматом.

Базовый синтаксис

example.com.  IN  TXT  "v=spf1 [механизмы] [модификатор]"

Механизмы SPF

Механизм	Описание	Пример
ip4	IPv4-адрес или подсеть	ip4:192.0.2.1 или ip4:192.0.2.0/24
ip6	IPv6	ip6:2001:db8::/32
a	A-запись домена	a или a:mail.example.com
mx	MX-записи домена	mx
include	Включить SPF другого домена	include:_spf.google.com
all	Все остальные	-all (запретить)

Модификаторы по умолчанию

• -all — жёсткий отказ (fail) для неразрешённых. Рекомендуется в продакшене.
• ~all — мягкий отказ (softfail). Для тестирования.
• ?all — нейтрально. Не рекомендуется.
• +all — разрешить всё. Не использовать.

Ограничения

• Одна SPF-запись на домен
• Максимум 10 механизмов include (лимит DNS)
• Длина записи — до 255 символов (несколько строк в TXT объединяются)
• Максимум 10 DNS-запросов при проверке (каждый include — запрос)

Примеры SPF

Только свой сервер:

v=spf1 ip4:192.0.2.10 -all

Google Workspace:

v=spf1 include:_spf.google.com -all

Яндекс:

v=spf1 include:_spf.yandex.net -all

Mail.ru:

v=spf1 include:mail.ru -all

Несколько провайдеров (Google + SendGrid):

v=spf1 include:_spf.google.com include:sendgrid.net -all

Частые ошибки SPF

1. Несколько SPF-записей — только одна допустима. Объедините механизмы в одну запись.
2. Забытый -all — без модификатора запись неполная. Используйте -all в продакшене.
3. Слишком широкий +all — разрешает всех, бессмысленно.
4. Неправильный include — проверьте точное имя домена у провайдера (например, _spf.google.com, не spf.google.com).

DKIM (DomainKeys Identified Mail)

Назначение

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

Как работает

1. Отправитель генерирует пару ключей (приватный + публичный)
2. Приватный ключ хранится на почтовом сервере
3. Публичный ключ публикуется в DNS
4. При отправке письмо подписывается приватным ключом
5. Получатель извлекает селектор из заголовка, запрашивает ключ в DNS, проверяет подпись

Формат DNS-записи

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

selector — произвольное имя (например, default, mail, s1). Один домен может иметь несколько селекторов (для ротации ключей).

Генерация ключей

OpenSSL:

# Генерация приватного ключа (2048 бит)
openssl genrsa -out dkim_private.pem 2048

# Извлечение публичного ключа в формате для DNS
openssl rsa -in dkim_private.pem -pubout -outform DER | base64 -w 0

Вывод — длинная строка Base64. Вставьте в запись:

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

Настройка в почтовых системах

Postfix + OpenDKIM:

# /etc/opendkim.conf
Domain                  example.com
Selector                default
KeyFile                 /etc/opendkim/keys/default.private

Exim: Используется плагин dkim или dkimsign. Конфигурация зависит от сборки.

Сторонние провайдеры (SendGrid, Mailgun и т.д.): Провайдер даёт готовую DNS-запись. Обычно в панели: «Authenticate domain» → скопировать TXT-запись.

Проверка DKIM

Отправьте тестовое письмо на свой ящик. В заголовках найдите DKIM-Signature. Проверка через Email Checker покажет статус DKIM.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Назначение

DMARC объединяет SPF и DKIM, задаёт политику при несовпадении и позволяет получать отчёты о результатах проверки.

Формат записи

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=[policy]; rua=mailto:dmarc@example.com"

Основные теги

Тег	Описание	Значения
p	Политика для домена	none, quarantine, reject
sp	Политика для поддоменов	Аналогично p
rua	Email для агрегированных отчётов	mailto:dmarc@example.com
ruf	Email для отчётов о несовпадении	mailto:forensics@example.com
pct	Процент писем для применения политики	0–100 (по умолчанию 100)
adkim	Строгость проверки DKIM	r (relaxed) или s (strict)
aspf	Строгость проверки SPF	r или s

Политики

• p=none — мониторинг, письма не блокируются. Для начала.
• p=quarantine — не прошедшие проверку в карантин (спам).
• p=reject — не прошедшие отклоняются. Максимальная защита.

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

Этап 1 (тест):

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

Собирайте отчёты 1–2 недели. Анализируйте: проходят ли ваши письма SPF и DKIM.

Этап 2 (карантин):

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

10% не прошедших — в карантин. Постепенно увеличивайте pct до 100.

Этап 3 (жёсткая политика):

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

Обработка отчётов

Отчёты приходят в XML. Используйте сервисы анализа: Postmark, Valimail, dmarcian. Или парсите самостоятельно для понимания источников писем и результатов проверки.

Полный пример конфигурации

Домен example.com, почта через Google Workspace, рассылки через SendGrid.

MX:

example.com.  IN  MX  5  gmail-smtp-in.l.google.com.
example.com.  IN  MX  10  alt1.gmail-smtp-in.l.google.com.

SPF (Google + SendGrid):

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

DKIM для SendGrid (селектор s1, ключ от провайдера):

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

DMARC:

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

Проверка конфигурации

Ручная проверка DNS

# MX
dig MX example.com +short

# SPF (TXT)
dig TXT example.com +short

# DKIM (подставьте свой селектор)
dig TXT default._domainkey.example.com +short

# DMARC
dig TXT _dmarc.example.com +short

Онлайн-инструменты

• Email Checker — комплексная проверка SPF, DKIM, DMARC
• DNS Lookup — просмотр любых DNS-записей

Отправка тестового письма

Сервисы mail-tester.com, glockapps.com — отправьте письмо на указанный адрес, получите оценку и детали проверки SPF/DKIM/DMARC.

Распространение DNS и задержки

После изменения DNS записи распространяются не мгновенно. TTL (Time To Live) определяет время кэширования. Типичные значения: 300 (5 мин), 3600 (1 час), 86400 (24 часа).

При первой настройке используйте низкий TTL (300), чтобы быстрее откатить при ошибке. После стабилизации — увеличьте.

Дополнительные записи для почты

PTR (обратная DNS-запись)

Для исходящих серверов настройте PTR (reverse DNS): IP должен резолвиться в hostname, который совпадает с именем в HELO/EHLO. Многие провайдеры проверяют PTR и отклоняют письма при несовпадении. Настраивается у хостинг-провайдера, не в обычной DNS-зоне.

BIMI (Brand Indicators for Message Identification)

Опциональная запись для отображения логотипа в поддерживающих клиентах (Gmail, Yahoo). Требует DMARC с политикой p=quarantine или p=reject и верифицированный VMC-сертификат. Пока редко используется.

MTA-STS (Mail Transfer Agent Strict Transport Security)

Политика принудительного TLS для доставки почты. Создаётся запись _mta-sts.example.com и файл на https://mta-sts.example.com/.well-known/mta-sts.txt. Защищает от downgrade-атак при передаче между серверами.

TLS Reporting

Отчётность о проблемах TLS при доставке. Запись _smtp._tls.example.com с rua=mailto:tlsreports@example.com. Помогает выявлять атаки и сбои шифрования.

Миграция почтового провайдера

При смене провайдера (например, с собственного сервера на Google Workspace):

1. Подготовить новые записи — MX, SPF, DKIM от нового провайдера
2. Снизить TTL за 24–48 часов до переключения
3. Обновить MX — почта начнёт приходить на новый сервер
4. Обновить SPF — добавить include нового провайдера, убрать старые IP
5. Настроить DKIM — новый селектор и ключ
6. DMARC — оставить p=none на 1–2 недели для мониторинга
7. Проверить через Email Checker

Параллельная работа двух провайдеров: можно временно включить оба в SPF (include обоих), затем убрать старого.

Ротация DKIM-ключей

Периодическая смена ключей DKIM повышает безопасность. Процесс:

1. Создать новый селектор (например, s2 вместо s1)
2. Сгенерировать новую пару ключей
3. Добавить DNS-запись для s2._domainkey.example.com
4. Настроить почтовый сервер на подпись селектором s2
5. Дождаться распространения DNS (TTL)
6. Переключить отправку на s2
7. Через 1–2 недели удалить старую запись s1 (для обратной совместимости с письмами в пути)

Ограничения и лимиты DNS

• SPF: до 10 механизмов include, до 10 DNS-запросов при проверке. При превышении — проверка прерывается с softfail.
• TXT-запись: до 255 символов в одной строке. Длинные записи разбивают на несколько строк в кавычках, которые объединяются при чтении.
• DKIM: длина ключа 1024 или 2048 бит. 2048 рекомендуется для долгосрочной безопасности.

Отладка: типичные сценарии

Письма не приходят — проверьте MX: указывают ли они на правильный сервер, резолвится ли hostname в IP. Проверьте firewall и порт 25.

Письма в спаме — проверьте SPF (совпадает ли IP отправителя), DKIM (подпись валидна?), DMARC (политика и отчёты). Используйте Email Checker.

SPF fail — убедитесь, что IP отправляющего сервера входит в include или явно указан. Проверьте, что нет нескольких SPF-записей.

DKIM fail — селектор в заголовке письма должен совпадать с селектором в DNS. Ключ в DNS — полный, без переносов (если разбит на строки, они объединяются без пробелов).

Заключение

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