Exchange 2013 refusing inbound messages 571 Delivery not authorized, message refused.

Have a client with a formerly working fine Exchange 2013 server. Monday it decided to start refusing "some" mail. Nobody (to my knowledge) changed anything.


1) Mail is rejected with the "571 Delivery not authorized, message refused" message.
2) Server does accept some mail from the internet.
3) I can send original messages to them and receive messages from them, but cannot reply to a message sent to my domain. Get the above message.
4) manual smtp sessions via telnet seem to work.
5) only error I can find in the Frontend log file is sessions that fail end with a "Remote(socketerror).

I disabled the maiware processing via MS script.

any idea appreciated,
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jian An LimSolutions ArchitectCommented:
it can be anything.

start with 571 delivery not authorized. this mean your server some how relay to a smart host and it start to reject email?

you need to provide detailed information like what is the exact error (in full and sometimes mesage header helps)

mx record details also help whether there is a middle mx record incoming (or relay servers for outbound)

and how do you disable malware processing? confirm it by dropping EICAR.txt files to confirm it is not working

my gut feel is external to exchange rather than exchange itself
rogerb_txAuthor Commented:
Thanks for the response. I'll post exact error messages when I get to the office although frankly there isn't a lot of information in them and yes I do know how to read them.

It does not appear to be a relay issue. It also appears to only happen on "reply" messages. As I stated I can send original messages to the server but cannot reply to a message from the server. thought it might have had something to do with the reply address format, checked that....

There is no intermediary MX or server. The MX has one server defined in it.
I also thought it might be the malware processing and ran the MS provided script to turn it off. However, if you look at the malware settings from EAC the default rule still shows enabled. so I really don't know if it's on or not?

I don't think the problem is external to the exchange server as I can see the message go through the firewall and to the exchange server. I also watched the traffic via wireshark; the exchange server gets to a place in the smtp conversation and then sends a reset,ack. So the problem IS actively the Exchange server.


Did you check Transport rules ?
This error can also occur if an Exchange 2010 transport rule rejects a message because the message matched conditions that are configured on the transport rule.

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

rogerb_txAuthor Commented:
This is Exchange 2013. It is a new product for me. But as far as I can tell there are no transport rules. Also, this server worked fine until last Friday, it's been up two months.

thx again
rogerb_txAuthor Commented:
requested error message on reply message.

Delivery has failed to these recipients or distribution lists:

An error occurred while trying to deliver this message to the recipient's e-mail address. Microsoft Exchange will not try to redeliver this message

for you. Please try resending this message, or provide the following diagnostic text to your system administrator.

The following organization rejected your message: Requested.


Sent by Microsoft Exchange Server 2007

Diagnostic information for administrators:

Generating server: myserver.mydomain.local
Requested #571 Delivery not authorized, message refused ##

Original message headers:

Received: from myserver.mydomain.local ([fe80::4152:8bf0:2dbc:4a31]) by
 myserver.mydomain.local ([fe80::4152:8bf0:2dbc:4a31%10]) with mapi; Wed, 2 Oct
 2013 11:34:08 -0500
From: firstname lastname <>
To: firstname lastname <>
Date: Wed, 2 Oct 2013 11:34:07 -0500
Subject: RE: Email update
Thread-Topic: Email update
Thread-Index: Ac6/b+e+O7YHAh62Sgi2SX1XhoZm9AAHUrDQ
Message-ID: <28904226D092564CAE18852C96544E1B02D2C70D53F1@myserver.mydomain.local>
References: <de2cff19b8194f8b8c29245f6027c120@cserver.cdomain.local>
In-Reply-To: <de2cff19b8194f8b8c29245f6027c120@cserver.cdomain.local>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative;
MIME-Version: 1.0
rogerb_txAuthor Commented:
mx record is simply...
Please can you more elaborate "Sent by Microsoft Exchange Server 2007 " ?
Jian An LimSolutions ArchitectCommented:
i will go through your receive connectors  on exchange 2013.

and resetup internet email flow

if this helps, then we will need to dig through your admin logs to find what have changes since.
rogerb_txAuthor Commented:
Well I figured it out. I will do my best to explain the situation so if somebody else makes this mistake, hopefully it won't take them two days to fix it.

This client has several internal servers that relay mail through the Exchange 2013 server to external (internet) addresses. To make this work in Exchange 2013 you have to create a receive connector that will allow anonymous relay and you restrict the scope to the addresses you want to allow to do this. Which we did when we set this up two months ago. You had to do this in previous versions as well but this mechanism has become more complicated. I'm pretty sure I read the instructions MS provided to set this up fairly well and I don't recall any advise then to NOT create two (or more) receive connectors that bind the same IP/Port combination. We created the addition receive connector with the same IP address and port 25 as the Default Frontend connector and it worked....for two months. Now having thought about this today, that was a pretty stupid thing to do. But it worked. I have since read the documentation online regarding this again and now there is a warning to not create connectors with the same IP/Port combination. In other words, each connector must bind a unique IP/Port combination.

If you do what I did, part of the time email from the internet will connect to the connector that restricts the scope address to the internal application servers and it will reject it as not authorized because it isn't. Some of the time it will connect to the correct one and it will work.

What I can't work out is why it worked fine for two months?

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
rogerb_txAuthor Commented:
It was the solution.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.