Хватит гадать с DNS: понятный для разработчиков обзор MX, SPF, DKIM и DMARC

Почему DNS-записи для email важны уже сейчас

Когда-то аутентификация email была необязательной. В 2026 году это базовое требование. Gmail и Outlook уже требуют SPF и DKIM от массовых отправителей, а DMARC быстро становится обязательным для любого домена, который отправляет транзакционные письма. Если ваши DNS-записи неверны, письма не доходят — без bounce-сообщения, без предупреждения, просто тишина.

Проблема в том, что эти записи документированы скорее как RFC, а не как инструменты. Большинство разработчиков копируют примеры из инструкции своего email-провайдера и надеются на лучшее. Это работает до тех пор, пока не нужно что-то отладить, добавить второй сервис отправки или объяснить клиенту, почему письма с контактной формы попадают в спам.

Это руководство проходит по MX, SPF, DKIM и DMARC в том порядке, в котором вы, скорее всего, с ними столкнётесь: с достаточным количеством деталей, чтобы настроить всё правильно, и контекстом, чтобы отлаживать проблемы, когда что-то ломается.

MX-записи: куда приходит входящая почта

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

MX-запись состоит из двух частей: числа приоритета и имени хоста. Сначала пробуются меньшие значения приоритета. Если вы используете Google Workspace, ваши MX-записи могут выглядеть так:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Точки в конце важны — они показывают, что имя хоста указано полностью. Большинство DNS-провайдеров добавляют их автоматически, но не все.

Типичные ошибки: указывать в MX-записи A-запись вместо имени хоста, задавать всем записям одинаковый приоритет (что лишает смысла резервные серверы) или забывать удалить старые MX-записи при миграции между провайдерами. Устаревшие MX-записи не просто безобидно лежат в DNS — они могут вызвать почтовые петли или разделить доставку между двумя ящиками.

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

SPF: каким серверам разрешено отправлять письма от вашего имени

SPF (Sender Policy Framework) — это TXT-запись, в которой перечислены IP-адреса и домены, имеющие право отправлять email от имени вашего домена. Это первая проверка, которую выполняет большинство почтовых серверов, получая сообщение, якобы отправленное от вас.

Базовая SPF-запись выглядит так:

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

Разберём по частям:

• v=spf1 объявляет версию SPF
• include:_spf.google.com делегирует проверку SPF-записи Google
• ~all означает мягкий отказ — отклонять почту из неуказанных источников, но не слишком строго

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

У SPF есть две острые грани. Во-первых, он ломается при пересылке писем, потому что сервер пересылки не находится в вашей SPF-записи. Во-вторых, у SPF-записей есть лимит в десять DNS-запросов. Если вы включите слишком много сторонних сервисов, вы превысите лимит, и SPF перестанет работать. Решение — «сплющить» SPF-запись: заменить директивы include: фактическими диапазонами IP-адресов. Но это требует поддержки, когда провайдеры меняют свои IP.

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

DKIM (DomainKeys Identified Mail) добавляет цифровую подпись к исходящему email. Принимающий сервер проверяет подпись по открытому ключу, опубликованному в вашем DNS. Если подпись действительна и сообщение не было изменено, проверка DKIM проходит успешно.

В отличие от SPF, DKIM сохраняется при пересылке, потому что подпись передаётся вместе с сообщением. Он также более гибкий — у вас может быть несколько DKIM-ключей для разных сервисов отправки, каждый со своим selector.

DNS-запись DKIM выглядит так:

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

Selector (default в этом примере) задаётся произвольно — его выбирает ваш email-провайдер. Значение p= — это открытый ключ, обычно длинная строка в base64. Ваш email-провайдер генерирует закрытый ключ и использует его для подписи исходящих сообщений.

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

Чтобы проверить, что DKIM работает, отправьте тестовое письмо на адрес Gmail и проверьте заголовки. Ищите dkim=pass в заголовке Authentication-Results.

