PowerMTA Delivery Rate Suddenly Dropped: Complete 2026 Operator Guide

Why a sudden drop is an incident

When PowerMTA's delivery throughput suddenly falls, it should be treated as an incident, not a curiosity to watch. A sudden drop means mail that should be going out is not, and several of the causes of a drop get worse the longer they run. A reputation problem feeding a throttling event escalates if sending continues at full pressure. A queue accumulating because of a drop keeps growing, consuming memory and disk. A throttling event left unanswered can escalate from deferral to outright rejection. The drop is rarely static; it tends to compound.

This guide exists to give operators a fast, structured way to diagnose and recover from a sudden delivery-rate decline. The good news is that a sudden drop has a recognizable set of causes, and the PowerMTA accounting log localizes which one applies. The structure of this guide: why the drop is urgent, how to distinguish a real drop from a harmless volume lull, the central technique of localizing the drop by ISP and sending IP, the difference between a drop concentrated at one receiver and one spread broadly, then each cause in turn, throttling, reputation, blacklisting, backoff, infrastructure and internal misconfiguration, and finally the structured recovery workflow. An operator who works through this restores throughput quickly, before the drop compounds into a larger problem.

A real drop versus a volume lull

Before diagnosing a drop, confirm it is real. A lower delivery rate is not always a problem: it can simply mean less mail to send.

Signal	Volume lull (no problem)	Real drop (problem)
Queue depth	Normal or low, not accumulating	Climbing, or deep and draining slowly
Delivery-to-deferral ratio	Normal ratio, just lower volume	Elevated deferral rate
Cause	Less mail submitted	PowerMTA delivering slower than it should
Action needed	None, it is normal	Diagnose and recover

A volume lull is when the rate is lower because less mail is being submitted, between campaigns, an off-peak hour, a quiet period in the schedule. PowerMTA is delivering everything promptly; the queues are not accumulating; the lower rate reflects lower demand.

A real drop is when PowerMTA has mail and is delivering it slower than it should. Queues accumulate because messages arrive faster than they leave, or existing queues drain slowly.

The distinguishing checks: run pmta show queues. Normal or low queue depth, not accumulating, means a lull. Climbing queue depth, or deep queues draining slowly, means a real drop. Also check the delivery-to-deferral ratio in the accounting log: a lull shows the normal ratio at lower volume, a real drop shows an elevated deferral rate. Confirming the drop is real before diagnosing prevents both wasted effort on a lull and missed attention on a genuine problem.

Localizing the drop by ISP and IP

Once a drop is confirmed real, the central diagnostic technique is localizing it: is the drop concentrated at one ISP, or spread across many? Is it on one sending IP, or all of them?

The accounting log answers this. Query recent delivery and deferral activity grouped by receiving domain:

SELECT
    rcptDomain,
    type,
    count() AS n
FROM pmta_accounting
WHERE timeLogged >= now() - INTERVAL 2 HOUR
GROUP BY rcptDomain, type
ORDER BY rcptDomain, n DESC;

This shows, per receiving domain, the count of deliveries (type d) versus deferrals (type t) and bounces (type b). A domain with a sharply elevated deferral count and depressed delivery count is where the drop lives.

Then group by sending IP to see whether the drop is IP-specific:

SELECT
    coalesce(dlvProxyServerIp, dlvSourceIp) AS source_ip,
    type,
    count() AS n
FROM pmta_accounting
WHERE timeLogged >= now() - INTERVAL 2 HOUR
GROUP BY source_ip, type
ORDER BY source_ip, n DESC;

The localization produces a two-dimensional picture:

Pattern	Points to
One ISP, all IPs affected	An ISP-specific throttle or reputation issue
One ISP, one IP affected	An IP-specific reputation problem at that ISP
All ISPs, one IP affected	That IP blacklisted or IP-specific problem
All ISPs, all IPs affected	A broad cause: auth, infrastructure, internal config

