Sending over SMTP

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 the 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	50 messages/sec per organization, 421 reply (closes connection) when blocked	1,000 requests/min 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 below.

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 SMTP client setup for detailed examples across languages and frameworks.

Requirements

Before sending via SMTP, ensure:

• Your sender domain is verified in the Arsel dashboard — see Domain verification
• 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 — see Sender reputation

Managing credentials

SMTP credentials are organization-scoped username/password pairs used to authenticate SMTP connections. Each credential set is independent — you can create multiple credentials for different applications or environments.

Creating credentials

Generate SMTP credentials from your Arsel dashboard:

1. Navigate to Settings > SMTP Credentials
2. Click Create Credentials
3. Optionally give them a descriptive name (e.g., "Production Server", "Staging")
4. Copy the username and password immediately

warning

The password is only shown once at creation time. Store it securely — it cannot be retrieved later. If lost, rotate the credential to generate a new password.

Credential format

Field	Format	Example
Username	smtp_ + 16 random characters	smtp_aB3xK9mP2qR5wY7z
Password	sk_ + 32 random characters	sk_4f8Hj2kLmN6pQrStUvWxYz1a3B5cD7e

Credential lifecycle

Active credentials. New credentials are active by default. Active credentials can authenticate SMTP connections and send emails.

Rotating. If a credential may have been compromised, or as part of regular security hygiene, you can rotate it:

1. Navigate to Settings > SMTP Credentials
2. Click Rotate on the credential
3. Copy the new password immediately
4. Update your application's SMTP configuration
5. The old password is immediately invalidated

tip

To rotate with zero downtime: create a new credential, update your application to use it, then revoke the old one.

Revoking. Revoking a credential disables it without deleting it. This is useful for temporarily disabling access:

1. Click Revoke on the credential
2. Any active SMTP sessions using this credential will fail on the next authentication
3. The credential can be re-enabled later by updating its status

Deleting. Deleting a credential permanently removes it. This cannot be undone:

1. Click Delete on the credential
2. Confirm the deletion
3. The credential is permanently removed

Security best practices

• Use separate credentials for each environment (development, staging, production)
• Use separate credentials for each application or service that sends emails
• Rotate credentials regularly as part of your security policy
• Revoke immediately if a credential may have been exposed
• Never commit credentials to source control — use environment variables or secrets management
• Monitor last-used timestamps in the dashboard to identify unused credentials

Tracking usage

The dashboard shows for each credential:

Field	Description
Name	Optional label you assigned
Username	The SMTP username
Status	Active or Revoked
Last Used	Timestamp of the most recent authentication
Created	When the credential was generated

Rate limits

Each organization can submit 50 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 50 msg/s/org — back-pressure is cheaper than reactive retries, since 421 only fires after the body has finished uploading.

The REST API has its own separate limit — see Rate limiting.