Skip to content

SMTP and REST API Injection Best Practices for Improved Performance

At MX18, our goal is to provide you with the most reliable and performant email sending experience. To help you get the best results, here are a set of best practices to optimize how you inject emails — whether through our REST API or SMTP.

Sending via MX18 Rest API

The REST API is our recommended method for sending, especially for high-volume and performance-focused applications. It offers better control, efficiency, and reliability compared to SMTP.

Recommendations

Use the REST API where possible
- It requires fewer system resources and provides faster response handling.

Handle timeouts and 5XX errors with retries
- Always retry on network or server errors. Use exponential backoff starting with a 5-second delay.

Set API timeouts appropriately
- We recommend setting your client timeout to 300 seconds.

Keep transmission payloads lightweight
- It's best to keep each payload under 20MB — including content, recipient list, and dynamic data.

Send smaller, parallel transmissions
- Instead of large single calls, break them into smaller batches.
- For example, send 10 transmissions of 2,000 recipients each rather than 4 transmissions of 5,000.

For large-scale campaigns (100K+ recipients):
- Max recipients per transmission: 10,000
- Min recommended: 2,000
- Max transmissions per connection: 10,000

Rotate connections
- Use a connection for a maximum of 15 minutes, then start a new one.

Respect DNS TTLs for API hostnames
- We use dynamic load balancing. Your app should perform a fresh DNS lookup for each new connection to ensure routing to active nodes.

Limit concurrent connections
- Up to 10 concurrent connections are allowed by default.
- Enterprise users can request custom limits via support@mx18.com.

Sending via SMTP

SMTP remains a widely used and reliable protocol. If you choose to use it, follow these guidelines to maximize performance and deliverability.

Recommendations

  • Use parallel SMTP connections
    Run multiple injections concurrently — up to 10 connections at a time is optimal.
    (Enterprise plans may support more upon request.)

  • Keep TCP connections open between messages
    Avoid reconnecting for every email. Reuse each connection for up to 100 messages, then create a new one to free up resources.

  • Enable SMTP pipelining
    This reduces roundtrip latency by allowing multiple commands to be sent without waiting for individual responses.

  • Always use TLS encryption
    TLS secures message content, recipient info, and API credentials during transmission.

  • Limit exposure of credentials
    If TLS is not supported in your system, generate API keys with only “Send via SMTP” privileges and rotate them regularly.

  • Retry on soft failures
    On timeouts or 4XX errors, retry the delivery with exponential backoff.

  • Set proper timeout values

  • Minimum of 30 seconds for the AUTH phase
  • General timeouts can follow RFC 5321 guidelines (Section 4.5.3.2)

General message size considerations

  • Keep individual message size below 100KB for optimal inbox placement.
  • For emails with images or attachments, ensure total size (including headers, body, images, and files) is under 20MB.
  • Note: MX18 billing includes 200KB as part of base message size. Each additional 200KB will be billed as one additional unit.

Need help?

If you’re unsure which approach is best for your use case or need help optimizing throughput:

We’re here to help you scale with confidence