Электронная почта: введение и начало работы

Эта статья объясняет, как работает электронная почта, какие DNS-записи используются для доставки и проверки писем и как подготовить домен к работе с Cloud24.kz.

Конкретные имена серверов, параметры подключения и DKIM-ключи необходимо получить при подключении услуги. RFC определяют правила работы протоколов, а параметры услуги определяет Cloud24.kz.

В учебных примерах используются домены example.com, .example и адреса из диапазонов, зарезервированных для документации. Заменяйте их своими значениями. Основание: RFC 2606, RFC 5737.

1. Основные протоколы электронной почты

SMTP — отправка и передача писем

SMTP — Simple Mail Transfer Protocol — используется для передачи электронной почты. Следует различать:

• Клиентскую отправку: почтовая программа передаёт письмо серверу отправки.
• Межсерверную передачу: почтовый сервер отправителя передаёт письмо серверу получателя.

Эти функции могут обслуживаться разными серверами и портами. Межсерверная передача обычно использует порт 25; клиентская отправка настраивается по параметрам почтового сервиса.

Основание: RFC 5321, RFC 6409, § 3.

IMAP — работа с почтой на сервере

IMAP — Internet Message Access Protocol — позволяет читать письма, управлять серверными папками и флагами сообщений, выполнять поиск и синхронизировать изменения с сервером.

Например, отметка о прочтении письма может отображаться на нескольких устройствах, подключённых к одному ящику. Сам IMAP не отправляет письма: для этого используется отдельный протокол отправки.

Основание: RFC 9051, § 1.

POP3 — получение писем

POP3 — Post Office Protocol, версия 3 — позволяет получать сообщения из почтового ящика.

Загрузка письма сама по себе не означает его удаления:

• RETR получает сообщение;
• DELE помечает сообщение для удаления;
• удаление помеченных сообщений выполняется в состоянии UPDATE после команды QUIT.

Будут ли письма оставаться на сервере, зависит от настроек клиента и политики сервера.

Основание: RFC 1939, §§ 5–6.

2. Что подготовить перед настройкой

До изменения DNS-записей:

1. Убедитесь, что у вас есть доступ к управлению DNS-зоной домена. Она может находиться у регистратора, хостинг-провайдера или отдельного DNS-провайдера.
2. Получите у Cloud24.kz действующие параметры услуги:
   • серверы MX и их приоритеты;
   • рекомендуемую SPF-политику;
   • DKIM-селектор и значение DNS-записи;
   • адрес веб-почты;
   • параметры подключения почтовых программ.
3. Создайте необходимые ящики, адреса и псевдонимы.
4. Составьте список всех систем, отправляющих письма от вашего домена: почта сотрудников, сайт, CRM, бухгалтерская система, сервис рассылок и другие приложения.
5. Сохраните текущие DNS-записи, особенно если переносите почту от другого провайдера.

Этот список понадобится для проверки всех разрешённых источников отправки.

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

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

Для электронной почты используются:

MX, SPF, DKIM и DMARC решают разные задачи. Для подключения услуги следует выполнить требования Cloud24.kz. Наличие этих записей само по себе не гарантирует доставку во входящие.

В формах управления DNS часто используются следующие обозначения:

• @ — корень текущей зоны, например example.com;
• относительное имя, например _dmarc, — имя внутри текущей зоны;
• полное имя — например _dmarc.example.com.

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

4. Настройка MX

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

Добавление записи

1. Откройте панель управления DNS-зоной.
2. Выберите тип MX.
3. Укажите домен, принимающий почту.
4. Введите имя сервера и приоритет из параметров подключения Cloud24.kz.

Например, если при подключении вам выдан сервер protectionmail-a.cloud24.kz с приоритетом 10, запись будет выглядеть так:

В поле сервера указывается доменное имя, без https://, номера порта или пути.

Приоритет серверов

Меньшее число означает более высокий приоритет:

Сервер с приоритетом 10 предпочтительнее сервера с приоритетом 20. Несколько MX не означают автоматического копирования писем на каждый сервер.

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

Основание: RFC 5321, § 5.1.

Имя сервера из MX должно разрешаться в адресные записи и не должно быть псевдонимом CNAME. Основание: RFC 2181, § 10.3.

5. Настройка SPF

SPF проверяет право IP использовать домен SMTP MAIL FROM/HELO, а не заголовка From.

Публикуйте одну TXT-запись v=spf1 для имени: несколько дают PermError. Дополняйте существующую политику.

Квалификаторы: + — Pass; - — Fail; ~ — Softfail; ? — Neutral. По умолчанию используется +. Окончательное решение принимает получатель.

redirect= — модификатор: передаёт проверку другому домену, если механизмы не совпали. Сочетание с ip4 и другими механизмами допустимо; наличие all делает redirect неиспользуемым. Расположение redirect в строке не определяет порядок проверки.

Лимит — 10 вычисляемых элементов, требующих DNS-поиска, включая вложенные; превышение даёт PermError.

Для двух серверов:

С дополнительным сервисом:

Если Cloud24 предписал передачу политики:

include требует опубликованной SPF-политики; имя SMTP-сервера само по себе для этого не подходит.

