7 августа 2026 г.

Как принимать входящие письма, если SMTP-порты заблокированы

Вашему приложению нужно принимать электронную почту.

Возможно, вы разрабатываете службу поддержки, обрабатываете счета и документы, отслеживаете ответы клиентов или хотите создать уникальный email-адрес для каждого проекта, тикета или пользователя в своем SaaS.

Традиционный подход предполагает запуск собственного почтового сервера. Необходимо открыть порт 25, настроить MX-записи, установить Postfix или Exim, обрабатывать MIME-сообщения, проверять отправителей, сохранять вложения и постоянно следить за доступностью инфраструктуры.

Проблемы начинаются, когда хостинг-провайдер блокирует SMTP-трафик. Или когда команда понимает, что не хочет обслуживать публичный почтовый сервер ради одной функции продукта.

Практичная альтернатива — отделить прием почты от обработки данных приложением:

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

Функция входящей почты Fmailer построена именно по этой модели. Вы направляете MX-запись принимающего хоста на Fmailer, создаете маршруты для адресов и получаете разобранные письма через события inbound.received.

Почему заблокированные SMTP-порты создают проблему

Сначала важно разобраться, для чего используются основные SMTP-порты.

Порт	Основное назначение	Используется для приема почты из интернета
`25`	Передача почты между почтовыми серверами	Да
`587`	Аутентифицированная отправка сообщений	Нет
`465`	Отправка сообщений через TLS	Нет

Порт 25 остается стандартным портом для передачи сообщений между почтовыми серверами.

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

Поэтому нельзя просто заменить входящий порт 25 на 587 или 465 и ожидать, что сервер станет полноценным публичным MX-получателем.

Ограничения зависят от конкретного облачного провайдера:

Amazon EC2 по умолчанию ограничивает исходящий трафик через порт 25.
Google Cloud обычно блокирует внешние соединения через порт 25, но разрешает порты 465 и 587.
Azure блокирует исходящий порт 25 для многих типов подписок и рекомендует использовать аутентифицированные relay-сервисы.
DigitalOcean блокирует SMTP-порты 25, 465 и 587 на Droplet-серверах.

Чаще всего ограничения провайдеров относятся именно к исходящему SMTP-трафику. Однако самостоятельный прием почты все равно требует публично доступного SMTP-сервера, корректных правил firewall, постоянного IP-адреса, DNS-настроек, TLS, защиты от злоупотреблений и постоянного мониторинга.

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

Более практичная архитектура: MX на входе, HTTPS на выходе

Сервис входящей почты выступает мостом между почтовой сетью и вашим приложением.

Почтовый сервер отправителя
        |
        | SMTP, порт 25
        v
Входящий MX-сервер Fmailer
        |
        | Парсинг, проверка и сохранение
        v
Подписанный HTTPS-вебхук
        |
        v
Ваше приложение

Вашему серверу достаточно принимать обычный HTTPS-трафик.

Fmailer берет на себя SMTP-часть системы и передает вашему приложению структурированное JSON-событие.

В результате вашему приложению не требуется:

открывать порт 25;
устанавливать Postfix, Exim или другой MTA;
самостоятельно разбирать multipart MIME-сообщения;
управлять очередями SMTP;
хранить оригинальные письма и вложения;
отклонять неизвестные адреса на уровне SMTP;
следить за репутацией IP-адреса почтового сервера;
устанавливать обновления безопасности для почтового ПО.

Вместо SMTP-сессий вы работаете с обычными HTTP-запросами.

Как работает входящая почта Fmailer

Входящая почта Fmailer предназначена для программных сценариев, а не для использования в качестве обычного почтового ящика.

Сервис не предоставляет доступ через IMAP или POP3. Вместо этого каждое принятое письмо разбирается и отправляется вашему приложению через вебхук inbound.received.

Событие содержит:

идентификатор входящего сообщения (inbound_id) и домен-получатель;
сработавший маршрут и фактического получателя;
SMTP-отправителя (mail_from) и разобранный заголовок From;
адреса из заголовков To и Cc;
тему письма;
текстовую и HTML-версии сообщения;
выбранные почтовые заголовки (Date, Reply-To, In-Reply-To, References, Auto-Submitted, List-Id и другие);
результаты проверки DKIM;
размер сообщения;
список вложений с метаданными;
API-ссылки для скачивания вложений и оригинального файла .eml.

