Exchange mail flow guides › Authentication and SMTP errors

NDRs for external senders behind a POP3 connector: unknown users, oversized mail, and providers that block empty senders

When mail is collected from a provider mailbox, the provider has already accepted the message, so an external sender learns about an unknown recipient or a size rejection only if Exchange accepts the message from the connector and then generates a non-delivery report (NDR) — and if your outbound relay lets the empty MAIL FROM of that report through. A refusal during the SMTP session between the connector and Exchange reaches the connector and nobody else. A POP3/IMAP connector such as POPcon does not generate non-delivery reports itself.

Updated on 2026-10-03

The Exchange behaviour on this page is taken from Microsoft Learn, where it is documented for Exchange Server 2016, 2019 and Subscription Edition; the connector side is taken from the POPcon and MultiSendcon knowledge base, whose articles on this subject were written for Exchange 2003 to 2013. Where the two differ, both are named.

Why a non-delivery report is different behind a connector

When a mail server on the internet delivers directly to Exchange, a refusal in the SMTP session goes back to the sending server, and that server informs its user. Behind a connector the sending server finished its work when the provider took the message. What happens afterwards is between three parties: the connector, which logs in to the provider mailbox and submits each message to Exchange over SMTP; Exchange, which either refuses the message in that session or accepts it; and the route by which Exchange sends its own mail out. A report for the original sender exists only if Exchange creates one, and it arrives only if that outbound route carries it.

Microsoft describes the report itself in DSNs and NDRs in Exchange Server: “When there’s a problem delivering a message, Exchange sends an NDR to the message sender that indicates there was a problem.” For a recipient that does not exist the enhanced status code is 5.1.1, “RESOLVER.ADR.ExRecipNotFound; not found” or “User unknown”.

The three cases

Case	If Exchange refuses in the SMTP session	If Exchange accepts the message	What the sender hears by default
Recipient does not exist	The message stays in POPcon’s queue (knowledge base) — unless POPcon re-routes unknown recipients to the postmaster, in which case it is delivered there	Exchange generates the non-delivery report, status 5.1.1	Nothing in the first two variants; the report in the third
Message is too large	Refused at the receive connector; POPcon moves it to its TOOLARGE folder	Refused by the organizational or mailbox limit; Exchange sends the non-delivery report	Nothing while the message waits in TOOLARGE; the report otherwise
Recipient is out of office	Does not apply: the message is delivered	Exchange sends the automatic reply if the remote domain settings allow it	The reply, if it is allowed and the outbound relay accepts it

Unknown recipients: postmaster, queue or report

This is the case with the most variants, because both the connector and Exchange have a setting for it.

On the connector. POPcon version 3.00 and later has the option “Re-route email to unknown recipients” in the POP3/IMAP account configuration. When it is enabled, mail addressed to users who are not found in Exchange or Active Directory is redirected to the postmaster address set on the General configuration tab (knowledge base). The message reaches a person who can forward it; the sender is not told. How a connector finds the recipients of mail from a catch-all mailbox in the first place is described in Catch-all mailbox or one POP3 mailbox per user.

In Exchange. If the option is off, POPcon submits the message to the address it was sent to, and Exchange decides. Microsoft’s description of accepted domains says an authoritative domain is one for which the Exchange organization “accepts messages that are addressed to recipients in these domains, and is responsible for generating non-delivery reports (also known as NDRs or bounce messages) for non-existent recipients” (Accepted domains in Exchange Server). Whether Exchange gets that far depends on recipient filtering. When the Recipient Filter agent is set to validate recipients, a message for a recipient that is not found is answered in the SMTP session: “the Exchange server sends a 550 5.1.1 User unknown SMTP session error to the sending server” (Recipient filtering on Edge Transport servers). Behind a connector the “sending server” is the connector, and the message stays in its queue.

