DNS-записи для электронной почты: полное руководство по MX, SPF, DKIM и DMARC

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

Для любого, кто занимается email-маркетингом, продажами или даже просто профессиональным общением, понимание и правильная настройка этих записей не является чем-то необязательным — это основа. Неправильно настроенные или отсутствующие DNS-записи могут привести к низким показателям доставляемости, попаданию писем в спам и ухудшению репутации отправителя. Это руководство содержит полную информацию о записях MX, SPF, DKIM, DMARC, BIMI и MTA-STS, которые имеют решающее значение для надежной доставляемости электронной почты, особенно в требовательном мире холодных рассылок.

Что такое DNS-записи для электронной почты и почему они важны для холодных рассылок?

DNS (Domain Name System) часто называют «телефонной книгой интернета». Когда вы отправляете электронное письмо, почтовый сервер получателя обращается к DNS-записям вашего домена, чтобы проверить легитимность отправителя и определить, как маршрутизировать сообщение. Для холодных рассылок, где доверие имеет первостепенное значение, а первоначальное вовлечение низкое, эти проверки критически важны. Правильная настройка DNS для электронной почты гарантирует, что ваши сообщения минуют спам-фильтры и попадут во входящие, напрямую влияя на показатели открытий, ответов и общий успех кампании.

Без корректных DNS-записей для холодных рассылок ваши сообщения с большой вероятностью будут помечены как спам или полностью отклонены. Это не только сводит на нет ваши усилия, но также может привести к попаданию вашего домена в черный список, что еще больше усложнит будущие рассылки. Ключевые записи, такие как SPF, DKIM и DMARC, являются механизмами аутентификации, которые подтверждают, что ваши электронные письма действительно отправлены с вашего домена и не были подделаны.

Настройка записи MX: маршрутизация входящей почты на ваш сервер

Запись MX (Mail Exchanger) — это фундаментальная DNS-запись, которая указывает, какие почтовые серверы отвечают за прием электронных сообщений от имени вашего домена и куда их маршрутизировать. Когда кто-то отправляет электронное письмо на ваш домен (например, [email protected]), почтовый сервер отправителя запрашивает MX-записи вашего домена, чтобы найти правильный сервер для доставки сообщения.

Как работают записи MX

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

Настройка ваших MX-записей

Большинство поставщиков услуг электронной почты (Gmail, Outlook, Zoho и т. д.) предоставят вам конкретные MX-записи для добавления. Обычно вам нужно добавить несколько записей, каждая с разным приоритетом. Вы можете проверить свои MX-записи, чтобы убедиться, что они настроены правильно.

Примеры конфигураций MX-записей

Вот распространенные примеры для популярных DNS-провайдеров:

Общая структура записи MX

Record Type: MX
Name/Host: @ or yourdomain.com
Value/Points to: mail.yourserver.com
Priority: 10 (or as specified)
TTL: Auto or 3600 seconds

Пример Google Workspace (Gmail)

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

Record Type: MX
Name/Host: @
Value/Points to: ASPMX.L.GOOGLE.COM.
Priority: 1
TTL: Auto

Record Type: MX
Name/Host: @
Value/Points to: ALT1.ASPMX.L.GOOGLE.COM.
Priority: 5
TTL: Auto

Record Type: MX
Name/Host: @
Value/Points to: ALT2.ASPMX.L.GOOGLE.COM.
Priority: 5
TTL: Auto

Record Type: MX
Name/Host: @
Value/Points to: ALT3.ASPMX.L.GOOGLE.COM.
Priority: 10
TTL: Auto

Record Type: MX
Name/Host: @
Value/Points to: ALT4.ASPMX.L.GOOGLE.COM.
Priority: 10
TTL: Auto

Пример Cloudflare (добавление MX-записей)

В Cloudflare вам нужно перейти в настройки DNS и добавить эти записи:

Type: MX
Name: @
Mail server: ASPMX.L.GOOGLE.COM
Priority: 1
TTL: Auto

Type: MX
Name: @
Mail server: ALT1.ASPMX.L.GOOGLE.COM
Priority: 5
TTL: Auto
... (and so on for other Google Workspace MX records)

Пример GoDaddy (добавление MX-записей)

В управлении DNS GoDaddy вы добавите новые MX-записи:

Type: MX
Host: @
Points to: ASPMX.L.GOOGLE.COM
Priority: 1
TTL: 1 Hour
... (and so on for other Google Workspace MX records)

