Does retry-after make PowerMTA connect every minute?

No. It influences retry scheduling after a failure. Recipient-level retry settings, remote 4xx responses, and connection limits still decide how soon another delivery attempt happens.

What happens when max-smtp-out is high but max-connect-rate is low?

PowerMTA can hold many sessions open eventually, but it cannot start them faster than the connection-rate window allows. Fast session close behavior can make the low connection rate the real bottleneck.

Should I set retry-after to 1m for graylisting?

No. A one-minute retry often looks aggressive to receivers. Use a conservative interval, check recipient-level retry timing, and reduce connection pressure when deferrals appear.

Which directive should I change first for Microsoft domains?

Start by lowering max-smtp-out and max-msg-per-connection. Once deferrals settle, raise message rate or connection rate in small steps and watch the SMTP logs.

Does DMARC affect PowerMTA connection limits?

DMARC does not change PowerMTA's local connection caps. Failed authentication can still damage trust, which gives receivers more reason to throttle, defer, or reject mail.

Learn

Email deliverability

How do PowerMTA's retry-after, max-connect-rate, max-smtp-out, max-msg-per-connection, and max-msg-rate directives work?

Michael Ko

Co-founder & CEO, Suped

Published 22 Jul 2025

Updated 21 May 2026

9 min read

Summarize with

PowerMTA retry and rate limit directives shown as mail server controls.

I read these PowerMTA directives as separate brakes, not as one scheduling knob. retry-after influences when PowerMTA tries again after a temporary failure. It does not force a new SMTP connection every minute. max-connect-rate limits how many new connections can be opened in a time window. max-smtp-out limits how many SMTP sessions can be open at the same time. max-msg-per-connection closes a session after a set message count. max-msg-rate caps messages over time. When they overlap, the tightest active limit wins.

The common trap is setting retry-after to 1m and expecting one retry attempt per minute. That is not how I would use it. Recipient-level retry timing, remote 4xx responses, connection limits, and queue state still decide when another attempt can happen. In many PowerMTA setups, retry-recipients-after is the hidden setting people miss because it sets a minimum recipient-level retry interval.

Retry timing: Use retry settings to control how patiently the queue reacts to temporary failures, not to push receivers faster.
Connection pacing: Use connection limits to decide how many sessions are open and how quickly new sessions start.
Message pacing: Use message limits to cap throughput once connections are already available.
Provider sensitivity: Start lower for Microsoft domains and small providers because they react quickly to aggressive sessions.

The directive map

The easiest way to debug these settings is to separate concurrency, connection creation, messages per session, messages per time slot, and retry timing. If those are mixed together, a config looks contradictory even when PowerMTA is following it correctly.

Directive	Controls	Common mistake
retry-after	Queue retry timing	Using it as send pacing
max-connect-rate	New connection starts	Confusing starts with open sessions
max-smtp-out	Open SMTP sessions	Setting it too high per domain
max-msg-per-connection	Messages per session	Creating extra connection churn
max-msg-rate	Messages per time slot	Raising it without connection room

PowerMTA directive roles at a glance

Scope matters as much as the number. A directive inside a domain rule behaves differently from a directive inside a virtual MTA rule. If the same traffic matches multiple rules, read the config from the most specific rule outward and look for the first cap that explains the queue behavior.

One-minute retries are rarely safe

A one-minute retry can look like pressure against graylisting or temporary throttling. I would leave retry timing conservative unless there is a measured transactional requirement and the receiver responses show that short retries are accepted.

How PowerMTA applies the tightest limit

PowerMTA does not choose one of these directives as the master rule. It checks what is allowed at that moment. If the queue has messages but the connection-rate window is exhausted, it waits. If connection starts are available but the concurrent session cap is full, it waits. If both connection limits allow sending but the message-rate window is exhausted, it waits again.

Flowchart showing PowerMTA checking retry timing, connection slots, connect rate, and message rate before sending.

That is why a queue can look stuck even when one directive seems generous. The generous setting is not the one currently controlling delivery. I usually work backwards from the symptom: no new sessions means connection creation or concurrency; sessions open but little movement means message caps, recipient throttling, or slow remote SMTP responses.