The knowledge base article How to have non-delivery reports sent for unknown users therefore gives two steps: disable “Re-route email to unknown recipients” in POPcon, and disable the blocking of unknown recipients in Exchange so that the message is accepted and answered with a report. It names the places for the older versions:

• Exchange 2007 and 2010: Exchange Management Console › Organization Configuration › Hub Transport › Anti-Spam › Recipient Filtering: uncheck “Block messages sent to recipients that do not exist”.
• Exchange 2003: Exchange System Manager › Global Settings › Message Delivery › Recipient Filtering: uncheck “Filter recipients who are not in the Directory”. In addition, “Allow non-delivery reports” must be checked under Global Settings › Internet Message Formats (article with screenshots).

Exchange 2016, 2019 and SE. On these versions recipient filtering is managed in the Exchange Management Shell only, and Microsoft’s documentation points the other way from the older defaults. The parameter that makes the agent block “messages addressed to recipients that don’t exist in the organization” is RecipientValidationEnabled on Set-RecipientFilterConfig, and “the default setting is $false”. For Mailbox servers Microsoft adds a warning: “Although the Recipient Filter agent is available on Mailbox servers, you shouldn’t configure it. When recipient filtering on a Mailbox server detects one invalid or blocked recipient in a message that contains other valid recipients, the message is rejected.” The agent is enabled when the antispam agents are installed on a Mailbox server, “but it isn’t configured to block any recipients” (Recipient filtering procedures). On a server where nobody changed this, Exchange accepts the message and the non-delivery report follows. On a server that was migrated or hardened over the years, read the state before assuming it:

• Get-RecipientFilterConfig | Format-List Enabled,RecipientValidationEnabled shows whether the filter is on and whether it blocks recipients that do not exist (Microsoft’s own check is the same command with Enabled alone).
• Get-AcceptedDomain | Format-List Name,AddressBookEnabled shows the setting per accepted domain: “By default, recipient filtering is enabled for authoritative domains, and disabled for internal relay domains and external relay domains.”
• Set-RecipientFilterConfig -RecipientValidationEnabled $false switches the blocking of non-existent recipients off again.

Microsoft’s warning about Mailbox servers has a practical side behind a connector: a message collected from a provider mailbox can carry several recipients of your domain, and one mistyped address among them should not cost the others their copy.

Oversized messages

The same split applies to size. A message that the receive connector refuses stays with POPcon in the TOOLARGE folder, and the sender hears nothing. To have the sender told, the knowledge base (How to have NDRs sent for emails that are too large) moves the decision behind the receive connector: set the connector’s limit high so that it does not refuse the message “at the wrong level”, and set the organizational maximum receive size to the limit you want. Exchange then accepts the message from the connector, finds it too large and sends the report itself. The limits, Microsoft’s default values and the commands are in Messages over 10 MB are not arriving.

Out-of-office replies

An automatic reply is not a non-delivery report, but it is the third message Exchange sends to external senders on its own, and it takes the same route. The knowledge base is clear about responsibility: this “is not a POPcon issue — it is an Exchange configuration setting” (article). For Exchange 2003 the switch is “Allow out of office responses” on the Advanced tab of the default entry under Global Settings › Internet Message Formats.

On later versions the setting belongs to the remote domain and is changed with Set-RemoteDomain. Microsoft’s cmdlet reference lists three parameters that matter here:

Parameter	What it controls	Default per Microsoft
AllowedOOFType	“the type of automatic replies or out-of-office (also known as OOF) notifications than can be sent to recipients in the remote domain”; valid values are External, ExternalLegacy, InternalLegacy and None	External: “Only automatic replies that are designated as external are sent”
AutoReplyEnabled	“automatic replies from client email programs in your organization (for example, automatic reply messages that are generated by rules in Outlook)”	$false “for the built-in remote domain named Default in on-premises Exchange”
NDREnabled	“whether to allow non-delivery reports (also known NDRs or bounce messages) from your organization to recipients in the remote domain”	$true

