Верификация домена отправителя для email-рассылок

Перед отправкой массовых или транзакционных писем со своего домена его обычно необходимо подтвердить в сервисе email-рассылок.

Этот процесс называют верификацией домена отправителя, подтверждением домена или аутентификацией отправителя.

Например, компания хочет отправлять письма с адреса:

news@company.ru

Сервису рассылок недостаточно просто разрешить пользователю указать company.ru в поле «От кого». Иначе любой клиент сервиса смог бы отправлять письма от имени чужих компаний.

Поэтому владелец домена подтверждает контроль над ним через DNS и настраивает необходимые записи.

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

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

Что такое верификация домена отправителя

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

Обычно подтверждение выполняется через DNS.

Сервис предоставляет специальную запись, которую необходимо добавить в настройки домена.

После этого сервис делает DNS-запрос.

Если нужное значение найдено, домен считается подтверждённым.

Упрощённо процесс выглядит так:

добавили домен в сервис → получили DNS-записи → разместили их в DNS → сервис проверил записи → домен подтверждён

На практике одновременно с подтверждением права владения часто выполняется настройка аутентификации почты: DKIM, SPF и других технических параметров.

Зачем подтверждать домен перед рассылкой

Главная задача — не позволить одному пользователю отправлять письма от имени чужого домена.

Представим, что сервис разрешает без проверки указать отправителем:

support@bank.ru

или:

orders@shop.ru

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

Верификация усложняет такую подмену.

Но у неё есть и вторая задача — подготовить нормальную техническую инфраструктуру отправителя.

При правильной настройке почтовые серверы могут проверить:

• кто отправляет письмо;
• разрешена ли эта инфраструктура владельцем домена;
• действительно ли сообщение подписано доменом;
• соответствует ли аутентифицированный домен адресу в поле From.

Для этого применяются SPF, DKIM и DMARC.

Подробнее о каждом механизме читайте в статье «SPF, DKIM и DMARC: что это и зачем нужны для email-рассылок».

Верификация домена и SPF, DKIM, DMARC — не одно и то же

Эти понятия часто смешивают.

Верификация домена подтверждает право пользователя управлять доменом или использовать его в конкретном сервисе.

SPF, DKIM и DMARC отвечают за аутентификацию отправляемых сообщений.

Можно представить так:

Верификация

Отвечает на вопрос:

Вы действительно контролируете этот домен?

SPF

Отвечает на вопрос:

Разрешён ли этот сервер для отправки почты от имени домена?

DKIM

Отвечает на вопрос:

Подписано ли сообщение ключом этого домена?

DMARC

Отвечает на вопрос:

Соответствует ли успешно прошедшая аутентификация домену, который пользователь видит в поле From?

Поэтому статус «Домен подтверждён» ещё не всегда означает, что вся инфраструктура email-аутентификации настроена идеально.

После верификации стоит обязательно проверить реальное письмо.

Какие DNS-записи могут потребоваться

Конкретный набор зависит от сервиса отправки.

Чаще всего используются:

• TXT;
• CNAME;
• SPF;
• DKIM;
• DMARC;
• записи для Return-Path или bounce-домена.

Не каждый сервис требует все эти записи одновременно.

Важно использовать только те значения, которые сервис показывает именно для вашего домена.

Не копируйте готовые SPF или DKIM из чужих инструкций.

TXT-запись для подтверждения домена

Самый простой способ доказать владение доменом — добавить уникальную TXT-запись.

Например, сервис может показать условное значение:

service-verification=ABC123XYZ

Владелец добавляет его в DNS.

После этого сервис проверяет:

существует ли у company.ru TXT-запись с этим значением?

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

Конкретное значение всегда уникально. Пример выше нельзя использовать для реального домена.

DKIM при верификации домена

Для профессиональной email-отправки одной TXT-записи подтверждения обычно недостаточно.

Особенно важен DKIM.

Сервис предоставляет DNS-запись с открытым ключом или CNAME, который ведёт к его инфраструктуре.

Например, DNS-имя может выглядеть примерно так:

