Understanding SMTP rate limits

The basics

To keep our sending infrastructure reliable and fair for all customers, we limit two things per sending IP address:

• New connections per second: up to 5 new SMTP connections per second (averaged over a 60-second window).

• Data throughput per connection: up to 10 MB/s per connection.

For most everyday setups: a website sending welcome emails, an accounting tool sending invoices, these limits are well above your typical sending rate. You are unlikely to notice them.

How much email is that, exactly?

It depends on message size. Here are three common scenarios:

Maximum message size: 25 MB per message (about 18 MB of actual content after encoding). Anything larger is rejected outright — use a cloud storage link instead.

These rates are sustained, meaning you can keep going at that pace all day without hitting a wall — as long as your application reuses SMTP connections (called connection pooling), which every standard mail library does by default.

What happens if a limit is hit?

Too many new connections (over 5/sec from one IP)

Our server rejects the excess connections at the network level. Your application will see a "connection refused" or "connection reset" error. What happens next depends on your software:

• Well-built systems (most modern mail libraries, PHPMailer, etc.) catch the rejection, wait briefly, and retry. Email still gets through, just slightly delayed.
• Poorly built systems may report the message as failed without retrying. You may see missing welcome emails or stuck invoices.
• Systems that retry too aggressively (no delay, looping immediately) are automatically blocked for 1 hour by our anti-abuse system. During that window, all connections from that IP are silently dropped, and your software will behave as if our server has gone offline. The block lifts automatically after an hour.

Repeated blocks: If the same IP triggers 5 ban events within 24 hours, the next block extends to 7 days. Contact support if this happens; it usually means something is badly misconfigured.

Too many failed login attempts

If a client fails to authenticate 5 times within 10 minutes (usually a misconfigured app with outdated credentials), that IP is blocked for 1 hour. Fix the credentials and wait for the block to expire, or contact support for an early unblock.

Too much data per connection (over 10 MB/s)

Nothing is rejected; we simply slow the connection down to the 10 MB/s ceiling. Your software won't see an error; sending will just appear slightly slower. In practice, this almost never affects normal email:

• A 2 MB invoice at 10 MB/s = about 200 ms.
• 100 invoices back-to-back through one connection = about 20 seconds.

Bulk sends (e.g. 5,000 invoices at once)

Most billing tools handle this gracefully; they open a small pool of long-lived connections (2–5) and pipeline messages through them. A 5,000-invoice run typically finishes in a few minutes without ever approaching our limits.

If a system opens a fresh connection per invoice and tries to send all 5,000 simultaneously, it will hit the 5 conn/sec ceiling. A well-behaved system retries and completes successfully, just more slowly.

For developers and sysadmins

Endpoint details:

Rate limits per source IP:

Throughput per source IP:

Note: The bandwidth cap binds before the connection count for all but the smallest messages. To exceed these aggregate rates, split egress across multiple source IPs.

Recommended client behaviour

• Connection pooling: Open 2–5 long-lived TLS connections per application instance and pipeline messages through them. Do not open a new TCP socket per message — with a 5 conn/sec cap you will hit the limit immediately.
• Retry strategy: Exponential backoff starting at ~1 second, jitter ±30%, max 5 attempts. Treat 421 4.x.x, other 4xx, and connection-reset as retryable. Treat 5xx as permanent — do not retry.
• High-volume senders: If a single source IP legitimately needs more than 5 new connections/sec sustained, split egress across multiple source IPs. If that isn't possible, contact support — high-volume sources can be whitelisted on a case-by-case basis.
• TLS: Use TLS 1.2 or 1.3. Port 465 uses implicit TLS (from the first byte). Ports 25 and 587 use STARTTLS. Never send credentials over a plaintext connection.

Diagnosing connection issues

Still need help?

If you're seeing persistent connection issues or believe your IP has been incorrectly blocked, get in touch with our support team on help@touchbasepro.com and include your source IP address. We're happy to take a look.