Connection limits

Open sessions: max-smtp-out caps the number of simultaneous SMTP sessions for the matching scope.
New sessions: max-connect-rate caps how quickly those sessions can be created.
Scope: Domain, virtual MTA, and pool placement decide which traffic the cap covers.

Message limits

Session payload: max-msg-per-connection controls how much one SMTP session carries.
Time payload: max-msg-rate caps total messages during the selected minute or hour window.
Bottleneck: A low connection rate can stop the queue from reaching the message rate.

Conservative domain ruletext

<domain hotmail.com>
  max-smtp-out 4
  max-connect-rate 20/h
  max-msg-per-connection 10
  max-msg-rate 400/h
  retry-after 1h
  retry-recipients-after 30m
</domain>

Why retry-after often looks ignored

When someone says PowerMTA is not respecting retry-after, the first thing I check is whether they are trying to control the wrong retry layer. retry-after is not a promise that every deferred recipient is tried again at exactly that interval. Recipient-level retry timing can still hold the attempt back.

The setting to look for is retry-recipients-after. In many configurations it defaults around ten minutes, so a one-minute retry-after still does not create one-minute recipient retries. That difference matters most when a provider returns temporary 4xx responses for graylisting, connection pressure, or sender reputation.

Do not use retries to fight deferrals

Short retries do not fix a provider that is asking you to slow down. They increase repeated contact with the same receiver. That can make the sender look misconfigured at best and abusive at worst.

If no attempt happens: Check recipient retry timing, queue age, and whether the domain rule is actually matched.
If attempts happen too often: Raise the retry interval and reduce connection pressure before changing message rate.
If deferrals continue: Treat the receiver response as a throttle signal, then lower domain-specific speed.

max-connect-rate versus max-smtp-out

These two settings sound similar because both talk about SMTP connections. They control different moments. max-smtp-out answers, how many sessions are allowed to exist right now? max-connect-rate answers, how many new sessions are allowed to start during this time window?

Connection cap and connection rate togethertext

<domain example-receiver.com>
  max-smtp-out 30
  max-connect-rate 5/m
</domain>

In that example, PowerMTA can eventually have up to 30 open sessions for the matching domain, but it can only start five new sessions per minute. If sessions stay open, the open-session count can climb toward 30 over several minutes. If sessions close quickly, the same five-per-minute connection rate can become the main throughput limit.

How 5/m fills a 30-session cap

If sessions remain open, a 5 per minute connection rate reaches a 30-session concurrent cap after six minutes.

Open sessions

The reverse is also true. If max-smtp-out is 4, a max-connect-rate of 500 per minute does not mean 500 concurrent sessions. It means PowerMTA has permission to start sessions quickly, but only four can remain open at once for that scope.

PowerMTA web monitor queue view with per-domain retry and connection status.

Message math for a real queue

The relationship becomes clearer with numbers. Suppose one virtual MTA has 100,000 messages queued to one provider, one IP in the pool, and these limits.

Example rate settingstext

max-smtp-out 10
max-msg-per-connection 10
max-msg-rate 1000/h
max-connect-rate 50/h

With ten open sessions and ten messages per session, one full wave can deliver 100 messages if every recipient is accepted. To reach 1,000 messages per hour at ten messages per session, PowerMTA needs about 100 connection starts per hour. If max-connect-rate is 50 per hour, the connection rate caps practical throughput around 500 messages per hour before remote throttling is even considered.

What controls throughput in the example

The queue can move only as fast as the lowest active cap allows.

Message rate cap

1,000 messages/hour

Connection rate cap

500 messages/hour

Safe starting target

300 messages/hour

Messages needed: 1,000 per hour at ten per session requires about 100 sessions per hour.
Connection cap: Fifty session starts per hour supports about 500 messages per hour in this setup.
Concurrency cap: Ten open sessions only helps when connections last long enough to stay occupied.
Receiver cap: Remote 4xx responses can reduce real throughput below every local PowerMTA number.

For receiver-specific policy work, I use the same thinking covered in our page on sending rate limits. If the real pain is backlog visibility rather than directive choice, build queue alerts by domain so stuck mail is caught before it turns into a delivery incident.