Входящая почта доступна на платных тарифах: тариф домена должен включать и вебхуки, и входящую почту. На платных тарифах по умолчанию доступно до 25 маршрутов на домен.

Рассмотрим процесс настройки по шагам.

Шаг 1. Выберите хост для приема почты

Начните с отдельного поддомена, например:

inbound.example.com

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

Предположим, сотрудники уже получают почту на адреса:

alex@example.com
support@example.com

Изменение MX-записей для example.com может нарушить работу существующего почтового сервиса.

Отдельный поддомен изолирует техническую почту приложения:

ticket-123@inbound.example.com
reply-456@inbound.example.com
upload@inbound.example.com

Принимающим хостом может быть как поддомен подтвержденного домена, так и сам домен. Если домен уже подключен именно для приема почты (например, help.example.com), второй уровень вложенности не нужен.

Есть одно ограничение: если на самом домене уже опубликована чужая MX-запись, Fmailer не даст назначить его принимающим хостом и предложит поддомен — это защита от случайного перехвата уже работающей корпоративной почты.

Шаг 2. Добавьте MX-запись

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

Пример:

inbound.example.com.  IN  MX  10  mx.fmailer.ru.

Эта запись сообщает другим почтовым серверам, что сообщения для адресов @inbound.example.com необходимо доставлять в Fmailer.

Прием почты включается при выполнении трех условий:

домен подтвержден обычной проверкой DNS-записей (в первую очередь DKIM);
MX-запись принимающего хоста опубликована и подтверждена проверкой Fmailer;
тариф домена включает входящую почту.

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

Для принимающего хоста рекомендуется оставить MX-запись Fmailer единственной.

При этом вам не требуется направлять на Fmailer почту основного корпоративного домена.

Шаг 3. Создайте endpoint для вебхука

Создайте HTTPS-endpoint в своем приложении, например:

POST /webhooks/fmailer/inbound

Затем добавьте endpoint в панели Fmailer и подпишите его на событие:

inbound.received

События входящей почты подключаются отдельно.

Простого создания универсального webhook-endpoint недостаточно — необходимо явно выбрать событие inbound.received и указать этот endpoint в маршруте (см. следующий шаг). В отличие от событий отправки, входящее письмо не рассылается всем подписанным endpoint'ам: оно уходит ровно на тот, который назван сработавшим маршрутом.

Fmailer подписывает webhook-запросы с помощью HMAC-SHA256. Перед разбором и обработкой события приложение должно проверить подпись на основе исходного тела HTTP-запроса.

Каждый запрос содержит заголовки:

X-Webhook-Event      inbound.received
X-Webhook-Delivery   идентификатор доставки, он же event_id в теле
X-Webhook-Timestamp  время подписи, unix-секунды
X-Webhook-Signature  HMAC-SHA256 в hex

Шаг 4. Настройте маршруты входящей почты

Маршруты определяют, какие email-адреса будут приниматься и на какой webhook-endpoint будут передаваться сообщения.

Fmailer поддерживает три основных типа маршрутов:

Шаблон	Тип	Пример совпадения
`support`	Точное совпадение	`support@inbound.example.com`
`ticket-*`	Префикс	`ticket-91@inbound.example.com`
`*`	Catch-all	Любой адрес без более точного маршрута

Правила записи шаблона:

указывается только локальная часть адреса, без @ и без имени хоста;
символ * допускается один и только в конце;
префиксный маршрут требует хотя бы один символ на месте звездочки: ticket-* совпадает с ticket-91, но не с ticket-;
сравнение регистронезависимое;
маршрут ссылается ровно на один webhook-endpoint того же домена.

Приоритет маршрутизации:

точное совпадение;
самый длинный подходящий префикс;
catch-all маршрут.

Если письмо отправлено на адрес, который не соответствует ни одному активному маршруту, Fmailer отклоняет его в рамках той же SMTP-сессии: почта на неизвестный хост отклоняется еще на этапе RCPT TO, а известный хост без подходящего маршрута отвечает 550 после передачи данных. В обоих случаях отчет о недоставке формирует сервер отправителя, а сообщение в вашу систему не попадает.

Сервис не принимает бесконтрольно сообщения для неопределенных адресов.

Таким способом можно создавать управляемые пространства адресов:

