> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Exchange On-Prem Mail Flow

> Diagnose on-prem Exchange transport — stuck queues, send/receive connector faults, TLS/cert failures, backpressure — using Queue Viewer and protocol logs.

<Info>
  **Category:** Troubleshooting Playbooks · [View source ↗](https://github.com/Thread-Magic/super-magic-skills/blob/main/skills/troubleshooting-playbooks/exchange-onprem-mailflow/SKILL.md)
</Info>

**Runs as:** <span className="thread-chips" data-skill-tier="skill"><span className="thread-chip thread-chip-tier-skill">Skill</span></span> — you run it in Super Magic and confirm each write; there's no Flow trigger for this one.

**Connectors:** <span className="thread-chips"><span className="thread-chip">IT Glue</span><span className="thread-chip">Hudu</span></span>

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response

**When to use:** Mail is queuing on-prem and not delivering (internally or externally); a send/receive connector broke after a change or a "smart host"/relay stopped working; TLS/certificate errors appear in mail flow or a partner stopped accepting mail; or the transport service stopped, backpressure warnings fired, or the Exchange disk filled up.

**Run it:** on the one ticket you're working — a tech drives the queue viewer and shell hands-on; not unattended.

## Prompt

```
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.
```


## Related topics

- [Liongard Exchange On-Prem Read](/skill-library/liongard-inspectors/liongard-exchange-on-prem.md)
- [Exchange Hybrid Issues](/skill-library/troubleshooting-playbooks/exchange-hybrid-issues.md)
- [Mailbox Migration Prep](/skill-library/m365-administration/mailbox-migration-prep.md)