Exchange mail flow guides › Authentication and SMTP errors

Exchange SMTP error codes explained: 421 4.4.1, 421 4.4.2, 451 4.7.0, 452 4.3.1, 530 5.7.1, 550 5.7.1 and more

Exchange answers every SMTP submission with a three-digit reply code and an enhanced status code; 4.x.x means try again later and 5.x.x means the message was rejected, and the text after the code tells you which Exchange limit, permission or resource caused it. This page lists the replies a connector sees when it hands mail to an on-premises Exchange Server — a POP3/IMAP connector delivering into Exchange, or a relay taking Exchange’s outbound mail — with the usual cause, the fix, and the knowledge base article that has the commands and screenshots.

Updated on 2026-09-26

How to read an Exchange SMTP reply

A reply such as 550 5.7.1 Unable to relay has three parts. The reply code (550) is the classic SMTP status; the enhanced status code (5.7.1) is defined in RFC 3463 and, as Microsoft describes it for Exchange Server 2016, 2019 and Subscription Edition (DSNs and NDRs in Exchange Server), reads class.subject.detail: class 4 indicates a temporary delivery error and class 5 a permanent one; the subject groups the cause. The text after the code is what you search for — it names the limit or permission that fired.

Subject digit	Category (per RFC 3463, as listed by Microsoft)	Codes on this page
x.3.x	Mail system (the destination mail system)	452 4.3.1, 552 5.3.4
x.4.x	Network and routing	421 4.4.1, 421 4.4.2
x.5.x	Mail delivery protocol	503 5.5.2, 550 5.5.1, 554 5.5.2
x.7.x	Security or policy	451 4.7.0, 454 5.7.3, 504 5.7.4, 530 5.7.0, 530 5.7.1, 550 5.7.1

Two things follow from the class. A 4xx reply is not a rejection: the connector keeps the message and tries again on the next cycle, so a 4xx that repeats for hours is a configuration problem, not a transient one. A 5xx reply is final for that attempt; POPcon moves the message into its BADMAIL folder, and after the fix the message is retried from there (see the last question below). Where the code shows up is the connector’s log — for POPcon the file POPconSrv.log in the program directory.

Temporary errors (4xx): Exchange wants you to try again

Reply	What it means	Typical cause when a connector submits mail	Fix	Article
421 4.4.1 Connection timed out	Exchange closed the SMTP connection before the submission finished	Very large messages or a slow network between the connector and Exchange	Raise the timeout on the receive connector: Set-ReceiveConnector -id "*default*" -ConnectionTimeout 01:00:00, then restart the Microsoft Exchange Transport service	421 4.4.1 Connection timed out
421 4.4.2 Message submission rate for this client has exceeded the configured limit	The receive connector’s MessageRateLimit — the maximum number of messages per minute from a single source — was reached; Microsoft’s default on the Default Frontend connector is unlimited (Message rate limits and throttling)	The limit was set too low for the volume the connector submits in one pass, for example after a best-practice tool changed it	List the connectors and their limits with Get-ReceiveConnector | ft name,messageratelimit, then raise the active one: Set-ReceiveConnector -identity Default* -MessageRateLimit 200	421 4.4.2 Message submission rate exceeded
451 4.7.0 Temporary server error. Please try again later. PRX	Exchange 2013 turns the session away for now; the article names two common causes	Two receive connectors in conflict, or TLS, DNS or network trouble on the Exchange server	Remove duplicate connectors and make sure the Default Frontend connector permits anonymous users; do not require TLS (the connector uses plain SMTP); disable unused network adapters, use IPv4 only, check DNS and the clock (NTP)	451 4.7.0 Temporary server error PRX
452 4.3.1 Insufficient system resources	Exchange has paused mail acceptance because a monitored resource is short — Microsoft calls the mechanism back pressure (Understanding back pressure): under high pressure the transport service rejects all new incoming MAIL FROM commands	Free disk space on the Exchange server has run low; the knowledge base article names 4 GB as the point at which the older versions stop accepting mail	Free disk space (logs, temp files), or restart if memory was the resource; then move the .msg files from BADMAIL to PICKUP so the connector delivers them again	452 4.3.1 Insufficient system resources

Permanent errors (5xx): Exchange rejected the message