Запись SPF: авторизация ваших отправителей и предотвращение спуфинга

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

Как работает SPF

Когда принимающий почтовый сервер получает электронное письмо от вашего домена, он выполняет проверку SPF. Он ищет SPF-запись вашего домена и сравнивает отправляющий IP-адрес со списком авторизованных отправителей. Если IP-адрес не указан, письмо может быть помечено как спам или отклонено. Для холодных рассылок действительная SPF-запись имеет решающее значение для установления первоначального доверия и улучшения доставляемости.

Синтаксис и механизмы записи SPF

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

• v=spf1: Указывает версию SPF.
• a: Авторизует IP-адрес A-записи домена.
• mx: Авторизует IP-адреса MX-записей домена.
• ip4 / ip6: Авторизует конкретные IPv4 или IPv6 адреса/диапазоны.
• include: Включает SPF-запись другого домена (например, вашего поставщика услуг электронной почты).
• exists: Авторизует на основе поиска A-записи.
• redirect: Указывает на SPF-запись другого домена.
• all: Определяет политику по умолчанию для отправителей, не соответствующих предыдущим механизмам.
  • -all (Hard Fail): Письма от неавторизованных отправителей должны быть отклонены. Рекомендуется для строгой политики.
  • ~all (Soft Fail): Письма от неавторизованных отправителей должны быть приняты, но помечены как подозрительные. Часто используется для первоначальной настройки.
  • ?all (Neutral): Политика не указана. Используется редко, так как не обеспечивает защиты.

Распространенные ошибки SPF

• Несколько SPF-записей: Домен должен иметь только одну SPF TXT-запись. Несколько записей приведут к сбоям аутентификации.
• Слишком много запросов: SPF-записи имеют ограничение в 10 запросов. Каждый механизм include, a, mx, ptr и exists считается одним запросом. Превышение этого лимита приведет к сбою SPF.
• Отсутствующие отправители: Забыв включить все ваши сервисы отправки (например, вашу платформу для холодных рассылок, поставщика транзакционных email-сообщений, CRM), вы приведете к тому, что легитимные письма не пройдут проверку SPF.

Примеры конфигураций SPF-записей

Вы можете проверить свою SPF-запись, чтобы выявить проблемы.

Базовая SPF-запись (отправка с вашего веб-сервера)

Record Type: TXT
Name/Host: @ or yourdomain.com
Value/Points to: "v=spf1 a mx -all"
TTL: Auto or 3600 seconds

SPF для Google Workspace

Record Type: TXT
Name/Host: @
Value/Points to: "v=spf1 include:_spf.google.com ~all"
TTL: Auto

SPF для SendGrid

Record Type: TXT
Name/Host: @
Value/Points to: "v=spf1 include:sendgrid.net -all"
TTL: Auto

Комбинированный SPF (например, Google Workspace + SendGrid + Postigo)

Record Type: TXT
Name/Host: @
Value/Points to: "v=spf1 include:_spf.google.com include:sendgrid.net include:postigo.net -all"
TTL: Auto

Примечание: Всегда стремитесь к -all (жесткий отказ), как только вы убедитесь, что все ваши легитимные источники отправки включены. Начните с ~all (мягкий отказ) во время тестирования.

Запись DKIM: цифровая подпись ваших писем для обеспечения целостности и аутентификации

DKIM (DomainKeys Identified Mail) — это еще один критически важный метод аутентификации электронной почты, который позволяет отправителю ставить цифровую подпись на исходящих письмах. Эта подпись проверяется принимающими почтовыми серверами, подтверждая, что письмо не было изменено в процессе передачи и что оно действительно исходит от заявленного домена.

Как работает DKIM

Когда отправляется электронное письмо, отправляющий сервер генерирует уникальную криптографическую подпись на основе содержимого письма (заголовков и тела). Эта подпись добавляется в заголовок письма. Публичная часть криптографического ключа публикуется в DNS вашего домена в виде TXT-записи. Принимающий сервер использует этот публичный ключ для расшифровки подписи и проверки ее подлинности. Если подпись совпадает, письмо аутентифицировано; в противном случае это указывает на подделку или спуфинг.

Настройка ваших DKIM-записей

