> For the complete documentation index, see [llms.txt](https://docs.iexexchanger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.iexexchanger.com/learn/email/04-email-foundation.md).

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

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

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

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

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

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

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

{% tabs %}
{% tab title="Только Zoho" %}
Zoho принимает корпоративную почту и отправляет уведомления через SMTP. Подходит для небольшого потока и единой почтовой инфраструктуры.
{% endtab %}

{% tab title="Только Resend" %}
Resend отправляет транзакционные письма через API. Для ответов клиентов всё равно нужен реально принимающий адрес у почтового провайдера.
{% endtab %}

{% tab title="Zoho + Resend" %}
Zoho принимает письма на основном домене, а Resend отправляет с отдельного поддомена, например `notify.example.com`. Такая схема уменьшает конфликт DNS и разделяет репутацию корпоративной и транзакционной почты.
{% endtab %}
{% endtabs %}

{% hint style="info" %}
Поддомен для транзакционной отправки — рекомендация, а не обязательное имя. Используйте домен, которым владеет компания, и зафиксируйте, кто управляет его DNS.
{% endhint %}

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

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

{% hint style="danger" %}
Не придумывайте DNS-значения и не копируйте их с чужого домена. Zoho, Resend и другие провайдеры показывают записи для конкретного аккаунта, домена и дата-центра.
{% endhint %}

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

{% stepper %}
{% step %}

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

Выберите адрес вроде `notify@your-domain.example` и понятное имя компании. Адрес должен быть разрешён провайдером; желательно, чтобы ответы на него не терялись.
{% endstep %}

{% step %}

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

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

{% step %}

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

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

{% step %}

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

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

{% step %}

### Добавьте DKIM и DMARC

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

{% step %}

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

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

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

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

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

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

Подробные правила: [SPF в Zoho](https://www.zoho.com/mail/help/adminconsole/spf-configuration.html), [DKIM в Zoho](https://www.zoho.com/mail/help/adminconsole/dkim-configuration.html), [DMARC в Zoho](https://www.zoho.com/mail/help/adminconsole/dmarc-policy.html) и [домены Resend](https://resend.com/docs/dashboard/domains/introduction).

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

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

Если используете корпоративный ящик, переходите к [Zoho Mail через SMTP](/learn/email/05-email-zoho.md). Для транзакционного API откройте [Resend](/learn/email/06-email-resend.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.iexexchanger.com/learn/email/04-email-foundation.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.