support@inbound.example.com
invoice@inbound.example.com
ticket-<ticket-id>@inbound.example.com
project-<project-id>@inbound.example.com
customer-<customer-id>@inbound.example.com

Шаг 5. Обработайте входящий webhook

Упрощенное событие входящей почты может выглядеть следующим образом:

{
  "event_id": "6f1d2c30-0004-4c7a-9b21-0c8e5a3d7f44",
  "event": "inbound.received",
  "inbound_id": "0f0b6c1a-4a1e-4a3a-9f7a-2c9d1b5e8a10",
  "domain": "example.com",
  "route": "support",
  "recipient": "support@inbound.example.com",
  "mail_from": "alex@customer.example",
  "from": {
    "email": "alex@customer.example",
    "name": "Alex"
  },
  "to": ["support@inbound.example.com"],
  "cc": [],
  "subject": "Проблема с импортом данных",
  "text": "Импорт останавливается на 72%.",
  "html": "<p>Импорт останавливается на 72%.</p>",
  "headers": {
    "Date": "Tue, 12 Aug 2025 10:04:11 +0300",
    "Reply-To": "alex@customer.example"
  },
  "message_id": "<a1b2c3@customer.example>",
  "auth": {
    "dkim": "pass",
    "dkim_aligned": true
  },
  "size": 18422,
  "raw_url": "https://api.fmailer.ru/api/inbound/messages/0f0b6c1a-.../raw/",
  "attachments": [],
  "timestamp": "2025-08-12T07:04:12.481Z"
}

Поля raw_url и attachments[].url — это постоянные API-адреса Fmailer, а не временные подписанные ссылки. Так сделано намеренно: тело события сохраняется и повторяется при ретраях в течение суток, а подписанная ссылка на хранилище живет минуты. Запрос к API выполняется с авторизацией вашего аккаунта и уже он возвращает редирект на короткоживущую ссылку для скачивания.

Пример webhook-endpoint на Node.js

Следующий endpoint на Express проверяет подпись Fmailer и принимает события входящей почты:

const crypto = require("crypto");
const express = require("express");

const app = express();

const webhookSecret = process.env.FMAILER_WEBHOOK_SECRET;
const replayToleranceSeconds = 300;

app.post(
  "/webhooks/fmailer/inbound",
  express.raw({ type: "application/json" }),
  async (req, res) => {
    const signature = req.get("X-Webhook-Signature");
    const timestamp = req.get("X-Webhook-Timestamp");

    if (
      !signature ||
      !timestamp ||
      !/^[a-f0-9]{64}$/i.test(signature)
    ) {
      return res.sendStatus(400);
    }

    const timestampNumber = Number(timestamp);

    if (
      !Number.isFinite(timestampNumber) ||
      Math.abs(Date.now() / 1000 - timestampNumber) >
        replayToleranceSeconds
    ) {
      return res.sendStatus(400);
    }

    // Подпись рассчитывается для строки:
    // <timestamp>.<точное исходное тело запроса>
    const signedPayload = Buffer.concat([
      Buffer.from(`${timestamp}.`, "utf8"),
      req.body
    ]);

    const expectedSignature = crypto
      .createHmac("sha256", webhookSecret)
      .update(signedPayload)
      .digest();

    const providedSignature = Buffer.from(signature, "hex");

    if (
      providedSignature.length !== expectedSignature.length ||
      !crypto.timingSafeEqual(
        providedSignature,
        expectedSignature
      )
    ) {
      return res.sendStatus(400);
    }

    let event;

    try {
      event = JSON.parse(req.body.toString("utf8"));
    } catch {
      return res.sendStatus(400);
    }

    if (event.event !== "inbound.received") {
      return res.sendStatus(204);
    }

    // Добавляем событие в очередь с защитой от дубликатов.
    // event.event_id не изменяется при повторной доставке.
    await enqueueInboundEmail({
      idempotencyKey: event.event_id,
      route: event.route,
      recipient: event.recipient,
      sender: event.from?.email,
      subject: event.subject,
      text: event.text,
      html: event.html,
      attachments: event.attachments,
      senderAuthenticated:
        event.auth?.dkim === "pass" &&
        event.auth?.dkim_aligned === true
    });

    return res.sendStatus(202);
  }
);

app.listen(3000);

