Contents
Why a single-ISP deferral problem is informative
When an operator sees a high deferral rate to one specific ISP, while mail to every other receiver flows normally, that very pattern, the isolation to a single receiver, is one of the most useful diagnostic signals available. It immediately narrows the problem from the whole sending operation down to the sender's relationship with one ISP.
This guide exists to turn that narrowing into a full diagnosis and recovery. The structure of this guide: why a single-ISP deferral problem is informative, the isolation as the central clue, the per-ISP nature of email reputation, reading the deferral diagnostic text in the PowerMTA accounting log, the four cause categories a single-ISP deferral problem falls into, the correct response, and the structured recovery workflow. The thread throughout is that a deferral problem confined to one ISP is, almost always, about the sender's standing with that one ISP, and the diagnosis follows from reading what that ISP is saying.
The isolation is the clue
The first and most important observation about a high deferral rate to one ISP is the isolation itself.
| Pattern | Points to |
|---|---|
| Deferrals high at all receivers | A broad, sender-side cause |
| Deferrals high at one ISP only | The sender's relationship with that ISP |
A broad deferral problem, one affecting delivery to all receivers, points to a sender-side cause that affects all the sender's mail: an authentication failure, an infrastructure problem, a blacklist listing on a widely-consulted list, an internal misconfiguration. The problem is general because the cause is general.
A deferral problem confined to one ISP, with delivery to everyone else healthy, points to something specific to that ISP. It cannot be a broad sender-side cause, because a broad cause would affect the other receivers too. It is something in the sender's relationship with that one ISP: the sender's reputation at that receiver, a throttling event from that receiver, a volume or sending-pattern issue that specific ISP is reacting to.
This is why confirming the isolation is the first diagnostic step. Before diagnosing a single-ISP deferral problem, the operator confirms it really is single-ISP, by checking the deferral rate across receivers in the accounting log. If the deferrals are genuinely concentrated at one ISP, the diagnosis is scoped to that ISP, and the broad causes can be set aside. The isolation does a large part of the diagnostic work just by being observed.
Reputation is per-ISP
The reason a single-ISP deferral problem is so often a reputation matter is that email reputation is largely per-ISP.
Each major receiver, Gmail, Yahoo, Microsoft, maintains its own independent assessment of a sender. They do not share a single reputation score. A sender's standing at Gmail is Gmail's own evaluation, based on how that sender's mail performs with Gmail users, the engagement, the complaints, the spam-folder placement, all as Gmail sees it. Microsoft's assessment is separate, based on what Microsoft sees, informed by SNDS.
The consequence: a sender can have good standing at one ISP and poor standing at another, simultaneously. Good reputation at Gmail, poor at Microsoft, is an entirely possible and not uncommon situation, because the two evaluate independently and the sender's mail may perform differently with each ISP's users.
So a high deferral rate at one specific ISP is, very frequently, that one ISP's reputation assessment of the sender having declined, while the other ISPs still see the sender favorably. The deferral problem is isolated because the reputation problem is isolated.
This per-ISP nature shapes the diagnosis. It means the relevant reputation question is not whether the sender's reputation is generally good, it is specifically how that one ISP sees the sender. And it means the relevant tool is that ISP's postmaster tools, Google Postmaster Tools for a Gmail problem, Microsoft SNDS for a Microsoft problem, because each tool shows the sender how that particular ISP measures them.
Reading the deferral diagnostic text
The single most informative thing in diagnosing an ISP-specific deferral problem is the deferral diagnostic text in the PowerMTA accounting log.
PowerMTA records every deferral as a transient-failure event, a t record, in the accounting log, with the SMTP code and the diagnostic text the receiving server returned. That diagnostic text is the receiver telling the sender, in the receiver's own words, why it is deferring the mail.
Querying the accounting log for the deferrals to the affected ISP and reading their diagnostic text:
SELECT
dsnStatus,
dsnDiag,
count() AS n
FROM pmta_accounting
WHERE type = 't'
AND rcptDomain = 'affected-isp.com'
AND timeLogged >= now() - INTERVAL 12 HOUR
GROUP BY dsnStatus, dsnDiag
ORDER BY n DESC;The diagnostic text frequently states the reason directly. It may reference a reputation concern, a rate limit, an unusual volume of mail, an authentication issue, or a policy. The reason that recurs across the deferrals points at the cause category.
Alongside the diagnostic text, the affected ISP's postmaster tools complete the picture. For a Gmail deferral problem, Google Postmaster Tools shows the sender's domain and IP reputation, the spam rate, the authentication results, as Gmail measures them. For a Microsoft problem, SNDS shows the IP's filter result, the complaint rate, the trap data. Checking the affected ISP's postmaster tools confirms a reputation cause and shows its severity.
The combination, the deferral diagnostic text plus the ISP's own postmaster tools, turns a vague high deferral rate into a specific diagnosis. The diagnosis must come from this evidence, not from assumption, because the cause categories need different responses.
The four cause categories
A high deferral rate to one specific ISP falls into one of four cause categories.
| Cause | Signature | Direction of fix |
|---|---|---|
| Reputation decline | Diagnostic text and postmaster tools show reputation | Reputation recovery, slow |
| Volume / pattern issue | Deferrals followed a volume change to that ISP | Adjust volume and pattern |
| Authentication problem | Diagnostic text references auth | Fix SPF, DKIM, or DMARC |
| Throttling event | Throttle codes, often transient | Reduce volume, wait it out |
A reputation decline is the most common cause of a sustained single-ISP deferral problem. That ISP's assessment of the sender has dropped, and it is responding by deferring more of the sender's mail. The diagnostic text references reputation, and the ISP's postmaster tools confirm a reputation decline. The fix is reputation recovery, which is slow.
A volume or sending-pattern issue is when the deferrals began after a change in how the sender sends to that ISP, a volume spike, a new list segment, a change in sending cadence. The ISP is reacting to the changed pattern. The fix is to adjust the volume and pattern back toward what the ISP handled well.
An authentication problem can be ISP-specific if a particular ISP is stricter about authentication, or if something about the sender's authentication interacts with one ISP. The diagnostic text references SPF, DKIM, or DMARC. The fix is to correct the authentication issue.
A throttling event is a more transient version: the ISP is throttling the sender, often in response to a short-term volume or reputation signal, and the deferrals carry throttle codes. A throttling event may ease on its own once the sender reduces volume; it is less deep than a sustained reputation decline.
The diagnosis, from the diagnostic text and the postmaster tools, places the problem in one of these four. They overlap, a volume spike can cause a reputation decline, but identifying the primary cause directs the response.
The correct response
Whatever the specific cause, the immediate correct response to a high deferral rate at one ISP includes reducing volume to that ISP, and pushing through is the wrong move.
When an ISP is deferring a high rate of a sender's mail, continuing to push full volume into the deferral makes things worse. The continued pressure can be read by the receiver as further evidence of an inconsiderate sender, deepening the reputation problem, and with some receivers escalating temporary deferrals toward permanent rejections. And the deferred mail accumulates in the PowerMTA queue, and if the condition does not clear before the bounce-after limit, that mail eventually bounces. The immediate correct response is to reduce the volume to the affected ISP, easing the pressure the receiver is reacting to and signalling that the sender is responding appropriately.
The response steps:
Reduce volume to the affected ISP. Lower the max-msg-rate on that ISP's domain block. For an ISP family, ensure the queue-to family collapsing means the reduction applies to the whole family, the whole Yahoo family, the whole Microsoft family.
Let backoff operate. If PowerMTA has put the queue into backoff because of the deferrals, let the backoff work rather than overriding it.
Address the underlying cause. The volume reduction is the immediate action, not the whole fix. The diagnosed cause, the reputation decline, the volume issue, the authentication problem, must be addressed for the deferral condition to clear durably. A reputation decline needs reputation work, list quality, engagement, complaint reduction. An authentication problem needs the authentication fixed. A volume issue needs the sending pattern corrected.
Recover gradually. When the deferral condition eases, raise the rate to the affected ISP back up slowly, not in a jump, which could re-trigger the deferrals.
The response is the same shape as for any throttling or deferral situation: respect the ISP's signal by reducing volume, fix the underlying reason the ISP is unhappy, and ramp back carefully. The volume reduction must come before, not instead of, the slower root-cause work.
The recovery workflow
The structured workflow for a high deferral rate to one ISP:
Step 1: confirm the isolation. Query the accounting log for the deferral rate across receivers. Confirm the deferrals really are concentrated at one ISP, with delivery to others healthy. This confirms the problem is ISP-specific, not broad.
Step 2: read the deferral diagnostic text. Query the accounting log for the deferrals to the affected ISP and read their diagnostic text. Identify the recurring reason.
Step 3: check the ISP's postmaster tools. Look at Google Postmaster Tools for a Gmail problem, SNDS for a Microsoft problem. See how that ISP measures the sender's reputation, complaints, and authentication.
Step 4: place the cause. From the diagnostic text and the postmaster tools, identify the cause category: reputation decline, volume/pattern issue, authentication problem, or throttling event.
Step 5: reduce volume to the affected ISP. Lower the max-msg-rate on that ISP's domain block immediately, regardless of the specific cause. Let any backoff operate.
Step 6: address the cause. Apply the cause-specific fix. Reputation: the slow reputation-recovery work. Volume/pattern: correct the sending pattern. Authentication: fix the auth. Throttling event: the volume reduction may largely suffice.
Step 7: monitor the recovery. Watch the deferral rate to the affected ISP in the accounting log, and the ISP's postmaster tools, for the recovery. A throttling event may ease in days; a reputation decline recovers over weeks.
Step 8: recover volume gradually. As the deferral rate eases, raise the rate to the affected ISP back up slowly.
An operator we worked with saw their PowerMTA accounting log showing a sharply elevated deferral rate to Microsoft, the Outlook and Hotmail family, while their delivery to Gmail, Yahoo, and everyone else remained perfectly healthy. They were initially worried it was a broad problem and started checking their authentication and looking for a blacklist listing. We pointed out that the isolation itself ruled the broad causes out: an authentication failure or a blacklist listing would have affected Gmail and Yahoo too, and those were fine. The problem was specific to Microsoft. With the diagnosis scoped to Microsoft, the next step was the deferral diagnostic text. They queried the accounting log for the Microsoft deferrals and read the diagnostic text, which referenced a reputation and unsolicited-mail concern. Then they checked SNDS, Microsoft's postmaster tool, and SNDS confirmed it: the IPs sending to Microsoft had moved into a poor filter-result range, and the complaint rate SNDS reported had risen sharply. So Microsoft's reputation assessment of the sender had declined, while Gmail's and Yahoo's had not, the per-ISP nature of reputation in action. The question was why the decline was specific to Microsoft. Investigating their recent sending, they found the cause. They had recently started mailing a particular list segment that had a high proportion of Microsoft-domain addresses, hotmail.com and outlook.com addresses, and that segment was poorly sourced, with low engagement and a high complaint rate. Because the segment was so Microsoft-heavy, its poor performance hit Microsoft's reputation assessment hard while barely touching Gmail's or Yahoo's, the bad mail was disproportionately going to Microsoft. The fix had two parts. Immediately, they reduced their volume to the Microsoft family by lowering the max-msg-rate on the Microsoft domain block, easing the pressure. Then they addressed the cause: they removed the poorly-sourced segment, which was generating the complaints, and cleaned the remaining list. Over the following weeks, with reduced volume and the bad segment gone, the SNDS filter result improved, the complaint rate dropped, and the Microsoft deferral rate eased back to normal. The lesson is the central one of this guide: a high deferral rate isolated to one ISP is, almost always, about that ISP's specific reputation assessment of the sender, and the isolation plus the diagnostic text plus that ISP's postmaster tools lead straight to the cause, here a Microsoft-heavy bad list segment that dragged down Microsoft's view while leaving the other ISPs unaffected.
A high deferral rate to one specific ISP, with delivery to other receivers healthy, is a well-scoped diagnostic situation, and the isolation is the central clue: it rules out the broad sender-side causes and points to the sender's relationship with that one ISP. Because email reputation is per-ISP, each receiver evaluating the sender independently, a single-ISP deferral problem is most often that one ISP's reputation assessment having declined while the others still see the sender favorably. The diagnosis comes from reading the deferral diagnostic text in the PowerMTA accounting log, the receiver explaining in its own words why it is deferring, and from checking that ISP's postmaster tools, Google Postmaster Tools or SNDS, which place the cause as a reputation decline, a volume or pattern issue, an authentication problem, or a throttling event. The immediate correct response, whatever the cause, is to reduce volume to the affected ISP, never to push through, and then to address the underlying cause and recover gradually. Operators who confirm the isolation, read the evidence from the accounting log and the postmaster tools, and respond by easing volume and fixing the cause, recover their delivery to the affected ISP; operators who push through, or who chase broad causes the isolation already ruled out, prolong the problem.