This localization is the diagnostic pivot. It turns a vague delivery-rate drop into a specific direction: an ISP-specific problem, an IP-specific problem, or a broad problem.

A drop concentrated at one ISP

When the localization shows the drop is concentrated at one receiving ISP, the cause is something specific to that ISP's relationship with the sender.

The likely causes for a one-ISP drop:

• An ISP throttling event. That ISP started deferring mail, slowing deliveries to it. The accounting dsnDiag will show that ISP's throttle codes.
• A reputation problem at that ISP. The sending reputation degraded specifically at that receiver, and it is filtering or slowing the mail.
• A queue in backoff for that ISP. PowerMTA detected throttling from that ISP and put the queue into backoff mode, so it is now sending slowly by design.

The diagnostic next step for a one-ISP drop is to read the dsnDiag text for the deferrals to that ISP. The diagnostic text names the specific reason: a Yahoo TSS04 throttle code, a Microsoft S3140, a Gmail rate-limit phrase. The dsnDiag tells the operator exactly what that ISP is signalling, which points directly to the recovery action.

A one-ISP drop is, in a sense, the more contained situation: it affects mail to one receiver, and the cause is the sender's relationship with that specific receiver. The recovery focuses on that ISP, reducing volume to it, addressing the reputation issue with it, exiting the backoff once the cause is resolved.

A drop spread across receivers

When the localization shows the drop is spread across many or all receiving ISPs, the cause is something broad, affecting the sender's mail to everyone.

The likely causes for a broad drop:

• A blacklist listing. A sending IP was added to a widely-consulted blocklist, and every receiver that checks that list is rejecting the mail.
• An authentication failure. An SPF, DKIM, or DMARC problem, perhaps a DNS record change or a key issue, is causing receivers broadly to reject or deprioritize the mail.
• An infrastructure or DNS problem. PowerMTA cannot resolve receiver MX records or cannot connect, affecting deliveries to everyone.
• An internal throttle misconfiguration. A configuration change accidentally lowered a rate limit, throttling the sender's own output.

A broad drop is, in a sense, the more serious situation, because it affects all the sender's mail at once. But it is also frequently diagnosable, because the broad causes have clear signatures: a blacklist listing shows up on a blacklist check, an authentication failure shows up in the dsnDiag as auth-related rejections, an infrastructure problem shows up as connection or DNS errors, an internal misconfiguration shows up as a config change that lowered a rate.

The diagnostic for a broad drop: check the dsnDiag for the rejection or deferral pattern across receivers (auth phrases point to authentication, throttle phrases without an obvious cause point to reputation or blacklisting), check blacklist status for the sending IPs, check whether PowerMTA can resolve DNS and connect, and check for any recent configuration change.

ISP throttling events

An ISP throttling event is one of the most common causes of a sudden one-ISP drop.

A throttling event is when a receiving ISP, in response to volume or reputation signals, starts deferring the sender's mail with 4xx codes. PowerMTA's deliveries to that ISP slow down because the ISP is accepting fewer messages. The dsnDiag shows the throttle codes: Yahoo's TSS04, Microsoft's S3140, Gmail's rate-limit phrases.

The recovery for a throttling event:

1. Confirm it is throttling. The dsnDiag throttle codes confirm the ISP is throttling rather than rejecting.
2. Reduce volume to that ISP. Lower the max-msg-rate for that ISP's domain block. Sending less into a throttling ISP is the correct response; continuing at full pressure makes it worse.
3. Let the backoff work. If PowerMTA has already put the queue into backoff, that is PowerMTA correctly slowing down. Do not force it out of backoff while the ISP is still throttling.
4. Investigate why. A throttling event has a reason, frequently a volume spike or a reputation signal like a complaint rate increase. Address the underlying reason.
5. Recover gradually. When the throttling cause is addressed and the ISP accepts mail again, increase the rate back up gradually rather than jumping to full volume.

