Входящая почта для приложений
Направьте на fmailer MX-запись своего поддомена — письмо будет принято, разобрано на поля и отправлено в ваш вебхук. Без IMAP, без собственного почтового сервера, без промежуточной инфраструктуры.
MX вашего поддомена · Вебхук · Без IMAP · Приём доступен на платных тарифах
Путь письма от отправителя до вашего кода
┌─────────────────────────────────┐
│ client@partner.ru │
└────────────────┬────────────────┘
│ письмо
▼
┌─────────────────────────────────┐
│ support@inbound.example.ru │
│ MX 10 mx.fmailer.ru │
└────────────────┬────────────────┘
│
▼
┌─────────────────────────────────┐
│ fmailer: разбор, DKIM, вложения │
└────────────────┬────────────────┘
│ inbound.received
▼
┌─────────────────────────────────┐
│ POST /webhooks/inbound │
└─────────────────────────────────┘Если вы переходите с другого сервиса
Mailgun, SendGrid и Amazon SES решают одно и то же: принять письмо на вашем домене и отдать его приложению. Различается только то, сколько компонентов стоит между письмом и кодом. Ниже — разбор каждого перехода на fmailer.
Как это работает
Обычно, чтобы принимать почту, приложению приходится опрашивать IMAP, держать собственный почтовый сервер или собирать конвейер из нескольких сервисов. Здесь три шага.
Тело события inbound.received — то же, что в документации
{
"event_id": "6f1d2c30-0004-4c7a-9b21-0c8e5a3d7f44",
"event": "inbound.received",
"inbound_id": "b41f9a70-2c55-4d1e-9a7f-1d3e5c9b2a08",
"domain": "example.ru",
"route": "support",
"recipient": "support@inbound.example.ru",
"mail_from": "client@partner.ru",
"from": { "email": "client@partner.ru", "name": "Иван Петров" },
"to": ["support@inbound.example.ru"],
"cc": [],
"subject": "Не пришёл счёт по заказу 4417",
"text": "Добрый день! Заказ оплачен, счёта нет.",
"html": "<p>Добрый день! Заказ оплачен, счёта нет.</p>",
"headers": { "Reply-To": ["client@partner.ru"] },
"message_id": "<CAF9x1@mail.partner.ru>",
"auth": { "dkim": "pass", "dkim_aligned": true },
"size": 24188,
"raw_url": "https://api.fmailer.ru/api/inbound/messages/b41f9a70-.../raw/",
"attachments": [
{
"id": "9c7e1b52-40a8-4f9d-8c31-6b2a4e0d1f77",
"filename": "чек.pdf",
"content_type": "application/pdf",
"size": 18422,
"inline": false,
"url": "https://api.fmailer.ru/api/inbound/messages/b41f9a70-.../attachments/9c7e1b52-.../"
}
],
"timestamp": "2026-06-24T09:41:13.482921+00:00"
}Ссылки на исходный .eml и вложения ведут на наш API, а не на хранилище: они постоянны, требуют токена аккаунта и в момент обращения перенаправляют на свежую подписанную ссылку. Поэтому повтор вебхука через сутки не приносит мёртвых ссылок.
Сравнение архитектур
Слева — путь письма в той инфраструктуре, с которой вы переходите. Справа — тот же путь здесь. Он одинаковый во всех трёх случаях, и в этом смысл.
Было
Стало
Это сравнение одного сценария — «письмо → приложение», — а не функций целиком. У каждого из перечисленных сервисов есть возможности, которых у нас нет, и обещать полную замену было бы неправдой.
Миграция
Mailgun Routes принимает письмо и по заданным правилам либо передаёт его на HTTP-эндпоинт, либо пересылает на другой почтовый адрес. Если Routes нужен был ради первого — чтобы письмо попадало в код, — тот же сценарий на fmailer собирается из MX-записи и маршрутов.
Что устроено иначе: маршрут здесь — это шаблон локальной части адреса (точный, префикс или catch-all), а не выражение с фильтрами по заголовкам и телу; действий forward на другой почтовый адрес и stop у нас нет — письмо всегда отдаётся вебхуком, а решение о том, что с ним делать, принимает ваш код.
Для каких сценариев подходит
Миграция
Inbound Parse принимает письма на заданном хосте, разбирает содержимое и отправляет данные POST-запросом на ваш URL. fmailer делает то же самое, но отдаёт разобранное письмо подписанным JSON, а не multipart-формой, и не кладёт вложения в тело запроса — вместо этого в событии приходят ссылки на них.
Не нужно подключаться к ящику по расписанию и проверять, не появилось ли новое письмо: приложение получает событие в момент, когда письмо принято.
Одно отличие стоит учесть заранее: локальная часть сравнивается дословно и теги после плюса не отрезаются. Для генерируемых адресов заводите префиксный маршрут — reply-* — и не рассчитывайте на то, что support+78392 попадёт в маршрут support.
Например: ответ попадает в нужный диалог
Миграция
Amazon SES умеет принимать входящую почту, но обработка обычно строится вокруг инфраструктуры AWS: Receipt Rule кладёт письмо в S3, Lambda достаёт его оттуда и разбирает MIME, между шагами могут стоять SNS и права IAM. Событие, которое Lambda получает напрямую, содержит метаданные и заголовки, но не тело письма — поэтому письмо и попадает сначала в бакет.
Если задача ровно в том, чтобы получить входящее письмо в приложении, промежуточные компоненты можно убрать: fmailer принимает письмо, разбирает его сам и вызывает ваш вебхук с готовыми полями.
Если задача шире — держать исходники писем в собственном бакете, обрабатывать их внутри VPC, собирать произвольный конвейер, — SES остаётся гибче. Речь здесь только про сценарий «письмо → приложение».
Что перестаёт быть вашей заботой
Что на этом строят
Отправляйте письма с уникальным адресом для ответа — reply-12345@inbound.example.ru — и ответ пользователя попадёт в нужный диалог, а не в общий ящик.
Письмо на support@ превращается в тикет: отправитель, тема, текст, HTML и вложения приходят уже разобранными.
Письма на sales@ становятся лидами, активностями или сообщениями в карточке клиента.
Счета, акты и заявки приходят почтой, а ваш обработчик забирает вложения по ссылке из события и отправляет их в свой конвейер.
Классифицировать обращение, вытащить номер заказа, определить клиента, подготовить черновик ответа — на входе готовый текст письма, а не MIME.
Отчёты и выгрузки, которые внешняя система присылает письмом, разбирает код, а не человек.
Что это не такое
Письма не хранятся для чтения человеком в почтовом клиенте: нет ни IMAP, ни POP3, и отвечать с адреса приёма нельзя — ответ отправляется обычным способом, через SMTP или API. Приём нужен, чтобы письмо попадало в код.
Принятые письма при этом видны в панели, пока их не удалит срок хранения журнала по тарифу: тело, заголовки, вердикт DKIM, исходный .eml и вложения.
Было
SMTP → ящик → IMAP → опрос → парсер → приложение
Стало
SMTP → fmailer → вебхук → приложение
Что именно реализовано
Здесь перечислено только то, что работает сегодня. Полное описание — в документации по приёму.
Частые вопросы
Подключите поддомен, опубликуйте MX-запись и получайте входящие письма прямо в своём приложении.