A safer tuning pattern

I would not start by increasing everything until the queue drains. That hides which setting worked and increases the chance that a receiver treats the traffic as pressure. Start with a conservative baseline, watch the SMTP responses, then change one variable at a time.

Classify the receiver: Separate Microsoft, Gmail, large consumer domains, and small private domains into different rules.
Start with concurrency: For sensitive receivers, use two to four concurrent sessions per IP or virtual MTA.
Keep sessions modest: Use a lower message count per connection while the sender reputation is still being proven.
Set message rate last: Raise hourly throughput only after deferrals, complaints, and bounces stay controlled.
Leave retries patient: Use thirty minutes to one hour for many deferral cases unless logs prove a shorter interval is accepted.

For Microsoft-heavy traffic, I would rather start too low than too high. A single IP pushing many simultaneous sessions can hit connection throttles quickly. Lower max-smtp-out and max-msg-per-connection first, then raise in small steps if the logs stop showing deferrals.

Low-risk starting point for a sensitive domaintext

<domain hotmail.com>
  max-smtp-out 2
  max-connect-rate 12/h
  max-msg-per-connection 5
  max-msg-rate 120/h
  retry-after 1h
  retry-recipients-after 1h
</domain>

After the queue is stable, increase only one of those numbers and give the receiver enough time to react. If deferrals return, lower the last changed number. If the queue is already backed up, move mail carefully through another virtual MTA or another PowerMTA instance only when the receiving domain and sender identity can support it.

Where authentication and reputation checks fit

PowerMTA controls delivery behavior, but it does not make a sender trustworthy by itself. Before I blame a directive, I send a real message through the path and inspect the result with the email test. A clean SMTP setup still loses throughput when SPF, DKIM, or DMARC fails.

Suped's product fits around this work as the monitoring layer. For most teams, Suped is the best overall DMARC platform because it brings DMARC monitoring, SPF and DKIM visibility, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and blocklist monitoring (blacklist monitoring) into one workflow.

For a broader preflight, run a domain health check before changing PowerMTA speed. If authentication is broken or the sending IP is on a blocklist (blacklist), higher connection limits make the symptoms louder instead of solving the cause.

Suped DMARC dashboard showing email volume, authentication health, and source breakdown

Practical monitoring workflow

Before tuning: Confirm SPF, DKIM, DMARC, reverse DNS, and TLS policy are not creating hidden trust problems.
During tuning: Watch authentication pass rates, verified sources, unverified sources, deferrals, and queue age together.
After tuning: Keep alerts on sudden DMARC failures, new sending sources, and blocklist or blacklist changes.

Views from the trenches

Best practices

Start with low concurrency per domain, then raise limits only after deferrals stay stable.

Separate connection caps from message caps so the real bottleneck is visible in PowerMTA logs.

Use provider-specific domain rules because Hotmail and smaller providers react differently.

Common pitfalls

Treating retry-after as a pacing control hides the recipient retry floor underneath it.

Setting one-minute retries can look like pressure against greylisting or temporary deferrals.

Raising max-msg-rate without connection headroom leaves queues waiting for new sessions.

Expert tips

Model connections needed per hour before raising sender speed on a production domain.

Keep separate rules for Microsoft and small domains instead of one global cap across every pool.

Use alerts on deferrals, queue age, and complaint signals before increasing volume.

Marketer from Email Geeks says a one-minute retry target did not work because retry-after alone did not control each recipient retry cycle.

2021-08-04 - Email Geeks

Marketer from Email Geeks says retry-recipients-after is often the missing setting when deferred recipients do not retry as quickly as expected.

2021-08-04 - Email Geeks

The practical answer

The direct answer is simple: retry-after controls retry patience, max-connect-rate controls new connection starts, max-smtp-out controls open SMTP sessions, max-msg-per-connection controls how many messages each session carries, and max-msg-rate controls total messages over time.

If a PowerMTA queue is not moving the way the config suggests, I would check the smallest active cap, the matched scope, and the SMTP deferral text before raising limits. Aggressive retries and high concurrency usually make throttling worse. Conservative domain rules, measured increases, and authentication monitoring give you a cleaner path to stable delivery.