A throttling event responded to promptly with reduced volume is usually a transient event that resolves. A throttling event ignored, with sending continuing at full pressure, escalates, and as the Gmail 421-to-550 pattern shows, can turn from deferral into outright rejection.

Reputation problems

A reputation problem causes a delivery drop when one or more ISPs, in response to degraded sending reputation, begin filtering or slowing the mail.

A reputation problem differs from a simple throttling event in that the cause is the sender's standing rather than a momentary volume spike. The signs: the drop persists rather than resolving quickly, the postmaster tools (Google Postmaster Tools, Microsoft SNDS) show a reputation decline, the complaint rate has risen.

The recovery for a reputation problem:

1. Confirm via the postmaster tools. Check Google Postmaster Tools and Microsoft SNDS for the reputation reading. A declining reputation score or a worsening SNDS filter result confirms a reputation problem.
2. Identify the cause of the reputation decline. Reputation degrades from rising complaints, poor list quality producing spam-trap hits and bounces, or content triggering filters. Find which.
3. Reduce volume while reputation recovers. Sending less, especially to the affected ISP, gives reputation room to recover.
4. Address the root cause. Clean the list, process complaints into suppression, fix the content issue, whatever the reputation decline traces to.
5. Recover patiently. Reputation recovers slowly. The delivery rate will return as reputation improves, over days, not minutes.

A reputation problem is a slower recovery than a throttling event, because rebuilding reputation takes time. The delivery rate drop is the visible symptom; the reputation is the disease, and the disease has to be treated for the symptom to resolve durably.

Blacklist listings

A blacklist listing causes a broad delivery drop: a sending IP is added to a blocklist, and every receiver that consults that blocklist rejects mail from that IP.

The signature of a blacklist listing: a drop that appeared suddenly, is spread across many receivers, and is concentrated on one sending IP (the listed one). The dsnDiag for the rejections may reference the blacklist or a policy block.

The recovery for a blacklist listing:

1. Confirm the listing. Check the sending IPs against the major blacklists. A blacklist check confirms which IP is listed and on which list.
2. Stop sending from the listed IP. Use pmta pause queue to take the listed IP out of rotation, or route around it, so mail is not pouring into rejections.
3. Identify why it was listed. A listing has a cause, a spam-trap hit, a complaint spike, compromised sending. Find and fix it.
4. Request delisting. Once the cause is addressed, follow the blocklist's delisting process. A delisting request that demonstrates the problem is fixed is more likely to succeed.
5. Resume gradually after delisting. When the IP is delisted, return it to rotation gradually, treating it somewhat like a re-warm.

The urgency with a blacklist listing is real: while the IP is listed, mail through it is being rejected broadly, and continuing to send through it just accumulates rejections. Pausing the listed IP and routing around it limits the damage while the delisting is pursued.

Queues stuck in backoff

A queue stuck in backoff is a specific and common cause of a slow delivery rate to one ISP.

When PowerMTA detects throttling from an ISP, it puts the queue into backoff mode, switching to a slower retry interval. This is correct behavior, PowerMTA slowing down in response to the ISP. But a queue can stay in backoff after the cause has resolved, continuing to send slowly when it could send normally.

The check: pmta show queues, looking for queues in BACKOFF status. A queue in backoff with depth, sending slowly, where the original throttling cause has been resolved, is sending slower than it needs to.

# Find queues in backoff
pmta show queues | grep BACKOFF

The recovery, once the operator has confirmed the ISP is genuinely accepting mail again:

# Exit backoff for a specific queue after confirming the cause is resolved
pmta set queue --mode=normal example.com/marketing-pool

