Перейти к содержанию

Глоссарий терминов

Краткие объяснения терминов, которые часто встречаются в документации Mailexam®, в переписке с разработчиками и при настройке почты. Текст рассчитан на джуниоров и менеджеров — без углубления в RFC и криптографию.

SMTP

SMTP (Simple Mail Transfer Protocol) — стандартный протокол передачи почты в интернете. Именно через SMTP ваше приложение «отдаёт» письмо на сервер отправки; дальше цепочка серверов доставляет его получателю (или, в тестовой среде, перехватывает в sandbox).

Простая аналогия

Представьте почтовое отделение:

В реальной почте В IT
Вы приносите конверт на стойку Приложение формирует письмо (тема, текст, вложения)
Сотрудник принимает отправление Приложение подключается к SMTP-серверу
Почта сортируется и везётся дальше SMTP-сервер передаёт письмо следующему узлу

Без SMTP (или его аналога) приложение не сможет отправить письмо наружу — только сформировать файл на диске.

Что обычно настраивают

При подключении к SMTP указывают хост, порт, логин и пароль. Типичные порты:

Порт Смысл (упрощённо)
587 Рекомендуемый: отправка с шифрованием (STARTTLS)
465 Отправка сразу по защищённому каналу (SMTPS)
25 Классический порт; часто блокируется хостингом и офисными сетями
2525 Альтернатива 25-му, если основной порт закрыт

В Mailexam® вы подключаете приложение к тестовому SMTP-серверу ({логин}.mailexam.ru) — письма попадают в ваш проект в кабинете, а не к реальным адресатам. Подробные шаги — в примерах интеграции.

Для менеджера

Если в задаче написано «настроить SMTP» — это почти всегда значит: дать разработчикам хост, порт, логин и пароль для отправки писем из приложения. Для Mailexam® эти данные выдаются при создании проекта.

Sandbox (песочница)

Sandbox в контексте почты — изолированная тестовая среда, куда уходят письма вместо реальных получателей. Это не «песочница» в смысле Docker или песочницы браузера: речь именно о безопасной отладке email.

Зачем нужен sandbox

Без sandbox С sandbox (Mailexam® и аналоги)
Тестовое письмо может уйти клиенту или на случайный адрес Письмо видно только вашей команде в тестовом ящике
Риск утечки токенов, паролей, персональных данных Можно гонять сценарии «как в проде», не боясь спама людям
Сложно автоматизировать проверки в CI/CD Есть API и единое место для всех писем теста

Sandbox ≠ продакшен

  • В продакшене SMTP ведёт на сервисы вроде SendGrid, Amazon SES, корпоративный Exchange — письма доставляются получателям.
  • В sandbox тот же код отправки часто не меняют: меняют только учётные данные SMTP (хост, логин, пароль) на тестовые.

Mailexam® — облачный sandbox для команд: разработка, QA, пайплайны CI/CD. Письма не уходят в интернет к реальным ящикам — они сохраняются в проекте, их можно смотреть в браузере и проверять через API.

SPF

SPF (Sender Policy Framework) — механизм в DNS, который указывает, с каких серверов разрешено отправлять почту от имени домена (например, company.com). Почтовый сервер получателя сверяет IP-адрес отправителя со списком в TXT-записи SPF.

Простая аналогия

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

Как это выглядит технически (без деталей)

  1. В DNS домена добавляют TXT-запись вида v=spf1 include:... -all — перечень разрешённых хостов и политика для остальных.
  2. При приёме письма сервер получателя проверяет, входит ли IP отправителя в эту запись.
  3. При несовпадении письмо чаще помечается как подозрительное, попадает в спам или отклоняется.

SPF дополняет DKIM и DMARC: SPF отвечает за «кто имеет право слать с этого IP», DKIM — за криптографическую подпись письма, DMARC — за политику при сбоях проверок.

Нужен ли SPF для Mailexam®?

Обычно нет. Mailexam® перехватывает тестовые письма в sandbox; проверка SPF у реальных получателей на доставку в кабинет не влияет. Настройка SPF (как DKIM и DMARC) важна, когда вы запускаете боевую рассылку с собственного домена. Проверить запись можно в инструментах SPF на сайте.

