Identify which Exchange route rejected the message
An Exchange-related delivery failure is not automatically an SPF, DKIM or DMARC problem. A message may be stopped by recipient restrictions, relay permissions, size limits or throttling before the receiver reaches the authentication question the operator expected. Start by identifying the product, route and rejecting system. The Exchange name alone does not distinguish an on-premises server from Exchange Online or a hybrid path involving both.
This guide uses Microsoft's public Exchange Server documentation reviewed on 8 November 2026. The relevant pages label applicability to Exchange Server 2016, 2019 and Subscription Edition. That label does not establish that an older installation remains supported: the Exchange Server 2019 lifecycle page shows its extended support ending in October 2025. Record the actual edition and build before applying any procedure. No server configuration or delivery test was inspected here.
Draw a route with observable boundaries
Describe the submitting application or mailbox, its connection method, the receiving connector, any transport agent or outbound gateway, the next hop and the destination recipient. Add the identities actually used at submission and final delivery. A cloud mailbox can still receive mail through an on-premises component, while an application can bypass the organization's usual mailbox platform entirely.
For each boundary, ask which system can accept, defer or reject the message and which administrator owns that decision. Keep the route map factual rather than filling gaps with assumed product defaults. If a remote relay returns the rejection, changing an unrelated local mailbox setting may have no effect. Microsoft 365 submission or direct-send instructions should not be imported into an Exchange Server diagnosis without proving that the route uses that service.
Read the diagnostic as evidence from a particular hop
Preserve the full non-delivery report in an approved location, then extract the generating server, rejecting server where present, affected recipient, time, enhanced status code and explanatory text. Microsoft's NDR guide distinguishes user-facing information from administrator diagnostics. The server that generates the report need not be the system that rejected the original message.
Do not interpret a short code without its context. A broad authorization failure can refer to relay access or recipient acceptance rather than domain authentication. If several recipients fail, retain their individual responses instead of assigning one cause to the entire submission. Protect addresses, message content and internal hostnames when preparing an external escalation; redaction must not erase the diagnostic needed to locate the rejecting boundary.
Separate recipient acceptance from domain authentication
Microsoft's delivery-restriction documentation describes allow and reject lists and a setting requiring authenticated senders. In that configuration context, external anonymous senders can be excluded. Passing DKIM is not the same as satisfying Exchange's authenticated-sender requirement. A valid signature therefore does not override a recipient permission decision.
The proposed investigation is to have the authorized administrator inspect the relevant recipient settings and compare them with the intended business access. Do not automatically remove an internal-only restriction to restore a single external message. It may be deliberate. An exception needs the recipient owner's decision, the exact affected population and a security review of the resulting access. This article neither reads nor changes those settings.
Locate the effective size and recipient controls
The message-size guide describes limits at organization, connector, server and mailbox levels. A mailbox's displayed allowance is not a complete route-wide entitlement. Determine which controls apply to the message and whether an upstream or downstream service imposes another restriction. Defaults in documentation are not proof of the configured value in a particular installation.
Message size also differs from attachment size. MIME encoding, headers and processing can increase what traverses the route; Microsoft notes roughly one-third expansion from Base64 encoding. For a proposed test, record the serialized message size as well as the attachment's original size. Recipient-count and header-size controls are separate dimensions. Avoid weakening several limits at once because that makes the cause harder to establish and enlarges the change scope.
Distinguish throttling from permanent rejection
Microsoft's throttling guidance describes controls over message processing, connection rates and session timeouts. Those controls protect server capacity and are not removed by publishing an authentication record. A queue delay needs investigation of the relevant rate, backlog and transport condition, not a speculative DNS edit.
Treat any diagnostic-driven retry as part of the approved mail system's behavior. Do not repeatedly submit test messages to see whether a limit eventually clears. If a change is justified, specify the exact control, affected route, expected effect and rollback condition. A route can encounter both a transport restriction and an authentication defect; correcting one does not establish that the other is absent.
Require a controlled message before declaring the route fixed
A proposed validation should compare the approved route with the diagnostic that prompted investigation, using an authorized recipient and harmless content. Record the submission result, relevant hop evidence and final receiver outcome where available. If authentication is in scope, inspect the message after the complete route because a later gateway can alter or replace a signature. One successful message supports that observed case, not every recipient, size or traffic level.
The commissioning condition remains open: Check the current provider-owned instructions and test the specific route. The general product setup guide is the parent; avoid duplicating its basics. Required original evidence is: A route-to-requirement map with current provider evidence and a controlled test message. The map below is a proposed diagnostic framework, not an observed customer route. No message was sent, no DNS answer collected and no permission or limit changed. Technical review and owner authorization must precede an operational remedy.