• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1435
  • Last Modified:

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:

p3pismtp01-004.prod.phx3.secureserver.net 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: APAMAIL.APAOffice.org
p3pismtp01-004.prod.phx3.secureserver.net #550 #5.1.0 Address rejected. ##
Original message headers:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apa1224.org;
      s=DKIM; t=1358985252; h=From:Subject:Date:Message-ID:To:MIME-Version
      :Content-Type; bh=bxLfClczBDqfj1WjiV8pyOb4F9MqPeIvR9J9jqPL6LU=; b=nju2opf
Received: from APAMAIL.APAOffice.org ([fe80::3802:b8c6:bcc:c647]) by
 apamail.APAOffice.org ([fe80::3802:b8c6:bcc:c647%11]) with mapi id
 14.01.0438.000; Wed, 23 Jan 2013 18:54:12 -0500
Reporting-MTA: dns;APAMAIL.APAOffice.org
Received-From-MTA: dns;apa1224.org
Arrival-Date: Wed, 23 Jan 2013 23:54:12 +0000

Final-Recipient: rfc822;someone@adomain.com
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp;550 #5.1.0 Address rejected.
Remote-MTA: dns;p3pismtp01-004.prod.phx3.secureserver.net
X-Display-Name: Some One

Both the "Generating Server" and the "Reporting-MTA" show APAMAIL.APAOffice.org which is the INTERNAL local domain name of the Exchange 2010 server.  The "Received-From-MTA" is apa1224.org 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 APAMAIL.APAOffice.org internal domain name.    How can I setup Exchange 2010 to only use the External domain name which would be mail.apa1224.org?

APAOffice.org is registered as an external domain as well when we needed to get an SSL certificate that would would work with APAOffice.org for some internal uses.   But I don't have any DNS pointing related to APAMail.APAOffice.org 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 mail.apa1224.org rather than APAMail.APAOffice.org.   The Send connector does have mail.apa1224.org 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 APAMail.APAOffice.org converted to mail.apa1224.org in all our outbound email headers?
  • 5
  • 5
1 Solution
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 apa1224.org:
Non-authoritative answer:
apa1224.org     MX preference = 10, mail exchanger = mail.mailroute.net

mail.mailroute.net is our spam filtering service on incoming email to us.

Looking at the PTR record:
PTR Record Found! resolves to mail.apa1224.org

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 mail.apa1224.org?    It's just the MX record that is problem.
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 host.example.com resolves to and the PTR on is host.example.com.

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.

Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

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 mail.apa1224.org.  

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 mail.apa1224.org 25 appropriately with:
220 mail.apa1224.org 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  someone@apa1224.org.    The public IP address is included as the originating IP.  Doing NSLookup on that address resolves to mail.apa1224.org.   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 mail.apa1224.org.     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 mail.remote.com"
Your server says I am "mail.example.com"
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?
Simon Butler (Sembee)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.

pwashburn1224Author Commented:
Thanks Simon.   I'll look through the feedback loop process at the major providers.

Featured Post

 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now