Подпись необходимо рассчитывать на основе точных исходных байтов HTTP-запроса.

Если сначала преобразовать body в объект, а затем снова сериализовать его в JSON, пробелы или форматирование могут измениться. В таком случае проверка подписи завершится ошибкой.

После успешного приема Fmailer ожидает HTTP-ответ со статусом 2xx. На ответ отводится 10 секунд.

Поэтому webhook-handler должен быстро:

проверить подпись;
проверить тип события;
добавить задачу в очередь;
вернуть успешный ответ.

Не стоит выполнять скачивание вложений, AI-анализ или длительную обработку до отправки HTTP-ответа.

При неуспешной доставке Fmailer повторяет webhook-запрос по возрастающему графику: через 1 минуту, 5 минут, 30 минут, 2 часа, 6 часов и 24 часа. Если все попытки исчерпаны, доставка помечается как неуспешная, а само письмо остается доступным через API и панель.

Ограничения приема

Технические лимиты по умолчанию:

Параметр	Значение
Максимальный размер сообщения	30 МБ
Вложений в сообщении	до 25
Размер одного вложения	до 25 МБ
Сохраняемый объем text и html	до 500 000 символов
Поток на домен	500 сообщений в час

Сообщение сверх допустимого размера отклоняется на уровне SMTP. При превышении почасового лимита Fmailer отвечает временной ошибкой 450, и отправляющий сервер повторит доставку позже.

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

Какие продукты можно построить с помощью входящей почты

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

1. Система поддержки email-to-ticket

Создайте точный маршрут:

support@inbound.example.com

Когда клиент отправляет письмо:

Fmailer принимает и разбирает сообщение.
Ваш webhook получает данные письма.
Приложение находит клиента по адресу отправителя.
Создается новый тикет.
Вложения прикрепляются к обращению.
Клиенту отправляется автоматическое подтверждение.

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

2. Уникальные адреса для ответов на тикеты

Назначьте каждому тикету собственный адрес:

ticket-8942@inbound.example.com

Создайте префиксный маршрут:

ticket-*

Webhook может извлечь идентификатор 8942 из адреса получателя и добавить письмо к соответствующему тикету.

Такой подход надежнее, чем связывание сообщений по теме письма.

Идентификатор объекта находится непосредственно в адресе доставки.

Та же схема подходит для адресов:

thread-<id>@inbound.example.com
conversation-<id>@inbound.example.com
case-<id>@inbound.example.com

3. Ответы на уведомления по email

Предположим, ваша система управления проектами отправляет уведомление:

Мария упомянула вас в проекте Apollo.
Ответьте на это письмо, чтобы добавить комментарий.

Укажите в качестве адреса для ответа:

project-41-thread-987@inbound.example.com

Когда пользователь отвечает, webhook определяет проект и обсуждение по адресу получателя.

Текст письма преобразуется в новый комментарий.

Перед сохранением приложение может:

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

4. Прием счетов и документов

Создайте адрес:

invoices@inbound.example.com

Клиенты или поставщики смогут отправлять счета непосредственно в вашу систему.

Приложение может:

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

Входящее событие Fmailer содержит информацию о каждом вложении:

идентификатор;
имя файла;
MIME-тип;
размер;
признак inline-вложения;
Content ID;
API-адрес для скачивания.

5. Уникальные адреса для каждого клиента

Создавайте персональный адрес для каждого tenant или клиента:

customer-a83f9@inbound.example.com

Такой адрес может стать простым интерфейсом интеграции.

Вместо полноценной API-интеграции клиент пересылает на него:

отчеты;
уведомления;
чеки;
документы;
экспортированные данные;
системные сообщения.

Ваше приложение определяет владельца сообщения по идентификатору в адресе получателя.

Сценарий подходит для:

сервисов управления расходами;
бухгалтерских платформ;
compliance-систем;
логистических приложений;
сервисов управления недвижимостью;
рекрутинговых платформ;
систем обработки документов.

Если идентификаторы клиентов или объектов используются в публичных адресах, лучше применять непрозрачные и непоследовательные значения.

6. Сбор лидов в CRM

Назначьте отдельный адрес каждому партнеру, кампании или менеджеру:

partner-acme@inbound.example.com
campaign-berlin@inbound.example.com
rep-42@inbound.example.com

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