selector._domainkey.company.ru

Слово selector в реальной конфигурации будет другим.

После настройки отправляемые сообщения получают DKIM-подпись.

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

SPF при подключении сервиса рассылок

SPF определяет, какой инфраструктуре разрешено отправлять почту от имени домена.

Если компания уже использует корпоративную почту, SPF может существовать до подключения email-рассылок.

Например, свой домен могут одновременно использовать:

• корпоративная почта;
• CRM;
• сайт;
• интернет-магазин;
• сервис email-маркетинга;
• система транзакционных уведомлений.

При подключении нового сервиса важно не создать случайно вторую независимую SPF-запись.

Для домена должна быть сформирована корректная единая SPF-политика.

Не создавайте две SPF-записи

Типичная ошибка выглядит так.

У домена уже есть:

v=spf1 ...

Пользователь подключает сервис рассылок и создаёт ещё одну отдельную запись:

v=spf1 ...

Получаются две SPF-политики.

Это неправильная конфигурация.

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

Нужен ли DMARC для верификации

Для самого подтверждения владения доменом DMARC может быть не нужен.

Но для нормально подготовленной почтовой инфраструктуры его стоит настроить.

DMARC связывает результаты SPF и DKIM с доменом, указанным пользователю в поле From.

Например:

From: newsletter@company.ru

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

Начальная политика DMARC нередко используется в режиме мониторинга:

p=none

Но выбирать конкретную политику нужно с учётом всей инфраструктуры домена.

Если корпоративная почта, сайт, CRM и другие системы ещё не учтены, слишком ранний переход к строгой политике может привести к блокировке собственных писем.

Как верифицировать домен: пошагово

Общий процесс почти всегда похож, независимо от выбранного сервиса рассылок.

Шаг 1. Определите домен отправителя

Сначала решите, с какого домена будут отправляться письма.

Например:

company.ru

Адрес отправителя может выглядеть так:

news@company.ru

hello@company.ru

orders@company.ru

Для регулярных бизнес-рассылок желательно использовать собственный домен, которым компания реально управляет.

Шаг 2. Добавьте домен в сервис рассылок

В настройках отправителя укажите домен, который хотите использовать.

После этого сервис сформирует список DNS-записей.

Это могут быть:

• TXT для подтверждения;
• DKIM;
• SPF;
• CNAME;
• дополнительные записи.

Не изменяйте значения самостоятельно.

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

Шаг 3. Определите, где управляется DNS

Это один из самых важных этапов.

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

Например:

• регистратор — одна компания;
• хостинг — другая;
• DNS — Cloudflare или отдельный DNS-провайдер.

Добавлять записи нужно там, где находятся авторитетные DNS-серверы домена, а не обязательно там, где вы покупали домен.

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

Как понять, где редактировать DNS

Посмотрите, какие NS-серверы используются доменом.

Они могут выглядеть примерно так:

ns1.provider.ru

ns2.provider.ru

или принадлежать DNS-платформе.

Именно сервис, управляющий этими NS, обычно является местом, где нужно создавать TXT, CNAME и другие записи.

Если вы не уверены, уточните у регистратора или администратора сайта:

Где сейчас находится DNS-зона моего домена?

Шаг 4. Добавьте записи

Откройте управление DNS-зоной.

Для каждой записи сервис обычно показывает:

• тип;
• имя или host;
• значение;
• иногда TTL.

Например:

Тип	Имя	Значение
TXT	@	значение подтверждения
CNAME	selector._domainkey	адрес сервиса
TXT	_dmarc	DMARC-политика

Это только пример структуры.

Реальные значения необходимо брать из своего личного кабинета.

Что означает символ @ в DNS

В интерфейсах DNS символ:

@

обычно означает корневой домен.

Для:

company.ru

запись с именем @ относится именно к:

company.ru

Но интерфейсы DNS отличаются.

Некоторые панели просят оставить поле пустым, другие автоматически подставляют домен.

Поэтому ориентируйтесь на инструкцию своего DNS-провайдера.

Нужно ли писать полный домен в поле «Имя»

