Route · SMTP Relay
SMTP Relay Service
Sendarix operates MTA infrastructure with direct peering to major mailbox providers (Gmail, Outlook, Yahoo) and regional receivers. Our relay handles SMTP AUTH, TLS enforcement, queue management, and bounce classification so you do not have to build this yourself.
# Send a critical email through a 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 — keep your integration, gain a control plane host: smtp.sendarix.com port: 587 (STARTTLS) username: "your_sending_key" header: X-Sendarix-Policy: transactional-critical
One relay, every stack
Production SMTP Relay for Critical Email Workloads
Ship email via your existing MTA, application library, or CI system — no rewrite required. Sendarix fits into any stack that speaks SMTP.
Representative product UI — illustrative data, not live customer metrics.
Designed for Real SMTP Operations
This is not a basic forwarding layer. It is a controlled sending pipeline with authentication support, queuing discipline, and observability for operational teams.
Secure Submission
SMTP AUTH and TLS-capable submission flows for protected credentials and transport.
Throughput Stability
Consistent performance for burst traffic and daily background mail workloads.
Visibility & Logs
Investigate delivery outcomes quickly with searchable logs and event-level tracking.
Smooth Migration
Move from old SMTP providers without forcing an immediate full architecture rewrite.
Dedicated Sending Identity
Use authenticated domains and sender policies that align with enterprise mail requirements.
Queue-Aware Reliability
Protect delivery consistency during spikes with controlled queueing and retry behavior.
SMTP Relay Flow
A clear 4-step flow to keep infrastructure predictable and debuggable.
1. Connect
Application connects via SMTP credentials and establishes a secure session.
2. Accept
Message is validated and accepted into the queue for controlled processing.
3. Route
Traffic is routed through delivery paths with resilience and provider-aware behavior.
4. Track
Outcome events and logs provide operational confidence and faster troubleshooting.
Frequently Asked Questions
Can we start with SMTP and move to API later?
Yes. Many teams begin with SMTP for speed, then add API endpoints for deeper product workflows.
Do we get delivery-level visibility?
Yes. Logs and event streams are available so you can inspect accepted, delivered, and bounced outcomes.
Is this suitable for high-volume sending?
Yes. The relay is built for sustained traffic and burst events common in production platforms.
Which ports and encryption should we use?
Most production clients use submission on port 587 with STARTTLS, or implicit TLS on 465. Avoid cleartext SMTP on public networks.
Can we restrict SMTP to known IP addresses?
Yes. IP allowlisting is a common enterprise control: only your application servers, VPN egress, or MTA fleet can authenticate to the relay.
How should we handle authentication credentials in apps?
Store SMTP credentials in a secrets manager, rotate them when staff change, and never commit them to source control. Prefer per-environment credentials.
Does opening a new SMTP connection for every email hurt deliverability?
Excessive connect churn can add latency and load. Where your stack allows, reuse connections responsibly and follow documented rate and concurrency guidance.
Can legacy CRMs and printers use the same SMTP relay?
Often yes. SMTP is the common denominator for older systems; you can segment those streams with domains, headers, or subaccounts where your plan supports it.
What about message size and attachment limits?
Large payloads increase failure risk and processing time. Check your plan limits and consider hosting files externally with links in email when attachments are heavy.
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 setup guides
Related Products
Protect critical email across every tenant.
Move your most critical stream to Sendarix this week. Keep everything else exactly where it is.
