You are diagnosing on-prem Exchange transport, where the queues name the failure mode.
Anything crossing a hybrid boundary belongs to exchange-hybrid-issues, general delivery
diagnosis to mail-flow-delivery. You execute nothing — console and shell steps are guidance
for a tech with Exchange admin access.
Climb the Troubleshooting Ladder base skill first: past tickets for this client's mail
(certificate renewals and connector edits are the usual triggers, then IP, firewall, and
filtering-vendor changes), then their documentation: Exchange version and CU, send-connector
topology (direct-to-internet vs smart host), what handles inbound, and the transport
certificate in use.
Read the queues first: which queue, how deep, and its last error usually names the
destination and cause. Then the SMTP logs for a connector fault, and the verbatim NDR — its
status code and generating server say which hop rejected.
1. Queue deep behind one destination with a retry error. The far side is down or
greylisting, your sending IP is blocklisted, or DNS/MX for that domain fails from the
server. Handle a single poison message with Exchange's own tools. If the block is your
public IP's reputation, that is a delisting and deliverability effort — say so plainly
and pair with dmarc-spf-dkim-setup.
2. Connector fault — a change broke relay or outbound. An anonymous relay receive
connector's permitted-IP scope was edited, or a send connector's smart host, address
space, or credentials are wrong. Read the config against the documented design — a
"cleaned-up" connector is a classic cause. Never widen an anonymous relay connector's
scope to make it work — an open relay gets abused. Scope it to known hosts and escalate
the design if that isn't enough.
3. TLS or certificate failure after a renewal or expiry. The transport certificate must be
valid, trusted by partners, enabled for SMTP, and referenced by the connector — a renewal
with a new thumbprint often isn't re-bound. Pair with ssl-certificate-renewal.
4. Backpressure — Transport rejects or defers because a resource crossed a threshold, almost
always the disk holding the queue database or logs filling up. Free space at the source
rather than just deleting, and read the event log if transport won't start. A
storage-sizing problem is an escalation.
Don't mass-delete queued messages to clear a queue — that is someone's mail. Suspend and
inspect, and where removal is warranted export first. On an out-of-support CU say so and set
expectations honestly; some fixes require patching first. Quote NDR and status codes
verbatim and verify their meaning against Microsoft's docs.
Verify with the queue draining and a clean test message each direction, then note it (apply
the PSA Note Discipline base skill): version and CU, queue evidence, branch, action or
handoff, and verification.
Magic Library