Основание: RFC 7208, §§ 2–6.

6. Настройка DKIM

DKIM — DomainKeys Identified Mail — связывает письмо с подписывающим доменом посредством цифровой подписи.

Отправляющая система:

1. Создаёт подпись закрытым ключом.
2. Добавляет заголовок DKIM-Signature.
3. Указывает подписывающий домен в параметре d= и селектор в s=.

Получатель находит открытый ключ в DNS и проверяет подпись.

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

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

Основание: RFC 6376, §§ 1 и 3.

Добавление записи

Получите у Cloud24.kz селектор и полный открытый ключ.

Например, при d=example.com и s=protectionmail-a:

Структура значения для RSA-ключа:

Текст в угловых скобках — обозначение поля, которое необходимо заменить. Закрытый ключ в DNS не публикуется.

Основание: RFC 6376, §§ 3.6.1–3.6.2.

Для RSA-подписей используется rsa-sha256; rsa-sha1 запрещён. RFC требует ключи не короче 1024 бит и рекомендует не короче 2048 бит. Основание: RFC 8301, §§ 3.1–3.2.

Если DNS-панель разбивает длинное TXT-значение на несколько строк, они должны оставаться частями одной записи и соединяться без добавленных пробелов. Основание: RFC 6376, § 3.6.2.2.

7. Настройка DMARC

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

DMARC проходит, если выполнено хотя бы одно условие:

• SPF прошёл, а проверенный домен MAIL FROM согласован с доменом From;
• DKIM прошёл, а подписывающий домен d= согласован с доменом From.

Успешной проверки для постороннего домена недостаточно. При пустом MAIL FROM SPF определяет идентификатор через HELO/EHLO.

По умолчанию используется мягкое согласование: допускаются домены с общим организационным доменом. Строгое согласование требует точного совпадения.

Основание: RFC 9989, §§ 3.2.4 и 4.4.

Начальная запись

Сначала создайте ящик для отчётов, затем добавьте:

Политики:

Окончательное решение принимает получатель. Даже p=none не гарантирует приём письма.

Основание: RFC 9989, §§ 4.5–4.7 и 6.7.

Отчёты

rua указывает адрес для агрегированных отчётов. Они содержат сведения об источниках отправки и результатах проверок, включая успешные и неуспешные. Для регулярного анализа удобно использовать обработчик XML-отчётов. Основание: RFC 9990, § 3.

Необязательный ruf запрашивает отчёты об отдельных сбоях. Адрес также задаётся URI:

Такие отчёты могут раскрывать сведения об отдельных сообщениях; их получение не гарантируется. Основание: RFC 9991, §§ 2 и 7.

Для отправки отчётов на внешний домен требуется подтверждение со стороны получателя отчётов. Используйте DNS-настройки, предоставленные сервисом отчётности. Основание: RFC 9990, § 4, RFC 9991, § 5.

Переход к ограничениям

Начните с p=none, соберите отчёты и исправьте настройки всех легитимных отправителей. После проверки можно переходить к quarantine или reject.

Основание: RFC 9989, §§ 5.1.4–5.1.7.

8. Подключение почтовой программы

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

Стандартные варианты защищённого подключения:

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

Основание: RFC 8314, §§ 3.1–3.3, RFC 6409, § 3.1.

Используйте TLS версии 1.2 или выше и проверку сертификата сервера. Ошибку сертификата следует устранить, проверив имя сервера и параметры подключения. Основание: RFC 8997, § 3.

9. Проверка после настройки

Проверка DNS

Проверьте записи по полным именам:

Сравните ответы DNS с сохранёнными значениями. Проверьте, что панель не добавила имя зоны дважды.

Проверка почты

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

В технических заголовках полученного письма сервер получателя может указать результаты в Authentication-Results, например:

Оценивайте результаты, добавленные доверенным сервером получателя: одно лишь наличие такого заголовка не доказывает успешную проверку. Основание: RFC 8601, §§ 2 и 7.

Прохождение проверок подтверждает отдельные свойства сообщения, но не гарантирует его помещение во входящие. Получатель также применяет собственные правила фильтрации. Основание: RFC 9989, § 6.7.

10. Срок применения изменений DNS

Изменения не становятся видимыми всем получателям одновременно.

TTL определяет, как долго DNS-ответ может храниться в кеше. Если ранее запись отсутствовала, ответ об отсутствии также может быть закеширован. Поэтому универсального срока «до 48 часов» нет.

Основание: RFC 1035, § 3.2.1, RFC 2308, § 5.

При плановом переносе почты:

1. Заранее проверьте текущие TTL и при необходимости уменьшите их.
2. Учтите: уменьшение TTL не сокращает срок хранения ответов, уже попавших в кеш.
3. Подготовьте новые ящики и отправляющие системы до переключения MX.
4. Согласуйте период параллельной работы старого и нового сервиса.
5. После переключения проверьте доставку и отчёты.
6. Удалите настройки прежнего провайдера, когда он перестанет участвовать в приёме и отправке почты.

11. Если письма не отправляются или не приходят

Для обращения в поддержку подготовьте:

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

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