DMARC: применение политики и отчётность

DMARC (Domain-based Message Authentication, Reporting and Conformance) связывает SPF и DKIM вместе и сообщает принимающим серверам, что делать, если аутентификация не прошла. Он также включает отчётность, чтобы вы могли видеть, кто отправляет email от имени вашего домена — как легитимные отправители, так и подделки.

Минимальная DMARC-запись выглядит так:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none означает только мониторинг — не отклонять и не помещать в карантин сообщения, не прошедшие проверку
• rua=mailto:[email protected] указывает, куда отправлять агрегированные отчёты

Когда вы убедитесь, что SPF и DKIM работают, можно ужесточить политику до p=quarantine (отправлять не прошедшие проверку письма в спам) или p=reject (отклонять их сразу). Также можно задать политику для поддоменов с помощью sp= и указать процент сообщений, к которым применяется политика, через pct=.

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

Один важный нюанс: DMARC требует alignment. Для SPF домен в заголовке Return-Path должен совпадать с доменом в заголовке From (или быть его поддоменом). Для DKIM домен d= в DKIM-подписи должен совпадать с доменом From. Если вы используете сторонний сервис отправки, он должен поддерживать пользовательские return paths или DKIM-подпись вашим доменом, а не своим.

Как провести аудит текущей настройки

Большинство DNS-проблем невидимы, пока не приводят к сбою. Вот как проверить записи до того, как что-то сломается:

1. Запросите MX-записи: dig MX example.com должен вернуть имена хостов почтовых серверов и их приоритеты. Проверьте, что они совпадают с документацией вашего email-провайдера.

1. Проверьте синтаксис SPF: dig TXT example.com и найдите запись v=spf1. Пропустите её через SPF-валидатор, чтобы найти ошибки синтаксиса и превышение лимита запросов.

1. Проверьте DKIM-ключи: отправьте тестовое письмо и изучите заголовок DKIM-Signature. Извлеките selector и домен, затем выполните запрос dig TXT selector._domainkey.example.com, чтобы убедиться, что открытый ключ существует.

1. Проверьте политику DMARC: dig TXT _dmarc.example.com должен вернуть вашу DMARC-запись. Убедитесь, что rua= указывает на адрес, который вы действительно отслеживаете.

1. Проведите сквозной тест: используйте сервис вроде mail-tester.com или отправьте письмо на адрес Gmail и проверьте полные заголовки. Ищите spf=pass, dkim=pass и dmarc=pass в заголовке Authentication-Results.

Если вы отлаживаете, почему письма не доходят, заголовки — ваш лучший инструмент. Большинство почтовых клиентов позволяют просматривать сырые заголовки: в Gmail откройте сообщение, нажмите на три точки и выберите «Показать оригинал». Заголовок Authentication-Results точно скажет, какая проверка не прошла и почему.

Когда использовать политики для поддоменов

Если вы отправляете email с нескольких поддоменов — например, newsletter.example.com для маркетинга и app.example.com для транзакционных писем, — можно задать отдельные DMARC-политики для каждого поддомена. Это позволяет применять строгие политики к поддоменам, которые вы контролируете, сохраняя более мягкую политику на основном домене.

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

Что делать, когда аутентификация ломается

Самый распространённый сценарий сбоя — добавление нового сервиса отправки без обновления DNS. Если вы начинаете использовать нового провайдера транзакционной почты, нужно добавить его SPF include или диапазон IP-адресов, настроить DKIM-подпись вашим доменом и проверить DMARC alignment.

Вторая по частоте проблема — пересылка. Если пользователи пересылают ваше письмо на другой адрес, SPF не пройдёт проверку, потому что сервер пересылки отсутствует в вашей SPF-записи. DKIM обычно переживает пересылку, поэтому если DKIM проходит и ваша DMARC-политика допускает частичное alignment, сообщение всё равно должно быть доставлено. Если вы видите, что пересылаемая почта отклоняется, проверьте DMARC-политику — p=reject со строгим alignment сломает пересылку.