В отличие от SPF, вы обычно не создаете ключ DKIM вручную. Ваш поставщик услуг электронной почты (ESP) или платформа для холодных рассылок (например, Postigo.net) сгенерирует уникальный ключ DKIM (длинную строку символов) для вашего домена. Затем вы добавляете этот ключ в виде TXT-записи в настройки DNS. Каждая запись DKIM использует «селектор» (например, s1, default или уникальную строку, предоставленную вашим ESP), который является частью имени записи.

Примеры конфигураций DKIM-записей

Общая структура записи DKIM

Record Type: TXT
Name/Host: selector._domainkey.yourdomain.com
Value/Points to: "v=DKIM1; k=rsa; p=MIGfMA0GC...[long alphanumeric string]...IDAQAB"
TTL: Auto or 3600 seconds

Пример DKIM для Google Workspace

Google предоставит вам конкретный селектор (например, google._domainkey) и длинный ключ.

Record Type: TXT
Name/Host: google._domainkey
Value/Points to: "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...[long key provided by Google]...QIDAQAB"
TTL: Auto

Пример DKIM для SendGrid

SendGrid обычно предоставляет две CNAME-записи для настройки DKIM, что упрощает процесс, указывая на собственные DKIM-ключи SendGrid.

Record Type: CNAME
Name/Host: s1._domainkey.yourdomain.com
Value/Points to: s1.domainkey.uXXXXXXX.wlX.sendgrid.net
TTL: Auto

Record Type: CNAME
Name/Host: s2._domainkey.yourdomain.com
Value/Points to: s2.domainkey.uXXXXXXX.wlX.sendgrid.net
TTL: Auto

Замените uXXXXXXX.wlX на конкретные значения, предоставленные SendGrid в процессе верификации вашего домена.

Запись DMARC: применение политики для аутентификации электронной почты

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

Как работает DMARC

DMARC предоставляет инструкции принимающим почтовым серверам о том, как обрабатывать письма, которые заявляют, что они от вашего домена, но не прошли аутентификацию SPF или DKIM. Он также вводит концепцию «выравнивания» (alignment), означающую, что домен в заголовке «From» должен соответствовать домену, аутентифицированному SPF или DKIM. Для холодных рассылок DMARC имеет решающее значение для защиты репутации вашего бренда и получения информации о потенциальных попытках спуфинга.

Типы политик DMARC

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

Отчетность DMARC

Записи DMARC включают адреса для отчетов (rua для агрегированных отчетов и ruf для криминалистических отчетов), которые предоставляют ценные данные о том, кто отправляет электронную почту с вашего домена и как она аутентифицируется.

Внедрение DMARC

Типичная стратегия внедрения DMARC включает:

1. Начните с p=none для мониторинга и убедитесь, что все легитимные источники отправки проходят SPF/DKIM.
2. Постепенно переходите к p=quarantine (например, 5-10% писем) после анализа отчетов.
3. В конечном итоге внедрите p=reject (100% писем) для максимальной защиты, как только вы будете полностью уверены (обычно 95-100% легитимных писем проходят SPF/DKIM).

Примеры конфигураций DMARC-записей

Базовый DMARC (режим мониторинга)

Record Type: TXT
Name/Host: _dmarc.yourdomain.com
Value/Points to: "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]"
TTL: Auto

Замените [email protected] на реальный адрес электронной почты для получения отчетов.

DMARC с политикой карантина

Record Type: TXT
Name/Host: _dmarc.yourdomain.com
Value/Points to: "v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]"
TTL: Auto

pct=100 означает, что 100% писем, не прошедших DMARC, будут помещены в карантин. Вы можете использовать более низкий процент (например, pct=10) для постепенного внедрения.

DMARC с политикой отклонения

Record Type: TXT
Name/Host: _dmarc.yourdomain.com
Value/Points to: "v=DMARC1; p=reject; rua=mailto:[email protected]"
TTL: Auto

За пределами основных: BIMI и MTA-STS для повышения доверия

Хотя MX, SPF, DKIM и DMARC являются основными, BIMI и MTA-STS предлагают дополнительные уровни доверия к бренду и безопасности, что особенно ценно для профессиональной электронной переписки и холодных рассылок.

BIMI (Brand Indicators for Message Identification): отображение вашего логотипа

BIMI позволяет отображать логотип вашего бренда рядом с вашим электронным письмом в поддерживающих почтовых ящиках (таких как Gmail, Yahoo!, Apple Mail). Это значительно повышает узнаваемость бренда и доверие получателей, выделяя ваши холодные письма. Для внедрения BIMI ваш домен должен иметь политику DMARC p=quarantine или p=reject, а ваш логотип должен быть Verified Mark Certificate (VMC), выданным доверенным центром сертификации.