Read the current values with Get-RemoteDomain | Format-List Name,DomainName,AllowedOOFType,AutoReplyEnabled,NDREnabled. If a user’s external reply is configured in Outlook and still does not go out, either AllowedOOFType was set to None or InternalLegacy at some point, or the reply is generated and stopped on the way out — the next section.

The way back: the empty sender and the outbound relay

Non-delivery reports and automatic replies have one property in common: Exchange sends them with an empty envelope sender, an empty MAIL FROM, as the SMTP standard requires. They leave through the same send connector and the same smart host as every other message. If that smart host is a provider mailbox, the provider’s rules for senders apply to them too.

IONOS is the documented case. Since January 2024 its outgoing mail servers refuse a message whose sender is not in the domain of the login mailbox, and a message with no sender at all, with Sender address is not allowed; IONOS describes the change on its help page (German). The effect on Exchange is in our knowledge base (IONOS blocks non-delivery reports and out-of-office messages): the reports and replies are generated and then blocked by the provider, and “the behaviour is not configurable in Exchange or POPcon”.

The fix is on the relay side. MultiSendcon, placed as an outgoing relay between Exchange and the provider, fills in a sender address for such messages: the address named in the message header where there is one, otherwise a fixed address configured for the account. The provider then accepts them. For a single provider login the lower-priced LITE edition is sufficient. The background, and the setup for several domains behind one provider, are in Using IONOS, Strato or GMX as the smart host for Exchange.

A relay in the outbound path has its own setting for reports. MultiSendcon’s NDR Handling tab configures how non-delivery reports from the relay servers are handled and who receives them: back to the original sender, a designated postmaster address, or both.

Postmaster or report: choosing per case

Arrangement	What happens to the message	Who knows	Settings
Re-route unknown recipients to the postmaster	Delivered to the postmaster mailbox	The postmaster; the sender is not told	POPcon: “Re-route email to unknown recipients” on, postmaster address set
Non-delivery report for unknown recipients	Accepted by Exchange and not delivered	The sender, by the report	POPcon: re-routing off. Exchange: no blocking of non-existent recipients; NDREnabled true; outbound relay accepts the empty sender
Report for the sender and a copy for the administrator	As above	Both	As above, plus Microsoft’s Set-TransportConfig -GenerateCopyOfDSNFor with the status codes to monitor and a mailbox assigned to the Exchange recipient (Procedures for DSNs and NDRs)
Oversized mail kept for the administrator	Waits in TOOLARGE as a .msg file	Whoever looks into the folder or the log	Receive connector limit not higher than the organizational limit
Oversized mail returned to the sender	Rejected by Exchange after acceptance	The sender, by the report	Receive connector limit high, organizational limit at the wanted size

The third row needs one remark from Microsoft’s page: “by default, no mailbox is assigned to the Exchange recipient, so any messages that are sent to the Exchange recipient are discarded.” Without that mailbox the copies go nowhere.

When the sender hears nothing: where to look

What you see	Cause	Where it is described
Mail for mistyped addresses arrives in the postmaster mailbox	POPcon re-routes unknown recipients	Knowledge base
Mail for unknown addresses stays in POPcon’s queue	Exchange refuses the recipient in the SMTP session	Knowledge base, options A and B
Large messages collect in TOOLARGE	Receive connector size limit	Size limits guide
Exchange generates reports and automatic replies, external senders never receive them, the provider answers Sender address is not allowed	The provider refuses the empty sender	Provider smart host guide
Out-of-office replies reach internal users only	Remote domain settings	Section above; knowledge base

The reply Exchange gave to the connector is in POPcon’s log, the file POPconSrv.log in the program directory; the codes are listed in the table of Exchange SMTP error codes.

Frequently asked questions

More in the Exchange mail flow guides, on the POPcon and MultiSendcon product pages, the POPcon download page and the MultiSendcon download page, or in the knowledge base. Auf Deutsch: Unzustellbarkeitsberichte hinter einem POP3-Connector.