Третья проблема — распространение DNS. Изменения DNS-записей могут распространяться часами, а разные почтовые серверы кэшируют записи на разное время. Если вы только что обновили запись, а она не работает, подождите несколько часов и проверьте снова. Распространение можно проверить инструментом вроде whatsmydns.net.

Главное

• MX-записи маршрутизируют входящую почту; SPF, DKIM и DMARC аутентифицируют исходящую. Они решают разные задачи, и вам нужны все четыре.
• SPF ломается при пересылке и имеет лимит в десять запросов. DKIM переживает пересылку, но требует настройки для каждого сервиса. DMARC связывает их вместе и включает отчётность.
• Начните с p=none в DMARC, несколько недель отслеживайте отчёты, затем ужесточите до p=quarantine или p=reject, когда убедитесь, что легитимная почта проходит.
• Ошибки DNS тихие. Проверяйте конфигурацию реальной почтой и изучайте заголовки, чтобы подтвердить, что SPF, DKIM и DMARC проходят.
• Если аутентификация сломалась после добавления нового сервиса отправки, проверьте SPF includes, DKIM selectors и DMARC alignment. Заголовки покажут, какая проверка не прошла.

FAQ

Q: Можно ли иметь несколько SPF-записей?

A: Нет. Несколько SPF-записей приведут к тому, что все они будут проигнорированы. Если нужно авторизовать несколько сервисов, используйте директивы include: в одной SPF-записи или укажите диапазоны IP напрямую. Следите за лимитом в десять запросов.

Q: Нужен ли DMARC, если я отправляю всего несколько писем в день?

A: Да. DMARC не про объём — он про доказательство того, что вы тот, за кого себя выдаёте. Даже небольшие домены выигрывают от DMARC, потому что он предотвращает подделку отправителя и даёт видимость проблем доставки. Начните с p=none и адреса для отчётов.

Q: Что произойдёт, если DKIM и SPF оба не пройдут, но письмо выглядит легитимным?

A: Это зависит от вашей DMARC-политики. Если p=none, письмо доставляется с предупреждением. Если p=quarantine, оно попадает в спам. Если p=reject, оно отклоняется. Именно поэтому стоит отслеживать DMARC-отчёты перед применением строгой политики — у вас могут быть легитимные отправители, о которых вы не знали.

Q: Можно ли использовать один и тот же DKIM-ключ для нескольких доменов?

A: Технически да, но не стоит. У каждого домена должна быть собственная пара DKIM-ключей. Совместное использование ключей усложняет ротацию и увеличивает масштаб последствий, если закрытый ключ будет скомпрометирован.

Q: Как часто нужно ротировать DKIM-ключи?

A: Универсального правила нет, но для большинства доменов разумно делать это раз в год. Если вы подозреваете, что ключ был скомпрометирован, выполните ротацию немедленно. Обязательно опубликуйте новый открытый ключ в DNS до того, как начнёте подписывать письма новым закрытым ключом, и оставьте старый ключ в DNS на несколько дней после ротации, чтобы обработать задержанную почту.

<!-- tool-cta:start -->

💡 Попробуйте это: Проверьте опубликованную политику любого домена с помощью DMARC Lookup, чтобы увидеть, как на практике сочетаются записи MX, SPF и DMARC.

<!-- tool-cta:end -->

Источники

• RFC 7208: Sender Policy Framework (SPF) — Спецификация SPF, включая правила синтаксиса и лимит в десять запросов.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Спецификация DKIM, охватывающая создание и проверку подписей.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Спецификация DMARC, включая синтаксис политик и формат агрегированных отчётов.
• Google Workspace: Prevent spoofing and spam — Практические рекомендации по настройке SPF, DKIM и DMARC для доменов Google Workspace.