Reply	What it means	Typical cause when a connector submits mail	Fix	Article
454 5.7.3 Client does not have permission to submit mail — or the connection is simply closed	Something between the connector and the Exchange transport refused the session	On Exchange 2007 the Windows SMTP service holding port 25, or the antispam agents; on Exchange 2003 sender, recipient or intelligent message filtering; anywhere, a firewall or antivirus product cutting the TCP connection	Stop and disable the Windows SMTP service; add the connector’s IP address to the antispam IP Allow List; switch off the Exchange 2003 filters; configure security products to drop mail silently instead of closing the connection	Connection unexpectedly closed / 454 5.7.3
503 5.5.2 need Rcpt command	Exchange refused every recipient of the message, so the DATA command arrived without an accepted RCPT	Recipient filtering is on, the domain is not an accepted domain, or the address does not exist in Active Directory	Check Accepted Domains and the users’ addresses in Active Directory; on Exchange 2003 disable recipient filtering under Global Settings › Message Delivery	550 5.5.1 user unknown / 503 5.5.2 need Rcpt
504 5.7.4 Unrecognized authentication type	Not from your Exchange: the Office 365 SMTP servers answer this when a relay talks to smtp.office365.com without the TLS mode they expect	MultiSendcon’s SMTP account for smtp.office365.com is set to plain SSL; Office 365 requires STARTTLS (explicit TLS on port 587), implicit SSL on 465 is not supported for outbound relay	Set the account’s SSL option to Explicit SSL/TLS (available since MultiSendcon 2.10)	504 5.7.4 Unrecognized authentication type
530 5.7.0 Must issue a STARTTLS command first	The receive connector requires TLS before it accepts SMTP commands	TLS is enforced on the connector; the POP3/IMAP connector delivers over plain SMTP without STARTTLS	On the Default Frontend connector’s Security tab allow anonymous users and make sure TLS is offered, not required	530 5.7.0 Must issue a STARTTLS command first
530 5.7.1 Client was not authenticated	The receive connector accepts only authenticated sessions	“Anonymous users” is not ticked in the connector’s permission groups — on Exchange 2007 and 2010 the receive connector accepts only authenticated sessions by default	Open the Default (or Default Frontend) receive connector, tick Anonymous users under Permission Groups; do not work around it with SMTP authentication	530 5.7.1 Client was not authenticated
530 SMTP authentication is required	Not from Exchange at all: another mail server (typically hMailServer) is listening on port 25 of the address the connector delivers to	A second SMTP server on the same machine as the connector answers before Exchange does	Remove the other server, or move it to another port and set the connector’s Exchange delivery port to match (EXCHANGE tab in POPcon)	530 SMTP authentication is required
550 5.5.1 user unknown	Exchange has no recipient with that address	The address is missing in Active Directory, the domain is not accepted, or a distribution group refuses external senders	Assign the address in Active Directory; for a group run Set-DistributionGroup GROUPNAME -RequireSenderAuthenticationEnabled $False; on Exchange 2003 disable recipient filtering	550 5.5.1 user unknown / 503 5.5.2 need Rcpt
550 5.7.1 Unable to relay	Exchange does not own the recipient domain and will not forward mail for it	Your internet domain is not in the list of accepted domains	Add the domain under Mail Flow › Accepted Domains as an Authoritative Domain; on Exchange 2003 add it to the Default Policy under Recipient Policies	550 5.7.1 Unable to relay
552 5.3.4 Header size exceeds fixed maximum size	The message header is larger than the receive connector allows	Mail from mailing lists, long forwarding chains or automated systems with very long headers	Set-ReceiveConnector -identity Default* -MaxHeaderSize 256kb, then move the affected messages from BADMAIL to PICKUP	552 5.3.4 Header size exceeds fixed maximum size
554 5.5.2 No valid recipients	Exchange found no deliverable recipient for the message	Exchange 2000/2003: the internet domain is missing from the Default Policy, the connector’s machine has no relay rights on the virtual SMTP server, or the addresses are not assigned	Add the domain to the Default Policy under Recipients › Recipient Policies, grant relay rights, check the addresses in Active Directory	554 5.5.2 No valid recipients

Three settings behind most of these replies

Read across the two tables and the same three Exchange settings keep coming back. They are also the three steps of the setup guide How to download POP3 and IMAP mailboxes into Exchange 2016, 2019 and SE, which is why a fresh installation tends to produce these codes in this order.

• Accepted domains. Exchange accepts SMTP mail only for domains it knows. A missing accepted domain produces 550 5.7.1 Unable to relay, and on the older versions 554 5.5.2 No valid recipients or 550 5.5.1 user unknown. The knowledge base explains why a connector needs the accepted domains.
• Anonymous users on the receive connector. The connector delivers like any internet mail server would: plain SMTP, no login, no STARTTLS. If the receive connector requires authentication you get 530 5.7.1 Client was not authenticated; if it requires TLS you get 530 5.7.0 Must issue a STARTTLS command first; if two connectors compete on Exchange 2013 you get 451 4.7.0 PRX. The configuration guide for Exchange 2013 / 2016 shows the connector settings with screenshots.
• Filtering and limits on the connector. Recipient and sender filtering (Exchange 2003) and the antispam agents (Exchange 2007) reject or drop sessions before the recipient is checked; the connector’s ConnectionTimeout, MessageRateLimit and MaxHeaderSize produce 421 4.4.1, 421 4.4.2 and 552 5.3.4. All three limits are changed with Set-ReceiveConnector in the Exchange Management Shell.

Two replies in the tables do not come from your Exchange at all: 530 SMTP authentication is required is another SMTP server answering on port 25 of the connector’s machine, and 504 5.7.4 Unrecognized authentication type is the Office 365 side answering a relay such as MultiSendcon. In both cases changing Exchange changes nothing.

Receive connector parameters that appear in the fixes

Parameter	Reply it produces when too low	Command from the knowledge base	Afterwards
ConnectionTimeout	421 4.4.1 Connection timed out	Set-ReceiveConnector -id "*default*" -ConnectionTimeout 01:00:00	Restart the Microsoft Exchange Transport service
MessageRateLimit	421 4.4.2 Message submission rate exceeded	Set-ReceiveConnector -identity Default* -MessageRateLimit 200	Confirm with Get-ReceiveConnector | ft name,messageratelimit
MaxHeaderSize	552 5.3.4 Header size exceeds fixed maximum size	Set-ReceiveConnector -identity Default* -MaxHeaderSize 256kb	Move the rejected messages from BADMAIL to PICKUP

Default* matches the connector named Default <ServerName>; if the connector that accepts the sessions is a different one — the Default Frontend connector on Exchange 2013 and later, or an SBS fax connector — apply the command to that connector, or to each connector listed by Get-ReceiveConnector.

Frequently asked questions

More in the Exchange mail flow guides, on the POPcon and MultiSendcon product pages, the POPcon download page or in the knowledge base. Auf Deutsch: Exchange-SMTP-Fehlercodes erklärt.