Question 1

What is an SMTP relay service and why do I need one?

Accepted Answer

An SMTP relay service is an authenticated outbound mail server that accepts messages from your application over the Simple Mail Transfer Protocol and forwards them to recipient mailbox providers — Gmail, Outlook, Yahoo, corporate mail systems — on your behalf. You need one because consumer ISPs and most cloud providers block outbound port 25 by default, and even when they do not, sending directly from an application server produces low inbox-placement rates because the originating IP lacks the reputation, DKIM signing, SPF alignment, and bounce-handling that mailbox providers require. **Inbox OSS provides authenticated SMTP relay on ports 587 (STARTTLS) and 465 (implicit TLS)** with full deliverability tooling layered on top: DKIM signing, suppression checks, feedback-loop routing, reputation monitoring, and per-IP warmup — all applied automatically to every message that passes through the relay.

Question 2

How do I configure WordPress to send through the SMTP relay?

Accepted Answer

Install the WP Mail SMTP plugin (the free version is sufficient) and configure it with **host smtp.inbox.onesourcesoft.com, port 587, encryption STARTTLS, authentication enabled, username apikey, and password set to your Inbox OSS API key**. Alternatively, drop the WPMS_* constants into wp-config.php for environments where the plugin UI is locked down. Once configured, every email WordPress sends — password resets, comment notifications, WooCommerce order confirmations, contact form submissions — flows through the relay with DKIM signing and click tracking applied. The migration takes under 5 minutes and requires no theme or plugin code changes. Compared to plugin-based SMTP providers like SMTP2GO or SendLayer, you get full enterprise deliverability tooling and a real dashboard rather than a basic send log.

Question 3

Does the SMTP relay work with Rails ActionMailer?

Accepted Answer

Yes. Configure config.action_mailer.smtp_settings in your production environment with address smtp.inbox.onesourcesoft.com, port 587, authentication :plain, user_name apikey, password ENV['INBOX_API_KEY'], and enable_starttls_auto true. ActionMailer will send every Mailer class through the relay without any change to mailer files, view templates, or controller code. The relay handles connection pooling, retries on transient failures, and async delivery so your request threads are not held up by SMTP handshakes. For background-job heavy Rails apps using Sidekiq or GoodJob, the SMTP relay scales horizontally — you can open hundreds of concurrent SMTP sessions per worker without rate-limiting from our side.

Question 4

What TLS versions does the SMTP relay support?

Accepted Answer

The relay requires **TLS 1.2 or TLS 1.3** for every authenticated session. Plaintext SMTP submissions are refused at the door — there is no fallback to cleartext, even for clients that request it. On port 587 the connection upgrades via STARTTLS immediately after the EHLO greeting; on port 465 the TLS handshake completes before any SMTP commands are exchanged (implicit TLS). Cipher suites are limited to AEAD-only constructions (ChaCha20-Poly1305 and AES-GCM). Older clients that only support TLS 1.0/1.1 or RC4 ciphers will be rejected. This conforms to current Mozilla Modern profile guidance and NIST SP 800-52 Rev. 2.

Question 5

How is the SMTP relay authenticated?

Accepted Answer

Authentication uses standard SMTP AUTH with the username **apikey** (literal string) and your Inbox OSS API key as the password. We support AUTH LOGIN, AUTH PLAIN, and AUTH CRAM-MD5 mechanisms. API keys are SHA-256 hashed at rest and carry the same scopes and IP allowlists configured on the API side — so an API key restricted to your application server IPs cannot be used from anywhere else, even via SMTP. This is meaningfully more secure than competitors that use account-level SMTP passwords (Mailgun, SES default configuration) because compromised credentials can be revoked per-key without rotating the entire account.

Question 6

What throughput can the SMTP relay sustain?

Accepted Answer

Every authenticated session supports SMTP pipelining (RFC 2920) and CHUNKING (RFC 3030), which lets a single connection deliver thousands of RCPTs without round-trips between commands. Practical sustained throughput from a well-configured client is around **5,000-15,000 messages per minute per session**, with no hard upper cap on parallel sessions per account. Rate limiting is applied per-API-key at the same limits as the REST API (typically 600 messages per second per key, higher on Pro and Enterprise). For very high-volume batches, the recommended pattern is to fan out across 8-16 concurrent SMTP sessions rather than serializing through one — this matches our internal worker topology and produces the highest aggregate throughput.

Question 7

Does the relay support categories and custom args via SMTP?

Accepted Answer

Yes. Add **X-INBOX-Category: onboarding** or **X-INBOX-Custom-Arg-user_id: 42** headers to the outbound message and we will parse them on intake, stamp the message with the category and custom-arg metadata, and surface them in dashboards, webhook payloads, and analytics splits exactly as if you had set them via the REST API. Multiple categories can be supplied by comma-separating the header value. This makes the SMTP path feature-complete with the API path — you do not lose tracking, categorization, or attribution by choosing SMTP over REST.

Question 8

What happens to messages that bounce or fail through the SMTP relay?

Accepted Answer

Soft bounces and transient SMTP failures retry with exponential backoff for up to 72 hours, exactly the same as messages submitted via the REST API. Hard bounces are recorded against your account suppression list immediately and surfaced via the bounced webhook event. Failure visibility goes deeper than competing relays: the dashboard message log shows the full SMTP conversation — every command, every response code, every reason text — so you can diagnose root-cause exactly. This is meaningfully better than SendGrid and Mailgun, which often surface only a parsed bounce category without the underlying SMTP response.

Question 9

Can I use the same API key for both SMTP and the REST API?

Accepted Answer

Yes, and most customers do. A single API key authenticates both the REST API at api.inbox.onesourcesoft.com and the SMTP relay at smtp.inbox.onesourcesoft.com — the scopes, rate limits, and IP allowlists apply uniformly to both protocols. This simplifies operations: rotating a credential rotates both transports at once, and the audit log captures activity from both endpoints under the same key. If you prefer protocol-specific keys for least-privilege reasons, you can issue separate keys and tag them with descriptive names in the dashboard.

Question 10

How does the Inbox OSS SMTP relay compare to Amazon SES?

Accepted Answer

Amazon SES SMTP is a competent low-cost relay but requires significant operational glue to be production-grade: you have to configure bounce and complaint topics in SNS, build your own suppression-list management, attach your own warmup logic, write a click-and-open tracking layer, and assemble a dashboard. **Inbox OSS gives you all of that on day one in a single product** at a comparable per-message price. SES is the right call when you already run heavy AWS infrastructure and have an SRE team to absorb the operational burden. Inbox OSS is the right call when you want the same deliverability without building the platform around it. See our [SES comparison page](/compare/amazon-ses) for a feature-by-feature breakdown.

Drop-in SMTP for apps you can't easily refactor

Every email through SMTP gets the full treatment

Authenticated SMTP

TLS 1.3 required

Live diagnostics

Anycast endpoints

High throughput

Categories + tags

Frequently asked questions about SMTP relay

Migrate your SMTP in a single config change.