# Or exit backoff for all queues
pmta set queue --mode=normal */*

Infrastructure and internal causes

Two broad causes of a delivery drop are not about the receiving ISPs at all: an infrastructure problem and an internal misconfiguration.

Infrastructure and DNS problems. PowerMTA needs DNS to resolve receiver MX records and network connectivity to reach receivers. A DNS resolution problem, a slow or failing resolver, or a network connectivity problem prevents PowerMTA from connecting, dropping the delivery rate broadly. The signature: deliveries failing with connection or DNS errors in the dsnDiag, across all receivers, because the problem is on the sender's side. The check: confirm DNS resolution works from the PowerMTA host, confirm outbound network connectivity to receivers on port 25. The fix is restoring the DNS or network function.

Internal throttle misconfiguration. A configuration change can accidentally lower a rate limit, throttling the sender's own output. If someone edited a domain block's max-msg-rate, or changed a VMTA's per-IP rate, or altered a pool, the delivery rate can drop because PowerMTA is now self-limiting. The signature: a drop that coincides with a configuration change, with no throttle codes from the ISPs (the ISPs are not throttling, PowerMTA is). The check: review recent configuration changes, compare the current rate limits against the intended ones. The fix is correcting the rate back to the intended value and reloading.

These two causes are worth checking specifically because they are easy to overlook, the operator is looking at the ISPs and the reputation when the problem is actually a broken resolver or an accidental config edit. When a drop is broad and the dsnDiag does not show ISP throttling, the infrastructure and internal causes move up the suspect list.

The recovery workflow

The structured workflow from a sudden delivery-rate drop to restored throughput:

Step 1: confirm the drop is real. Check queue depth and the delivery-to-deferral ratio. A lull needs no action; a real drop, accumulating queues or elevated deferrals, needs diagnosis.

Step 2: localize the drop. Query the accounting log grouped by receiving ISP and by sending IP. Determine whether the drop is concentrated at one ISP, on one IP, or spread broadly.

Step 3: read the dsnDiag. For the affected deliveries, read the diagnostic text. Throttle codes point to throttling, auth phrases to authentication, connection errors to infrastructure, blacklist references to a listing.

Step 4: match to a cause.

Localization + dsnDiag	Likely cause
One ISP, throttle codes	ISP throttling event
One ISP, persistent, reputation declining	Reputation problem at that ISP
One ISP, queue in BACKOFF	Queue stuck in backoff
Broad, one IP, blacklist reference	Blacklist listing
Broad, auth-related rejections	Authentication failure
Broad, connection/DNS errors	Infrastructure problem
Broad, coincides with a config change	Internal throttle misconfiguration

Step 5: take the recovery action. Apply the cause-appropriate recovery: reduce volume for a throttling event, address the reputation cause for a reputation problem, exit a stale backoff, pause and delist for a blacklist listing, fix authentication, restore DNS or connectivity, correct the misconfigured rate.

Step 6: monitor the recovery. Watch the delivery rate, the queue depth, and the deferral ratio recover. Some recoveries are fast (a corrected config, an exited backoff), some are slow (reputation, a delisting).

Step 7: address the root cause and harden. Whatever caused the drop, fix the underlying reason so it does not recur, and consider whether monitoring would have caught it earlier. A delivery-rate drop is exactly the kind of event that leading-indicator monitoring, on complaint rates, deferral trends, reputation, can catch before it becomes a full drop.

A sudden PowerMTA delivery-rate drop is an incident, because the causes compound and the cost of delayed mail is real. The structured response is efficient: confirm the drop is real rather than a volume lull, localize it by receiving ISP and sending IP using the accounting log, read the dsnDiag to identify the specific signal, and match the localization-plus-dsnDiag picture to a cause, a throttling event, a reputation problem, a blacklist listing, a stuck backoff, an infrastructure problem, or an internal misconfiguration. Each cause has its own recovery, from reducing volume into a throttling ISP to correcting a misconfigured rate. The diagnostic discipline that matters most is localizing before theorizing: the accounting log evidence picks the direction far more reliably than the operator's first guess. Operators who treat a sudden drop as an incident, localize it methodically, and address the root cause rather than just the symptom, restore throughput quickly and keep a minor drop from compounding into a major deliverability problem.