Catch-all маршрут позволяет использовать динамические адреса, а точные маршруты — резервировать важные системные имена.

7. Обработка автоматических отчетов

Многие устаревшие системы умеют отправлять email, но не поддерживают REST API.

Вместо разработки отдельной интеграции можно выдать такой системе специальный адрес:

reports-warehouse-7@inbound.example.com

Legacy-система отправляет периодический отчет по почте.

Ваш webhook:

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

В этом случае email становится адаптером между устаревшей системой и современным приложением.

8. AI-обработка входящей почты

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

Примеры:

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

Сначала сохраните событие или поставьте его в очередь, а ресурсоемкую обработку выполняйте отдельным worker-процессом.

Содержимое email и вложений необходимо считать недоверенными данными. Они могут содержать:

вредоносные файлы;
скрытый HTML;
tracking-элементы;
попытки prompt injection;
вводящие в заблуждение инструкции;
поддельные данные отправителя.

Безопасность и надежность

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

Проверяйте подпись каждого webhook-запроса

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

Проверяйте:

X-Webhook-Signature;
X-Webhook-Timestamp;
точное исходное тело запроса;
допустимое окно времени для защиты от повторного воспроизведения.

Для сравнения ожидаемой и полученной подписи используйте constant-time функцию.

Удаляйте дубликаты по `event_id`

Доставка входящих событий работает по модели at least once.

Если endpoint не ответил вовремя или вернул ошибку, одно и то же событие может быть доставлено повторно.

Используйте event_id в качестве ключа идемпотентности: при повторных попытках он не меняется.

Так повторная доставка не создаст:

два тикета;
два комментария;
два счета;
два лида;
две задачи обработки.

Не доверяйте полю From автоматически

Видимый заголовок From можно подделать.

Fmailer сообщает:

результат проверки DKIM;
соответствует ли домен DKIM-подписи видимому домену отправителя.

Поле auth.dkim принимает пять значений:

Значение	Что означает
`pass`	подпись проверена
`fail`	подпись не прошла проверку
`none`	подписи нет — обычное состояние для многих отправителей
`temperror`	DNS не ответил, проверить не удалось
`permerror`	подпись или ключ некорректны

Значения temperror и permerror намеренно отделены от fail: «письмо подделано» и «мы не смогли проверить» — разные факты, и правило вида «дропаем все, кроме pass» должно это учитывать.

Полей spf и dmarc в событии нет, и это осознанное решение: SPF в этом контуре не вычисляется, а DMARC-вердикт по одной только DKIM-подписи давал бы ложные отказы для писем, прошедших по SPF.

Для сценариев, где требуется более высокий уровень доверия, отправителя можно считать технически аутентифицированным только при выполнении условий:

event.auth.dkim === "pass" &&
event.auth.dkim_aligned === true

Однако аутентификация не заменяет авторизацию.

Даже корректно подтвержденный отправитель не должен автоматически получать доступ ко всем проектам, тикетам или аккаунтам.

Приложение должно отдельно проверить, имеет ли пользователь право выполнять конкретное действие.

Используйте фактически принятый адрес получателя

Для определения маршрута и объекта используйте поля recipient и route.

Не следует считать все адреса из видимых заголовков To и Cc фактически принятыми системой.

В заголовках могут находиться:

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

Авторизацию и маршрутизацию необходимо строить на основе адреса, который действительно принял Fmailer.

Проверяйте вложения

Перед обработкой вложения:

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

Ограничения приложения могут быть строже ограничений почтового сервиса.

Защищайтесь от email-циклов

Осторожно настраивайте автоматические ответы.

Не создавайте autoresponder, который отправляет сообщения обратно на тот же входящий маршрут.

Со своей стороны Fmailer ограничивает цикл по числу транзитных заголовков Received и по почасовому лимиту домена, но это защита от разрастания, а не замена корректной логики автоответов.

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

Auto-Submitted
In-Reply-To
List-Id
Precedence

Автоответы и списочная почта не отбрасываются сервисом: это ваша почта, и решение принимает ваше приложение.

Входящая почта — не обычный почтовый ящик

Функция inbound email в Fmailer предназначена для передачи почты программному коду.

Она не заменяет Gmail, Outlook или общий почтовый ящик отдела поддержки.

Пользователи не входят в Fmailer, чтобы читать письма через IMAP или POP3.

