Exchange 2010 - Non Delivery Reports - Reporting-MTA isn't the same as Received-From-MTA

Getting NDR's from a few recipients on email we send out.  A typical one would be: gave this error:
#5.1.0 Address rejected.
A problem occurred during the delivery of this message to this e-mail address. Try sending this message again. If the problem continues, please contact your helpdesk.
Diagnostic information for administrators:
Generating server: #550 #5.1.0 Address rejected. ##
Original message headers:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;
      s=DKIM; t=1358985252; h=From:Subject:Date:Message-ID:To:MIME-Version
      :Content-Type; bh=bxLfClczBDqfj1WjiV8pyOb4F9MqPeIvR9J9jqPL6LU=; b=nju2opf
Received: from ([fe80::3802:b8c6:bcc:c647]) by ([fe80::3802:b8c6:bcc:c647%11]) with mapi id
 14.01.0438.000; Wed, 23 Jan 2013 18:54:12 -0500
Reporting-MTA: dns;
Received-From-MTA: dns;
Arrival-Date: Wed, 23 Jan 2013 23:54:12 +0000

Final-Recipient: rfc822;
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp;550 #5.1.0 Address rejected.
Remote-MTA: dns;
X-Display-Name: Some One

Both the "Generating Server" and the "Reporting-MTA" show which is the INTERNAL local domain name of the Exchange 2010 server.  The "Received-From-MTA" is which is our external domain name and where we have all our DNS SPF and DKIM, MX, A records setup.   I thinking that some receiving email servers are doing rDNS and getting tripped up on the internal domain name.    How can I setup Exchange 2010 to only use the External domain name which would be is registered as an external domain as well when we needed to get an SSL certificate that would would work with for some internal uses.   But I don't have any DNS pointing related to setup in it and would like to not have to duplicate the DKIM stuff there as well.   A, MX, SPF records could be setup in external DNS, but the DIM might be a little tricker.

I think that all of this could be resolved if outbound email from us showed rather than   The Send connector does have listed as the FQDN, but we are running all Exchange 2010 roles on one server and I've seen indications that the FQDN is ignored in that case.

Anyone have a way to get converted to in all our outbound email headers?
Who is Participating?
Simon Butler (Sembee)Connect With a Mentor ConsultantCommented:
The external provider will have all of the reporting channels that the major email providers require setup.

This is the AOL one for example:

Most of the providers will have these (Hotmail, Yahoo etc) and by having those you have a higher chance of email delivery. They can also give you reporting etc.

Simon Butler (Sembee)ConsultantCommented:
Don't get hung up on the FQDN on the NDR. There are only three FQDN's that you need to worry about:
1. Send Connector
2. MX record
3. PTR

Ideally all three should be the same.

If you have set the Send Connector correctly, then problem is most likely elsewhere. What is in the headers doesn't matter, and you cannot really (and nor should you try to) change that behaviour.

Remote servers are only interested in the address the email is coming from, they don't care what has happened before that.

pwashburn1224Author Commented:
Looking at the MX record for
Non-authoritative answer:     MX preference = 10, mail exchanger = is our spam filtering service on incoming email to us.

Looking at the PTR record:
PTR Record Found! resolves to

So they are not the same.    How do I handle the situation then where I want all incoming email to go to the MX record location, but all outbound email is coming from    It's just the MX record that is problem.
Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

Simon Butler (Sembee)ConsultantCommented:
If your MX record is pointing somewhere else, then that is fine.
You just need to ensure that the PTR has a matching A record that resolves to the correct place.

So resolves to and the PTR on is

The other option is to send email OUT via the spam filtering service. A lot of them prefer that as they learn what email you are sending.

pwashburn1224Author Commented:
Looks like the SMTP banner that my Exchange server was putting out on Port 25 might have been the problem.  Was showing the server name in the local domain instead of  

Went into the Exchange Management Shell and used this command to change it:

Set-ReceiveConnector –identity “ServerConnectorname” –Banner “220 banner text”

Now it answers telnet 25 appropriately with:
220 Service ready

That should help.
Simon Butler (Sembee)ConsultantCommented:
Sorry, no that doesn't help.
That is the RECEIVE Connector, and is only involved in receiving INBOUND email. Has nothing to do with OUTBOUND email. Basically what I wrote in my first posting.

All that changing the receive connector does is pass the dumb tests on things like MX Toolbox.

pwashburn1224Author Commented:
Okay, then how does the SMTP banner check work when a mail server tries to check the validity of our email then?

The email goes out from our server as from    The public IP address is included as the originating IP.  Doing NSLookup on that address resolves to   The PTR record matches as well.  So validating with reverse DNS should work and be happy.   SPF records and DKIM signing are available for further validation and appear to be working.    

If the receiving email server tries to do a SMTP Banner check, it is my understanding that it tries a port 25 connection to our sever.  Doing that before my changed resulted in the internal domain name of the server being shown, not the public name of     Changing the receive connector took care of that problem.  Having the remote server trying to verify our banner would involve it opening a connection to our server and seeing the banner that is displayed.   That would seem like a "Receive Connection" to our Exchange server wouldn't it?

Now, if the receiving email server tried to do its validation by looking at the MX records for us, then that's a completely different creature as the MX records point to our spam filtering provider, not us.   And that is where if you want to send us mail, that's where you should send it.   But outbound email from us come directly from our Exchange server.    Certainly that would be a common situation these days, so I would think any validation by a receiving email server from email we send out would handle that.  

We use Exchange distribution lists extensively and the NDR's I get do seem to occur more often on those rather than on email between individual users.   We do lots of outbound email to these distribution lists.   I've just run our Exchange public IP address against the RBL and we aren't listed so that isn't the issue.
Simon Butler (Sembee)ConsultantCommented:
The SMTP banner check is a complete waste of time. I ignore the results of that because the remote testing sites are unable to see how your server is announcing itself when sending email unless an email is delivered to their server.

I am not aware of anyone doing a remote banner check independant of how the server announces itself.

The communication would be

Your server connects to remote server.
The remote server says "I am"
Your server says I am ""
The remote server does a lookup on your PTR (IP address) and DNS and effectively says "Yes you are" and allows you to send your email.

Distribution lists will trip more filters simply because you are sending to multiple recipients. If youa re sending to lots of external recipients (so you have Contacts) you might want to consider outsourcing the delivery of that email to an external provider, which will be more relaible and allow you to get reports etc on the email delivery.

pwashburn1224Author Commented:
Yup, lots of Contacts.   What extra things does an external provider have that gets things through more reliably?
pwashburn1224Author Commented:
Thanks Simon.   I'll look through the feedback loop process at the major providers.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.