> 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/knowledge-base/uvedomleniya-i-integracii/notification-center/email/email-domain-authentication.md).

# SPF, DKIM и DMARC для почты

SPF, DKIM и DMARC для почтового домена без конфликтующих DNS-записей

SMTP-пароль или API-ключ разрешает iEXExchanger передать письмо провайдеру. SPF, DKIM и DMARC помогают принимающей стороне проверить, что провайдер действительно вправе отправлять письма от вашего домена.

Эти записи создаются не в iEXExchanger. Их добавляет технический специалист в действующую DNS-зону домена: REG.RU, Namecheap, GoDaddy, Cloudflare или у другого DNS-провайдера.

## Что означает каждая запись

| Механизм | Что проверяет                                                                               |
| -------- | ------------------------------------------------------------------------------------------- |
| SPF      | Какие серверы и сервисы могут отправлять почту от домена                                    |
| DKIM     | Подписано ли письмо ключом выбранного почтового сервиса и не изменено ли оно после отправки |
| DMARC    | Что делать, если проверки домена не проходят, и куда отправлять отчёты                      |

## Перед изменением DNS

1. Определите действующую DNS-зону по авторитетным NS-записям.
2. Составьте список всех сервисов, которые уже отправляют письма от домена.
3. Откройте кабинет нового почтового провайдера и получите записи именно для нужного домена или поддомена.
4. Сохраните текущие DNS-записи и подготовьте способ отката.
5. Не изменяйте MX, если перенос входящей почты не входит в задачу.

{% hint style="danger" %}
У домена должна быть одна итоговая SPF-запись. Если почту отправляют несколько сервисов, объедините разрешённые механизмы в одной записи по их официальным инструкциям. Две отдельные SPF-записи могут привести к ошибке проверки.
{% endhint %}

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

{% stepper %}
{% step %}

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

Скопируйте имя и значение записи из кабинета провайдера без изменений. Учтите, что DNS-панель может автоматически дописывать имя домена.
{% endstep %}

{% step %}

### Обновите SPF

Если SPF уже существует, не создавайте вторую запись. Добавьте новый разрешённый механизм в существующую итоговую политику и сохраните единственный завершающий `all`.
{% endstep %}

{% step %}

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

Начните с политики, согласованной владельцем домена. Для нового домена сначала соберите отчёты, проверьте всех законных отправителей и только затем вводите более строгую политику.
{% endstep %}

{% step %}

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

Откройте домен в кабинете почтового сервиса и дождитесь подтверждения всех обязательных записей. Не ориентируйтесь только на то, что запись видна в одной DNS-панели.
{% endstep %}

{% step %}

### Выполните тест из iEXExchanger

Откройте **«Настройки» — «Общие настройки» — «Уведомления» — «Подключения»**, отправьте тест и проверьте результаты SPF, DKIM и DMARC в технических заголовках полученного письма.
{% endstep %}
{% endstepper %}

## Собственный домен и поддомен

Транзакционную отправку можно вынести на отдельный поддомен. Это отделяет настройки и репутацию системных сообщений от основной корпоративной почты. Адрес в поле «E-mail отправителя» должен принадлежать подтверждённому домену или поддомену.

Если входящая почта остаётся в Zoho, Google, Яндексе или другом сервисе, не заменяйте её MX-записи только ради исходящей отправки через Resend или другой транзакционный сервис.

## Что проверить после изменения

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

Для значений используйте только кабинет и официальную документацию текущего провайдера: [Zoho](https://www.zoho.com/mail/help/adminconsole/spf-configuration.html), [Google Workspace](https://support.google.com/a/answer/33786?hl=ru), [Яндекс 360](https://yandex.ru/support/yandex-360/business/admin/ru/domains), [Resend](https://resend.com/docs/dashboard/domains/introduction).


---

# 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/knowledge-base/uvedomleniya-i-integracii/notification-center/email/email-domain-authentication.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.