Пример конфигурации записи BIMI

Record Type: TXT
Name/Host: default._bimi.yourdomain.com
Value/Points to: "v=BIMI1; l=https://yourdomain.com/your-logo.svg; a=https://yourdomain.com/your-vmc.pem"
TTL: Auto

l указывает на ваш SVG-файл логотипа, а a указывает на ваш файл VMC-сертификата. VMC требуется для отображения логотипа в большинстве основных почтовых ящиков.

MTA-STS (Mail Transfer Agent Strict Transport Security): зашифрованная электронная почта

MTA-STS — это стандарт безопасности, который гарантирует, что электронная почта, отправляемая между поддерживающими почтовыми серверами, всегда зашифрована, защищая от прослушивания и атак типа «человек посередине». Он работает путем наличия DNS TXT-записи, которая объявляет о поддержке вашим доменом MTA-STS и указывает на файл политики, размещенный на вашем веб-сервере через HTTPS.

Пример конфигурации записи MTA-STS

Сначала создайте файл политики (например, mta-sts.txt) и разместите его по адресу https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: yourdomain.com
mx: mail.yourdomain.com
max_age: 604800

Затем добавьте следующую DNS TXT-запись:

Record Type: TXT
Name/Host: _mta-sts.yourdomain.com
Value/Points to: "v=STSv1; id=202308151030"
TTL: Auto

Значение id должно быть уникальной строкой (например, датой и временем), которая меняется при каждом обновлении файла политики mta-sts.txt.

Сравнение DNS-записей для электронной почты

Понимание различных ролей каждой записи является ключом к надежной конфигурации DNS для электронной почты. Вот краткое сравнение:

Лучшие практики настройки DNS для электронной почты и холодных рассылок

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

1. Проверяйте все источники отправки: Убедитесь, что каждая платформа, которая отправляет электронную почту от имени вашего домена (ваш ESP, CRM, инструмент автоматизации маркетинга, платформа для холодных рассылок, такая как Postigo.net, и т. д.), включена в вашу SPF-запись и имеет собственную настроенную DKIM. Отсутствие даже одного может привести к проблемам с доставляемостью.
2. Регулярно отслеживайте отчеты DMARC: Отчеты DMARC (отправляемые на ваш адрес rua) предоставляют бесценные данные о том, кто отправляет электронную почту с вашего домена и как она аутентифицируется. Используйте инструмент DMARC-аналитики для легкой интерпретации этих XML-отчетов. Стремитесь к тому, чтобы 100% легитимных писем проходили SPF и DKIM.
3. Начинайте DMARC с p=none: Никогда не переходите сразу к p=reject. Начните с p=none, анализируйте отчеты в течение нескольких недель или месяцев, и только затем постепенно повышайте свою политику до p=quarantine и, наконец, до p=reject, как только вы будете уверены в отсутствии легитимных сбоев.
4. Держите SPF-записи краткими: Соблюдайте лимит в 10 запросов для SPF. Объединяйте операторы include, где это возможно. Если у вас много сервисов, рассмотрите возможность использования выделенного поддомена для некоторых отправок.
5. Используйте выделенный поддомен для холодных рассылок: Для холодных рассылок рассмотрите возможность использования отдельного поддомена (например, outreach.yourdomain.com) с собственным набором записей SPF, DKIM и DMARC. Это изолирует любые потенциальные проблемы с доставляемостью от вашего основного домена (yourdomain.com), защищая репутацию вашего основного бренда.
6. Внедрите BIMI для доверия к бренду: Как только ваша политика DMARC будет на уровне p=quarantine или p=reject, займитесь BIMI. Визуальный сигнал доверия в виде вашего логотипа во входящих может значительно повысить вовлеченность в холодные письма.
7. Регулярно проверяйте свои записи: Распространение DNS может занять время (до 48 часов), но крайне важно убедиться, что ваши записи активны и корректны. Используйте такие инструменты, как проверка MX, проверка SPF и другие инструменты для электронной почты от Postigo, чтобы убедиться, что все в порядке.
8. Отслеживайте попадание в черный список: Даже при идеальной настройке DNS ваш домен может быть занесен в черный список из-за содержимого или практики отправки. Регулярно используйте проверку черного списка, чтобы убедиться, что ваш домен остается чистым.

Основные выводы

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