Пользовательский интерфейс создает ваше приложение.

Например:

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

Ответные письма можно отправлять отдельно через API, SMTP relay или SDK Fmailer.

Почему сервис входящей почты удобнее собственного SMTP-сервера

Собственный SMTP-сервер дает полный контроль, но вместе с ним — полную ответственность.

Необходимо самостоятельно обслуживать:

доступность SMTP-listener;
MX-записи;
reverse DNS;
TLS-сертификаты;
настройки протоколов;
MIME-парсинг;
большие сообщения;
проверку адресов;
очереди доставки;
временные ошибки;
повторные попытки;
защиту от спама и злоупотреблений;
хранение исходных сообщений;
хранение вложений;
обновления безопасности;
мониторинг;
реагирование на инциденты.

Для компании, которая специализируется на email-инфраструктуре, такие затраты могут быть оправданы.

Но если задача SaaS-команды заключается в том, чтобы превратить письмо в тикет, комментарий, счет, лид или загруженный документ, самостоятельная SMTP-инфраструктура обычно становится ненужной сложностью.

Fmailer оставляет SMTP на внешнем контуре и предоставляет вашему приложению привычный интерфейс: подписанный JSON-вебхук через HTTPS.

Часто задаваемые вопросы

Можно ли принимать email, не открывая порт 25?

Да.

Если входящий сервис принимает почту от вашего имени, приложению не требуется открывать порт 25.

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

SMTP-соединение существует только между сервером отправителя и сервисом входящей почты. До сервера вашего приложения оно не доходит.

Можно ли использовать порт 587 вместо порта 25 для входящей почты?

Нет, не для стандартной передачи сообщений между почтовыми серверами.

Порт 587 предназначен для аутентифицированной отправки сообщений клиентами и приложениями.

Передача почты между MX-серверами выполняется через порт 25.

Можно ли использовать порт 465?

Порт 465 используется для отправки сообщений через TLS.

Он не является универсальной заменой порта 25 для публичного MX-сервера.

Нужно ли устанавливать Postfix или Exim?

Нет.

Fmailer самостоятельно принимает SMTP-сообщение и разбирает его содержимое.

Ваше приложение получает HTTPS-запрос со структурированными данными письма.

Поддерживаются ли вложения?

Да.

Событие входящей почты содержит метаданные вложений и API-адреса для их скачивания: имя файла, MIME-тип, размер, признак inline и Content ID.

Также можно получить оригинальный файл сообщения в формате .eml.

Ограничения по умолчанию: до 25 вложений, до 25 МБ каждое, размер всего сообщения до 30 МБ.

Можно ли создавать динамические email-адреса?

Да.

Например, префиксный маршрут ticket-* может принимать адреса:

ticket-123@inbound.example.com
ticket-456@inbound.example.com

Catch-all маршрут * позволяет принимать любой адрес, который не совпал с более точным правилом.

Что произойдет, если webhook временно недоступен?

Fmailer повторит доставку через 1 минуту, 5 минут, 30 минут, 2 часа, 6 часов и 24 часа.

Поскольку одно событие может быть доставлено несколько раз, приложение должно удалять дубликаты по event_id.

Само письмо при этом сохранено и остается доступным через API и панель.

Можно ли принимать почту на основном домене компании?

Технически да: принимающим хостом может быть и сам домен. Но если на нем уже работает корпоративная почта, менять MX-записи не нужно и не следует — Fmailer откажет в такой настройке, обнаружив чужую MX-запись на домене.

Практичный вариант — отдельный поддомен:

inbound.example.com

Это позволяет не трогать MX-записи, которые уже обслуживают корпоративные адреса на example.com.

На каких тарифах доступна входящая почта?

Входящая почта включена в платные тарифы: тариф должен поддерживать и вебхуки, и входящие маршруты. На бесплатном тарифе функция недоступна.

Принимайте email без собственной SMTP-инфраструктуры

Заблокированные SMTP-порты не должны останавливать разработку продукта.

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

Ваше приложение будет получать каждое письмо в виде разобранного и подписанного HTTPS-вебхука, который можно обрабатывать через существующую API-инфраструктуру.

Архитектура остается простой:

Настроить MX
    → создать маршрут
    → подключить webhook
    → обработать входящее письмо

Используйте входящую почту, чтобы:

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