Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1163
  • Last Modified:

Cannot send to some external recipients after SP3 upgrade of Exchange 2007 #550

After upgrading our Exchange 2007 from SP1 to SP3 we now cannot send e-mail to some external recipients.  This issue always appears to involve recipients whose mail domains are being hosted on other domains.
generating server: our.internal.mail.server.net
Most of the NDRs return #550 with various messages including:

someone@recipient.domain
some.other.domain #550 relay not permitted

someone@recipient.domain
some.other.domain #550 5.7.1 Unable to relay for someone@recipient.domain

someone@recipient.domain
some.other.domain #553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)

someone@recipient.domain
some.other.domain #550 No Such User Here
(this one was a reply to that user)

It would seem to me that the SP upgrade changed something, but I do not know what.
Incoming mail comes through a spam appliance, of which we have a receive connector, plus the typical default and client receive connectors.  All of our Exchange roles are on one server, there is one Send connector configured on our server Hub Transport.

Any help would be appreciated.
0
PaulR
Asked:
PaulR
  • 3
  • 2
1 Solution
 
Simon Butler (Sembee)ConsultantCommented:
Both of those errors are NOT Exchange errors. This will have nothing to do with the upgrade to Exchange. They are remove errors and usually mean what they say.
The second error is completely clear - the server accepting the email doesn't recongise the recipient. However that DOES NOT mean you are delivering to the correct server, it is most likely a DNS error at the other end.

The first error is often a sign of being blacklisted, not having the correct FQDN on the Send Connector or a missing PTR.

Simon.
0
 
PaulRAuthor Commented:
Something changed on our server with the upgrade, as this started happening as soon as the server came back up, and was not an issue before.

I have discovered some new information that would leave me to believe this is a DNS\MX lookup problem with SP3. In the examples above, the some.other.domain hosts the recipients website, but does not host their e-mail.

It looks like Exchange is using the A record instead of the MX record to send mail to.
0
 
Simon Butler (Sembee)ConsultantCommented:
Exchange simply does a DNS lookup. Nothing more. If the results aren't correct then there is nothing you can do about that.
Have you set Exchange to use external DNS servers? Have you set your domain controllers to use external DNS servers - as forwarders?

Simon.
0
 
PaulRAuthor Commented:
This has been resolved, or at least worked around.
In Exchange the Server Hub Transport properties had 4 dns servers configured for External DNS lookups, 2 at&t name servers (our ISP) and 2 opendns.  I had set this up some time ago (several years) attempting to increase the performance, which at the time it appeared to do.  To solve the current issue of Exchange sending to the A record instead of the MX record, in Exchange Organization Hub Transport Send Connector properties I UNchecked "Use the external DNS lookup settings of the server transport".  This solved the issue and improved mail delivery times significantly even on those where ther was not a problem.  The DNS serrings for the IP connection on this server are our two internal dns servers, which are configured to forward external lookups (1 server to a bellsouth name server, the other to 2 opendns name servers)
So I still do not know if Exchange began asking for the wrong record after the service pack upgrade, or if at&t began retuening the wrong records and the problem started when I rebooted the server clearing the cache of previously good lookups.
0
 
Simon Butler (Sembee)ConsultantCommented:
OpenDNS will be the source of this problem.
They return certain records no matter what the response, so that they catch the wrong host names and can display adverts.

As a rule, using external DNS servers in Exchange is to be avoided. It isn't best practises.

Simon.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

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