Почтовый домен и DNS

Спроектируйте почтовые адреса, домен и DNS до ввода SMTP-пароля или API-ключа

Что вы получите

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

Разделите три роли E-mail

Роль	Где задаётся	Пример назначения
Адрес поддержки	«Общие параметры»	Клиент отвечает или обращается за помощью
Адреса администраторов	«Общие параметры»	Команда получает служебные события
Адрес и имя отправителя	В каждом SMTP/Resend-подключении	Письмо приходит от имени обменного пункта

Эти значения могут совпадать, но система использует их по-разному. Адрес поддержки не становится отправителем автоматически.

Выберите схему

Только Zoho

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

Только Resend

Resend отправляет транзакционные письма через API. Для ответов клиентов всё равно нужен реально принимающий адрес у почтового провайдера.

Zoho + Resend

Zoho принимает письма на основном домене, а Resend отправляет с отдельного поддомена, например notify.example.com. Такая схема уменьшает конфликт DNS и разделяет репутацию корпоративной и транзакционной почты.

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

Что означают записи DNS

Запись	Для чего нужна	Главное правило
MX	Приём входящей почты или служебный return-path по инструкции провайдера	Копировать только значения выбранного сервиса
SPF	Разрешает серверам отправлять от имени домена	На одном имени домена должна быть одна итоговая SPF-запись
DKIM	Подписывает письмо ключом домена	Имя селектора и значение выдаёт провайдер
DMARC	Задаёт политику проверки и адрес отчётов	Начинать с наблюдения и усиливать после анализа отчётов

Не придумывайте DNS-значения и не копируйте их с чужого домена. Zoho, Resend и другие провайдеры показывают записи для конкретного аккаунта, домена и дата-центра.

Подготовьте домен

1

Зафиксируйте отправителя

Выберите адрес вроде [e-mail] и понятное имя компании. Адрес должен быть разрешён провайдером; желательно, чтобы ответы на него не терялись.

2

Решите, кто принимает ответы

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

3

Добавьте домен у провайдера

Получите индивидуальные записи проверки, SPF и DKIM. Для Zoho отдельно настройте MX, если он принимает вашу почту.

4

Объедините SPF без дубля

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

5

Добавьте DKIM и DMARC

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

6

Дождитесь проверки

Обновите статус домена в панели провайдера после распространения DNS. Время зависит от TTL и DNS-хостинга; обещать фиксированную минуту нельзя.

Безопасная модель доступа

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

Как проверить основу до iEXExchanger

1. Панель провайдера показывает домен как подтверждённый.
2. SPF и DKIM не имеют ошибок.
3. Контрольный ящик получает обычное письмо от выбранного отправителя.
4. Ответ на письмо приходит в службу поддержки.
5. Письмо проверено минимум в двух независимых почтовых системах.
6. В заголовках полученного письма SPF, DKIM и DMARC показывают ожидаемый результат.

Подробные правила: SPF в Zoho, DKIM в Zoho, DMARC в Zoho и домены Resend.

Этап завершён, если

• адрес поддержки, административные получатели и отправитель не перепутаны;
• выбран основной домен или отдельный поддомен отправки;
• домен принадлежит компании;
• нет двух SPF-записей на одном hostname;
• DKIM подтверждён;
• DMARC введён контролируемо;
• ответы клиентов приходят в рабочий ящик;
• секреты и доступ к DNS распределены безопасно.

Если используете корпоративный ящик, переходите к Zoho Mail через SMTP. Для транзакционного API откройте Resend.