Зависит от панели управления DNS.

Например, сервис просит добавить:

selector._domainkey.company.ru

Одна DNS-панель ожидает:

selector._domainkey

и сама добавляет .company.ru.

Другая может принимать полное имя.

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

selector._domainkey.company.ru.company.ru

Естественно, сервис такую запись не найдёт.

Это одна из самых распространённых причин неудачной верификации.

Шаг 5. Сохраните изменения

После добавления всех записей сохраните DNS-зону.

Проверьте, что значения действительно отображаются в списке записей.

Особенно внимательно смотрите:

• тип записи;
• host;
• значение;
• отсутствие лишних пробелов;
• отсутствие случайно повторённого домена.

Шаг 6. Подождите обновления DNS

DNS-записи не всегда становятся видимыми мгновенно.

Иногда изменение доступно через несколько минут, иногда требуется больше времени.

На скорость влияют:

• DNS-провайдер;
• TTL;
• кеширование;
• изменение NS;
• конкретный тип записи.

Поэтому статус «Не подтверждено» через 30 секунд после добавления DNS ещё не означает ошибку.

Сначала подождите и повторите проверку.

Шаг 7. Запустите проверку домена

Вернитесь в сервис email-рассылок и нажмите проверку или подтверждение домена.

Сервис выполнит DNS-запрос.

Если всё правильно, статус изменится, например, на:

Подтверждён

или:

Verified

Если отдельные записи не найдены, обычно сервис показывает, какой именно этап не пройден.

Шаг 8. Отправьте тестовое письмо

Это обязательный этап.

Статус «домен подтверждён» полезен, но конечная задача — не получить зелёную галочку в интерфейсе, а убедиться, что реальное сообщение корректно аутентифицируется.

Отправьте тест на внешний адрес.

После получения откройте технические заголовки письма.

Проверьте результаты:

spf=pass

dkim=pass

dmarc=pass

При необходимости также проверьте домены, которые использовались для этих механизмов.

Шаг 9. Проверьте письмо перед массовой отправкой

После настройки домена полезно сделать дополнительный технический тест.

Отдельная инструкция:

«Как проверить email-письмо на спам перед рассылкой».

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

Почему домен не подтверждается

Если сервис продолжает показывать статус ожидания или ошибку, почти всегда стоит начать с DNS.

Разберём типичные причины.

Запись добавлена не у того DNS-провайдера

Очень распространённая ситуация.

Пользователь купил домен у регистратора и добавил TXT именно там.

Но NS домена уже направлены, например, на другой DNS-хостинг.

В результате запись существует только в панели регистратора, но не публикуется в интернете.

Решение:

проверить авторитетные NS и редактировать реальную DNS-зону.

Неправильно указано имя записи

Сервис попросил:

selector._domainkey

а пользователь добавил:

selector._domainkey.company.ru

при этом панель автоматически дописала домен.

Получилась неправильная запись.

Проверьте итоговое DNS-имя с помощью внешнего DNS lookup.

Значение скопировано не полностью

DKIM-ключи и TXT-значения могут быть длинными.

При копировании можно случайно:

• потерять часть строки;
• добавить пробел;
• вставить перенос;
• изменить кавычки.

Лучше использовать кнопку копирования в сервисе, если она доступна.

Запись ещё не распространилась

Если всё добавлено правильно, но прошло всего несколько минут, возможно, нужно просто подождать.

Особенно это актуально после:

• изменения NS;
• переноса DNS;
• изменения старой кешируемой записи.

Создан неправильный тип записи

Например, сервис требует:

CNAME

а пользователь создаёт:

TXT.

Или наоборот.

Название записи при этом может выглядеть правильно, но сервис её не увидит в нужном DNS-типе.

Дублируется SPF

Если после подключения сервиса появилось две SPF-записи, настройка становится некорректной.

Проверьте все TXT-записи корневого домена, начинающиеся с:

v=spf1

Политика должна быть согласованной.

Старый DKIM остался после смены сервиса

Само по себе наличие старого DKIM не обязательно является проблемой.

