What causes the bounce code 4.7.0 'Too many concurrent connections' and how can it be resolved?
Published 28 Apr 2025
Updated 10 Oct 2026
13 min read
Summarize with
Updated on 10 Oct 2026: We clarified SMTP connection limits, retry handling, and the checks needed to resolve 4.7.0 deferrals.
Bounce code 4.7.0 "Too many concurrent connections" means an SMTP server temporarily refused the delivery attempt because a simultaneous-session limit was reached at that hop. It is a throttling deferral, not a final rejection. The system submitting to that server must reduce connection concurrency, pace delivery, and queue the message for a later retry.
The important practical point is ownership. If a destination MX returns the reply to an ESP, the ESP controls delivery concurrency, retries, queue behavior, and pool selection. If your own submission relay returns it before accepting the message, the application or relay administrator owns the fix. A domain owner should gather the full SMTP transcript and identify the rejecting hop before escalating.
Short answer: treat this as a temporary delivery-pressure signal. Identify the SMTP server that issued the reply, confirm the message entered a retry queue, and cap concurrent sessions to that server. If an ESP is delivering to the affected MX, ask it to adjust destination-specific concurrency and retry pacing before considering pool separation.
What the code means
SMTP reply codes beginning with 4 are temporary failures. The receiving server is saying, in effect, "not now, try again later." The enhanced status code 4.7.0 means other or undefined security or policy status, so it does not define a connection limit by itself. The accompanying "Too many concurrent connections" text supplies the useful detail: the server has reached or enforced a limit on simultaneous SMTP sessions. Concurrency is the number of sessions open at once; a connection-rate limit counts new connections over time, while a message-rate limit counts messages. Reusing a bounded connection pool reduces connection churn, but message pacing is still needed when a separate send-rate limit applies.
Typical bounce texttext
421 4.7.0 Too many concurrent connections 451 4.7.0 Too many concurrent connections 421 4.7.0 Too many connections, try again later
The leading reply code can vary by implementation. A 421 response closes the transmission channel, while 451 reports a temporary processing failure. Preserve the reply code, enhanced code, diagnostic text, responding hostname, and SMTP stage. The SMTP client should act on the 4xx reply by queueing the message and retrying later.
|
|
|
|---|---|---|
4.x.x | Temporary deferral | Queue and retry |
4.7.0 | Undefined security or policy status | Read the diagnostic text |
421 | Service unavailable, channel closing | Reconnect after backoff |
451 | Temporary processing failure | Keep the message queued |
How to read common connection-limit bounce details
Find the SMTP hop that set the limit
The same wording can appear at different SMTP hops. Check which hostname or IP returned the reply and whether the message had already been accepted into a delivery queue. This separates a submission problem in your application path from a remote-delivery problem at the destination MX. The relay's final 250 response after DATA confirms that it accepted responsibility for the message; a 250 response to an earlier command does not. Submission acceptance does not confirm delivery to the final recipient.
|
|
|
|---|---|---|
Application to submission relay | Reply occurs before the relay accepts or queues the message | Application and relay administrator |
Outbound MTA to destination MX | Provider log shows a queued message and remote SMTP response | ESP or outbound MTA operator |
Gateway to internal mail server | Gateway accepts external mail but its downstream queue grows | Receiving mail administrator |
Use the SMTP transcript and queue event to assign ownership
An application that opens many parallel SMTP sessions and has no retry logic can lose messages immediately even though 421 is temporary. Use a durable queue, limit the connection pool, and reuse sessions where supported. After a 421 response, discard the closed connection and reconnect only after a delay.
Why SMTP connection limits are reached
The immediate cause is a live-session limit at the SMTP server that returned the reply. The limit can apply per source IP or authenticated account, or across the whole server. It can be fixed, reduced dynamically because of load or sender reputation, or reached by a burst that opens new connections faster than the server closes old ones.
- Fixed server cap: Some submission relays and receiving gateways accept only a small number of simultaneous connections per authenticated account or source IP, and can also enforce a total server cap.
- Reputation-based cap: A receiver can reduce concurrency for a sending IP when it sees complaint risk, unknown recipients, previous connection errors, unusual traffic spikes, or uneven behavior on a shared pool.
- Shared-pool pressure: On a shared ESP pool, other senders can add traffic to the same destination or weaken the pool's reputation. A clean transactional stream can still inherit the pool's current limits.
- Aggressive batching: A queue or application that opens too many sessions to the same server at once will hit limits even when the messages are legitimate and authenticated.
- Server capacity: The SMTP server can have a temporary load or resource issue. This often produces intermittent deferrals and a growing delivery queue until capacity recovers.
- Idle connections: Oversized connection pools and sessions left open after sending consume slots even when message volume is low.
Flowchart for 4.7.0 connection deferrals: MX checks, retry counts, ESP adjustments, and dedicated IP consideration.
Fixed server limit
- Pattern: The same server returns the error at a consistent connection level.
- Fix: Throttle parallel sessions or safely raise the cap on a server you control.
- Owner: The operator on the client side or the administrator of the limiting server.
Dynamic receiver limit
- Pattern: Deferrals change across sending IPs, destinations, or traffic spikes.
- Fix: Reduce bursts, improve list hygiene, and isolate the stream when shared-pool evidence supports it.
- Owner: The outbound operator plus the sending domain owner.
Who can resolve it
If you send through an ESP and a destination MX returns the reply, the ESP usually has the lever that matters: destination-specific connection limits. The sender can request the change, but the ESP has to tune its delivery engine. That includes maximum concurrent sessions per domain or MX, retry intervals, queue pacing, and the IP pool used for the traffic. If several recipient domains share an MX, separate per-domain connection pools can still exceed a limit at the same receiving host.
This is why the first escalation should include the responding hostname, SMTP hop, destination domain or MX, UTC timestamp, sending IP, message ID, full reply, retry history, and affected volume. A vague ticket saying "we got 4.7.0" is hard to act on. A ticket showing that 300 transactional messages to the same business gateway deferred over 40 minutes gives the ESP a specific routing or throttling problem to investigate.
SMTP delivery logs showing a 421 4.7.0 'Too many concurrent connections' deferral and queued retries.
|
|
|
|---|---|---|
Connection pool | Application or ESP | Fewer open sessions |
Retry timing | Application or ESP | Less repeated pressure |
Receiver cap | Receiving administrator | More safe capacity |
Dedicated IP | Sender and ESP | Separate source identity |
Authentication | Sender | Stronger trust signals |
List hygiene | Sender | Fewer bad attempts |
Ownership of common fixes
How to troubleshoot it
Use a simple sequence: confirm the error class, locate the SMTP hop that returned it, group events by responding host, check the final retry outcome, then decide whether the issue needs pacing, server-capacity work, pool separation, or broader reputation work. Avoid drawing a conclusion from one bounce line.
- Collect the full event: Save the SMTP reply, enhanced status code, responding host, destination MX, recipient domain, sending IP, message ID, SMTP stage, and UTC timestamps.
- Locate the limiting hop: Confirm whether the message failed before submission, during remote delivery, or between a gateway and an internal server.
- Group by responding host: A single affected MX or relay suggests a host-specific limit. Group recipient domains that share that MX together, and compare sending IPs before assigning a broader pattern to the sending infrastructure.
- Check retry outcome: Track whether each message remains queued, later delivers, or expires, and record the oldest queued message's age. If the client does not queue 4xx failures, fix its retry logic before sending another burst.
- Review infrastructure: Shared pools can create shared traffic pressure. Dedicated IPs give the sender clearer attribution, but they need warming and steady volume.
- Audit trust signals: Check SPF, DKIM, and DMARC for separate authentication failures. A connection-limit reply alone does not establish an authentication problem or a reputation-based cap.
Use delayed retries with increasing backoff and jitter, rather than reconnecting every few seconds. RFC 5321 recommends a general retry interval of at least 30 minutes and allows variable strategies when the client knows the failure reason. Check the provider's actual retry schedule and queue lifetime. A temporary connection deferral does not establish that the recipient address is invalid, so do not permanently suppress it solely for this reply.
For a quick operational check, send a real test message and inspect authentication, headers, and visible delivery issues with Suped's Email tester. Its results describe authentication and formatting for that test recipient; use the affected receiver's SMTP logs to diagnose its concurrency limit.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Do not treat a single 4.7.0 bounce as proof of damaged sending reputation. Treat a pattern as actionable when it clusters around one responding host, repeats across retry windows, affects time-sensitive transactional mail, or ends in expired messages after the retry limit is reached.
Check active SMTP connections and per-IP limits
If you control either SMTP endpoint, inspect live connections while the error is occurring. On Linux, this read-only command lists established TCP connections on common SMTP ports. Substitute the actual port if your relay uses a different one.
Inspect active SMTP connections on LinuxBASH
ss -tn state established \ '( sport = :25 or dport = :25 or sport = :465 or dport = :465 or sport = :587 or dport = :587 )'
A local SMTP service port normally indicates an inbound connection; a peer SMTP service port normally indicates an outbound connection. This is a snapshot on one host, so compare it with the SMTP server's own session counters.
- Compare the count with the effective per-client and total server caps. There is no universal safe SMTP connection limit.
- Count all workers and sending servers sharing a public IP through network address translation (NAT); the receiver can count them as one client.
- Close pooled sessions when they are no longer needed, and use timeouts to prevent abandoned sessions from consuming slots.
- Reduce outbound concurrency first. Increase a receiving server's cap only after checking CPU, memory, file descriptors, and queue capacity.
Shared IP or dedicated IP
A shared IP can work well for transactional email when the ESP manages traffic carefully. The weakness is that you share reputation and routing decisions with other customers, and their traffic can add pressure at the same destination. If clean traffic still gets intermittent "too many connections" deferrals, ask the ESP for evidence at the pool and MX level.
Stay on shared IPs
This is reasonable when affected volume is low, retries deliver within an acceptable window, and the ESP can tune destination limits without moving the stream.
- Benefit: Less warming and less operational ownership.
- Risk: Pool traffic can affect destination limits.
Move to a dedicated IP
This fits a steady, higher-volume stream after the ESP confirms that shared-pool behavior contributes to harmful delays or expiry.
- Benefit: Separate reputation and source identity.
- Risk: Requires warm-up and stable sending patterns.
A dedicated IP does not remove a destination's connection cap. It separates the sending source and makes attribution clearer, but a bursty transactional stream can still open too many sessions. Try destination-specific pacing first unless shared-pool evidence and steady volume support migration.
Escalation thresholds
Use these operational indicators to decide when a temporary connection deferral needs action; they are not standardized connection-count thresholds.
Normal
Low
Rare deferrals that deliver on retry
Watch
Medium
Repeated deferrals at the same SMTP host
Escalate
High
Retries expire or transactional delivery exceeds its required window
Where Suped fits
Suped is our DMARC reporting and email authentication platform. The SMTP operator controls connection pools and delivery queues. Suped's authentication results and sending-source history add context to the SMTP logs, but DMARC aggregate reports do not show live sessions or individual retry outcomes. A refusal at the SMTP greeting occurs before the receiver can evaluate that message's DMARC result.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For teams that manage multiple domains or transactional streams, Suped's DMARC monitoring gives a clear view of authentication pass rates and sending sources. Suped's domain health checks help confirm SPF, DKIM, and DMARC basics, while blocklist monitoring tracks whether blocklist or blacklist issues are developing alongside the connection errors.
Use Suped to check authentication and sending-source changes, and review blocklist (blacklist) alerts alongside the SMTP logs. Include queue outcomes and the responding host when escalating to the operator that controls that hop.
What to send the ESP
The fastest way to get help is to write the ticket as an operations problem. Include the pattern, the business impact, the affected SMTP hop, and the exact change requested.
ESP ticket templatetext
Subject: 4.7.0 concurrent connection deferrals to specific MX hosts We are seeing repeated temporary failures with this response: 421 4.7.0 Too many concurrent connections Affected stream: transactional email Affected UTC window: [start] to [end] Sending domain: example.com Sending IPs: 192.0.2.10, 192.0.2.11 Responding SMTP host: mx1.example-mx.net SMTP hop: outbound MTA to destination MX Message IDs: [include examples] Final outcomes: [delivered after retry or expired] Please review destination-specific concurrency, retry pacing, and pool routing. Some messages are expiring after repeated temporary deferrals.
If the ESP confirms the affected traffic is on a shared pool, ask whether it can set stricter destination concurrency for the remote MX, route the stream through a pool with less pressure, or move a steady stream to a dedicated IP with a warm-up plan. Keep monitoring messages that later deliver. Treat expired retries as a production incident for time-sensitive mail.
It also helps to classify the failure correctly. This error belongs with soft bounces, but repeated deferrals can end in a final delivery failure when the retry queue expires. Some systems then report 5.4.7 'Delivery time expired'; keep the earlier 4.7.0 replies to identify the cause.
Views from the trenches
Best practices
Group bounce evidence by responding SMTP host before asking the ESP to tune concurrency.
Confirm final retry outcomes so temporary deferrals do not quietly become failed deliveries.
Separate transactional streams only when shared IP evidence supports changing the pool.
Common pitfalls
Treating a truncated bounce line as complete evidence slows a useful provider escalation.
Assuming clean domain reputation rules out shared IP connection pressure misses the cause.
Moving to a dedicated IP without enough steady volume and warm-up creates another risk.
Expert tips
Ask for destination-specific concurrency changes before changing the message content.
Track the SMTP response and final delivery result, including expiry, for each message.
Use authentication and blocklist (blacklist) checks to investigate separate trust issues.
Marketer view
Marketer from Email Geeks says the sending provider controls the connection settings unless the sender has direct access to MTA concurrency controls.
2024-10-08 - Email Geeks
Marketer view
Marketer from Email Geeks says a receiver can enforce a fixed connection cap or adjust the cap based on the sender's reputation.
2024-10-08 - Email Geeks
How to resolve 4.7.0
The direct fix is to reduce concurrent SMTP sessions to the server that returned the reply, delay repeated attempts, and keep deferred mail in a durable queue. The ESP controls these changes for remote delivery; the application or relay administrator controls them for submission failures. After the change, confirm that the oldest queued message's age falls and deferred messages deliver within the required window.
