Route · SMTP Relay
SMTP Relay
SMTP по-прежнему самый быстрый путь для многих приложений, плагинов и внутренних сервисов. Sendarix даёт производственную обработку SMTP с понятными логами и исходами событий.
# Отправить критическое письмо через routing policy curl -sS -X POST 'https://app.sendarix.com/v1/email/send' \ -H 'Content-Type: application/json' \ -H 'X-API-Key: YOUR_API_KEY' \ -H 'Idempotency-Key: otp_8842' \ -d '{"to":"user@acme.com","template":"password_reset","routing_policy":"transactional-critical"}'
const sendarix = require("sendarix")(process.env.SENDARIX_KEY); await sendarix.email.send({ to: "user@acme.com", template: "password_reset", routingPolicy: "transactional-critical", idempotencyKey: "otp_8842" });
# Drop-in SMTP — сохраните интеграцию и получите control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
Один relay для любого стека
Держите legacy и современные системы на одном надёжном relay
Используйте один relay для транзакционного трафика, нагрузок уведомлений и платформенных сообщений без хрупких разовых инструментов.
Репрезентативный UI продукта — примерные данные, не live-метрики клиентов.
Создан для реальных SMTP-операций
Это не простой forwarding. Это контролируемый конвейер отправки с аутентификацией, дисциплиной очереди и наблюдаемостью для операционных команд.
Безопасная передача
SMTP AUTH и сессии с TLS для защищённых учётных данных и транспорта.
Стабильность пропускной способности
Ровная производительность для burst-трафика и ежедневной фоновой почты.
Видимость и логи
Быстро разбирайте исходы доставки с поиском по логам и отслеживанием на уровне событий.
Плавная миграция
Уходите от старых SMTP-провайдеров без немедленной полной переработки архитектуры.
Выделенная идентичность отправки
Аутентифицированные домены и политики отправителя в духе корпоративной почты.
Надёжность с учётом очереди
Сохраняйте согласованность доставки при всплесках за счёт контролируемой очереди и повторов.
Поток SMTP Relay
Понятный 4-шаговый поток, чтобы инфраструктура оставалась предсказуемой и отлаживаемой.
1. Подключение
Приложение подключается по учётным данным SMTP и устанавливает защищённую сессию.
2. Приём
Сообщение проверяется и принимается в очередь для контролируемой обработки.
3. Маршрутизация
Трафик идёт по путям доставки с устойчивостью и учётом поведения провайдеров.
4. Отслеживание
События исходов и логи дают операционную уверенность и ускоряют разбор проблем.
Частые вопросы
Можно начать с SMTP и позже перейти на API?
Да. Многие команды начинают с SMTP ради скорости, затем добавляют API для более глубоких продуктовых процессов.
Есть ли видимость на уровне доставки?
Да. Доступны логи и потоки событий для проверки принято, доставлено, отказ.
Подходит ли для высокого объёма?
Да. Relay рассчитан на устойчивый трафик и burst-события типичные для продакшен-платформ.
Какие порты и шифрование использовать?
Большинство продакшен-клиентов использует submission на 587 с STARTTLS или неявный TLS на 465. Избегайте открытого SMTP в публичных сетях.
Можно ограничить SMTP известными IP?
Да. Разрешение по IP — обычный enterprise-контроль: только серверы приложений, VPN-выход или парк MTA могут аутентифицироваться на relay.
Как хранить учётные данные в приложениях?
Храните SMTP-учётные данные в менеджере секретов, ротируйте при смене персонала, не коммитьте в репозиторий. Предпочтительно по средам.
Вредит ли открытие нового SMTP-соединения на каждое письмо доставляемости?
Чрезмерная смена соединений добавляет задержку и нагрузку. Где возможно, переиспользуйте соединения и следуйте документированным лимитам скорости и параллелизма.
Могут ли legacy CRM и принтеры использовать тот же relay?
Часто да. SMTP — общий знаменатель для старых систем; потоки можно сегментировать доменами, заголовками или субаккаунтами, если план поддерживает.
А размер сообщений и вложений?
Крупные полезные нагрузки повышают риск сбоев и время обработки. Проверьте лимиты плана и при тяжёлых вложениях размещайте файлы снаружи со ссылками в письме.
What is the difference between port 587 and port 465?
Port 587 uses STARTTLS (opportunistic TLS upgrade after CONNECT), while port 465 uses implicit TLS where the connection is encrypted from the start. Both are valid for secure submission. Port 587 is the RFC-compliant standard for message submission; port 465 is deprecated but still widely supported for legacy clients.
How does Sendarix handle greylisting?
When a destination provider returns a 450 or 451 temporary response, Sendarix respects the retry period specified in the SMTP response. Most providers implement greylisting for 30 seconds to 10 minutes. Sendarix tracks these windows and retries within the provider's specified interval to maximize first-attempt success.
What is the maximum message size via SMTP?
Default maximum message size is 50MB including attachments and MIME encoding. For files larger than 25MB, Sendarix recommends uploading to cloud storage and sending a signed link instead. Some providers reject messages over 25MB entirely, regardless of SMTP acceptance.
Can we use subaddressing (user+tag@example.com) with Sendarix?
Yes. Subaddressing is fully supported and passed through to destination mail servers. The plus-address portion is visible to receiving MTA filters and can be used for routing, tagging, or filtering rules on the recipient side.
How do we verify our sending domain with Sendarix?
Domain verification requires adding DKIM records to your DNS. Sendarix provides a DKIM public key pair during setup. Add the TXT record to your domain's DNS, then Sendarix validates the record propagates before signing outgoing mail on your behalf.
Руководства по настройке SMTP
Связанные продукты
Защитите критически важную почту по всем tenants.
Перенесите самый критичный поток в Sendarix на этой неделе. Все остальное оставьте там, где оно есть.