Разные системы могут использовать разные selectors.

Например:

mail1._domainkey

service2._domainkey

newsletter._domainkey

Они могут существовать одновременно.

Проблема возникает, если новая система ожидает один selector, а в DNS опубликован другой или неправильный ключ.

CNAME включён через проксирование

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

Email-аутентификация должна получать ожидаемый DNS-ответ.

Если сервис рассылок не видит CNAME, проверьте настройки проксирования.

Нужно ли подтверждать каждый email-адрес отдельно

Это зависит от сервиса.

При доменной верификации обычно подтверждается право использовать определённый домен.

После этого могут быть доступны разные отправители на нём:

news@company.ru

sales@company.ru

events@company.ru

Но конкретные правила определяются платформой отправки.

Не следует автоматически считать, что верификация домена разрешает отправку от любого технически возможного адреса.

Адрес From должен быть реальным, контролируемым компанией и понятным получателям.

Можно ли отправлять рассылки с Gmail, Яндекс Почты или Mail.ru

Для профессиональных массовых рассылок лучше использовать адрес на собственном домене.

Например:

newsletter@company.ru

а не:

company123@gmail.com

или:

company@yandex.ru.

Главная причина — вы не управляете DNS доменов gmail.com, yandex.ru или mail.ru.

Следовательно, вы не можете самостоятельно настроить DKIM, SPF и DMARC этих доменов для сторонней инфраструктуры рассылок.

Собственный домен даёт компании контроль над аутентификацией и репутацией отправителя.

Нужно ли создавать отдельный поддомен для рассылок

Не всегда.

Можно отправлять маркетинговые сообщения непосредственно от:

news@company.ru.

Но при более сложной инфраструктуре иногда имеет смысл разделять потоки.

Например:

newsletter.company.ru

notify.company.ru

mail.company.ru

Это может быть удобно, если отдельно работают:

• массовый email-маркетинг;
• транзакционные сообщения;
• корпоративная почта;
• несколько независимых систем отправки.

Однако создание поддомена само по себе не решает проблему доставляемости.

Его всё равно необходимо правильно настроить и использовать последовательно.

Домен подтверждён, но письма попадают в спам

Верификация — только один элемент доставляемости.

Даже полностью подтверждённый домен может получать плохие результаты, если:

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

Подробнее:

«Почему письма попадают в спам и что с этим делать».

То есть:

подтверждённый домен — необходимая техническая основа, а не гарантия папки «Входящие».

Что проверить после верификации

После успешной настройки домена я бы не запускал сразу большую рассылку.

Сначала выполните несколько проверок.

SPF

Убедитесь, что реальное письмо показывает:

spf=pass

DKIM

Проверьте:

dkim=pass

и домен подписи.

DMARC

Проверьте:

dmarc=pass

Spam test

Проведите проверку письма перед отправкой.

Blacklist

Если домен или IP уже использовались для отправки, при необходимости проверьте их по инструкции:

«Как проверить домен и IP в чёрных списках email».

Postmaster

После начала регулярной отправки следите за репутационными сигналами.

Подробнее:

«Что такое Postmaster и зачем он нужен отправителю email-рассылок».

Почему верификация важна перед SMTP/API

Особенно внимательно к домену стоит относиться при автоматической отправке.

Через SMTP или API могут уходить:

• подтверждения регистрации;
• восстановление пароля;
• чеки;
• статусы заказа;
• уведомления;
• сервисные сообщения.

Такие письма пользователи часто ждут сразу после определённого действия.

Проблемы с доменной аутентификацией напрямую ухудшают надёжность этого канала.

Для программной отправки в QWERTYMAIL можно использовать SMTP и REST API.

Верификация домена не заменяет проверку базы

Настройка отправителя и качество получателей — две разные части одной системы.

Верифицированный домен не исправит:

• несуществующий email;
• опечатку в адресе;
• давно удалённый корпоративный ящик;
• устаревшую базу.

Если база давно не использовалась, перед массовой отправкой её можно проверить через валидатор email-адресов QWERTYMAIL.

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