Для менеджера

Если в задаче на миграцию в sandbox спрашивают «надо ли менять SPF или DNS» — для Mailexam® и аналогов ответ «нет»: меняются только SMTP-учётные данные, записи домена отправителя не требуются. SPF понадобится позже, на этапе продакшен-SMTP.

DKIM

DKIM (DomainKeys Identified Mail) — механизм цифровой подписи исходящих писем от имени домена (например, company.com). Получающий почтовый сервер проверяет подпись и решает, доверять ли письму.

Простая аналогия

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

Как это выглядит технически (без деталей)

  1. В DNS домена добавляют специальную TXT-запись с публичным ключом.
  2. Почтовый сервер отправителя подписывает письмо при отправке.
  3. Сервер получателя проверяет подпись. При несовпадении письмо чаще попадает в спам или отклоняется.

DKIM часто используют вместе с SPF и DMARC — вместе они повышают доставляемость и защищают бренд от фишинга «от вашего имени».

Нужен ли DKIM для Mailexam®?

Обычно нет. Mailexam® предназначен для тестовой почты: письма перехватываются в sandbox и не идут к реальным получателям в интернете. Настройка DKIM, SPF и DMARC важна, когда вы запускаете боевую рассылку с собственного домена (маркетинг, транзакционные письма, уведомления клиентам). Проверить запись и сгенерировать ключ — в инструментах DKIM.

Для менеджера

Если разработчик говорит «в sandbox DKIM не настраиваем» — это нормально: для проверки шаблонов, ссылок и логики отправки в Mailexam® подпись домена не требуется. DKIM понадобится позже, на этапе продакшен-SMTP и работы с DNS.

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) — политика в DNS, которая говорит получателям, что делать, если проверки SPF и/или DKIM не прошли, и куда присылать отчёты о таких письмах.

Простая аналогия

SPF и DKIM — это проверка пропуска и печати на входе. DMARC — инструкция охраны: «если пропуск поддельный — не пускать в здание» или «положить в отдельную корзину и сообщить администратору».

Как это выглядит технически (без деталей)

  1. В DNS домена добавляют TXT-запись _dmarc с политикой (например, p=none, p=quarantine, p=reject).
  2. Получатель сверяет результат SPF/DKIM с заявленным доменом в поле From (с учётом выравнивания домена).
  3. При сбое применяется политика: письмо может доставиться как есть, уйти в карантин/спам или быть отклонено. На указанный адрес могут приходить агрегированные отчёты (кто шлёт от вашего имени).

Типичный путь внедрения: сначала p=none (только мониторинг отчётов), затем ужесточение до quarantine или reject, когда SPF и DKIM настроены стабильно.

Нужен ли DMARC для Mailexam®?

Обычно нет. В sandbox письма не проходят через боевую цепочку доставки с проверкой DMARC у реальных получателей. DMARC нужен на этапе продакшен-рассылки, когда домен уже защищён SPF и DKIM и вы хотите зафиксировать политику и видеть попытки подделки. Проверить политику — в инструментах DMARC.

Для менеджера

DMARC — не замена SPF/DKIM, а надстройка: без настроенных SPF и DKIM «включить DMARC» мало что даст. Для Mailexam® в разработке это не блокер; в проде за настройку обычно отвечает тот же специалист, что настраивает корпоративную почту или ESP (SendGrid, SES и т. п.).

Как термины связаны между собой

flowchart LR
    App[Ваше приложение] -->|SMTP| Sandbox[Тестовый сервер<br/>Mailexam]
    Sandbox --> Inbox[Письма в кабинете / API]
    Prod[Продакшен SMTP] -->|SPF + DKIM + DMARC| Internet[Реальные получатели]
Термин Роль в типичном процессе
SMTP Способ отправить письмо из кода
Sandbox Куда письмо попадает на этапе разработки
SPF Кто имеет право отправлять почту с вашего домена (по IP)
DKIM Как подписать письмо от имени домена
DMARC Что делать при сбое SPF/DKIM и куда слать отчёты

Дальше по теме