SMTP Integration

Arsel provides a standard SMTP server that lets you send transactional emails using any SMTP client. This is ideal when your application already sends emails through SMTP and you want to route them through Arsel without changing your code.

When to Use SMTP vs API

	SMTP	REST API
Best for	Existing apps with SMTP code, legacy systems, platforms that only support SMTP	New integrations, full control over request/response, programmatic workflows
Authentication	Username + password per connection	API key per request
Features	Send emails with HTML, text, attachments	Send emails + list status + per-recipient tracking + SMS
Rate limiting	2 messages/sec per organization, 421 reply (closes connection) when blocked	2 requests/sec per organization, 429 with rate-limit headers
Tracking	Full delivery tracking via the API status endpoints	Full delivery tracking built-in

tip

Emails sent via SMTP are processed through the same pipeline as API emails. You get the same delivery infrastructure, tracking, and analytics regardless of which method you use.

Connection Details

Setting	Value
Host	smtp.arsel.sa
Port	465 (implicit TLS)
Security	TLS required
Authentication	PLAIN or LOGIN
Max message size	30 MB

Quick Start

1. Create SMTP credentials from your Arsel Dashboard under Settings > SMTP Credentials. See Managing Credentials.

2. Configure your SMTP client with the connection details above and your generated username and password.

3. Send an email through your application's existing email flow.

See Sending Emails via SMTP for detailed setup examples across languages and frameworks.

Requirements

Before sending via SMTP, ensure:

• Your sender domain is verified in the Arsel dashboard
• Your SMTP credentials are active (not revoked)
• Your organization's sending quota has not been exceeded
• Your organization is not suspended due to bounce/complaint rates

Rate Limits

Each organization can submit 2 messages per second in production. The limit is shared across all SMTP credentials and concurrent connections — additional credentials do not raise your throughput.

When you exceed it, the server replies to your DATA command with:

421 Too many messages, please slow down

and closes the connection (RFC 5321 §3.8). Your next message opens a fresh session. The limit is a 1-second window aligned to the wall clock, so backing off slightly more than one second is the safest pattern.

Things to know:

• The check runs after the message body has streamed. There's no way to pre-flight at MAIL FROM or RCPT TO — a throttled message still pays full upload cost.
• The slot is consumed even when the message later fails downstream validation (unverified sender, bad recipients). Fix the underlying error first — retrying a doomed message burns rate budget.
• The monthly sending quota is a separate limit and returns 451 Monthly sending quota exceeded (connection stays open). Waiting a second won't clear it.

Handling rate limits

When you see 421 Too many messages:

• Match on code 421 and the text Too many messages. Don't blanket-retry every 421 — other causes (restarts, maintenance) are not the same condition.
• Open a new connection. The old one is closed. Pooled libraries (Nodemailer pool, JavaMail) reopen automatically; ad-hoc clients construct a fresh transport.
• Back off exponentially with jitter, e.g. 1s × 2^attempt capped at ~10 s, and stop after about 5 attempts. Surface persistent failures to a dead-letter queue or your upstream caller.
• Prefer prevention. If you regularly hit the limit, add a client-side token bucket sized to 2 msg/s/org — back-pressure is cheaper than reactive retries, since 421 only fires after the body has finished uploading.