Что делать после смены сервиса email-рассылок

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

Новый сервис может использовать:

• другой SPF;
• другой DKIM selector;
• другой Return-Path;
• другие CNAME.

При этом не стоит сразу удалять все старые записи.

Сначала выясните, используются ли они:

• корпоративной почтой;
• старой CRM;
• транзакционным сервисом;
• сайтом;
• другими приложениями.

После полного переноса ненужные настройки можно удалить.

Главное — не повредить рабочие источники почты.

Нужно ли удалять записи после отключения сервиса

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

Например, давно отключённый сервис может остаться в SPF годами.

Это:

• усложняет конфигурацию;
• затрудняет диагностику;
• увеличивает количество DNS lookup;
• оставляет ненужные разрешения.

Инфраструктура отправителя должна соответствовать реальной текущей архитектуре.

Чек-лист верификации домена

Перед первой массовой отправкой проверьте:

• используется собственный домен;
• вы знаете, где находится его DNS-зона;
• домен добавлен в сервис рассылок;
• все предоставленные DNS-записи добавлены;
• TXT подтверждения доступен;
• DKIM доступен;
• SPF не дублируется;
• DMARC настроен;
• сервис показывает домен как подтверждённый;
• тестовое письмо отправлено;
• SPF показывает pass;
• DKIM показывает pass;
• DMARC показывает pass;
• From содержит ожидаемый домен;
• выполнен spam test.

Только после этого имеет смысл переходить к регулярной отправке.

Частые вопросы

Что значит «верифицировать домен»?

Это означает подтвердить, что вы контролируете домен, от имени которого собираетесь отправлять email.

Обычно подтверждение выполняется с помощью записи в DNS.

Зачем сервис рассылок просит добавить TXT-запись?

TXT позволяет доказать контроль над DNS домена.

Сервис выдаёт уникальное значение, а пользователь публикует его в DNS.

Сколько времени занимает верификация домена?

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

В отдельных случаях распространение DNS занимает больше времени.

Почему сервис не видит TXT-запись?

Чаще всего запись добавлена не в ту DNS-зону, неправильно заполнено поле host либо изменение ещё не распространилось.

Нужно ли настраивать DKIM?

Для профессиональной отправки с собственного домена DKIM крайне желателен и является одной из базовых частей email-аутентификации.

Нужен ли SPF?

Да, если его требует используемая инфраструктура.

При этом нельзя создавать несколько независимых SPF-записей для одного домена.

Нужно ли настраивать DMARC?

Для современной инфраструктуры отправителя — да.

Он связывает результаты SPF/DKIM с видимым доменом From и позволяет управлять политикой обработки неаутентифицированных сообщений.

Можно ли просто скопировать SPF из этой статьи?

Нет.

DNS-записи должны соответствовать именно вашим сервисам и инфраструктуре.

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

Можно ли подтвердить домен без доступа к DNS?

Обычно нет.

Если вы не можете изменять DNS, обратитесь к владельцу домена, системному администратору или специалисту, который управляет DNS-зоной.

Гарантирует ли верификация попадание во «Входящие»?

Нет.

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

Связанные материалы

После настройки домена рекомендуем проверить остальные элементы инфраструктуры:

• SPF, DKIM и DMARC: что это и зачем нужны для email-рассылок
• Почему письма попадают в спам и что с этим делать
• Как проверить email-письмо на спам перед рассылкой
• Что такое Postmaster и зачем он нужен отправителю
• Как проверить домен и IP в чёрных списках
• SMTP и API для отправки email
• Валидатор email-адресов

Главное

Верификация домена отправителя — один из первых технических этапов перед профессиональной email-рассылкой.

Она подтверждает, что вы контролируете домен, и позволяет настроить нормальную аутентификацию сообщений.

Общий порядок выглядит так:

добавить домен → получить DNS-записи → разместить их у DNS-провайдера → подтвердить домен → отправить тестовое письмо → проверить SPF/DKIM/DMARC

При этом зелёный статус в интерфейсе сервиса — не конечная цель.

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

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