No announcement yet.

Reverse DNS/Send or Receive connectors question

  • Filter
  • Time
  • Show
Clear All
new posts

  • Reverse DNS/Send or Receive connectors question

    I'm looking to resolve some Reverse DNS errors I'm getting on MXToolBox. My company has 3 data connections from 3 separate providers, connected to a single Exchange 2007 server and one domain. I have an MX record for each line. They all are passing inbound/outbound email without a problem. The Rev DNS error only shows up for the 2 new lines, our original one does not have any errors.

    MXToolBox recommends updating the Send connector with the correct public DNS name. Since each ISP data connection has it's own unique A record, I have a problem because my send connector can only be configured for one dns name.

    I believe the solution is to create a Send Connector for each ISP connection, along with ip addresses, firewall/nat rules and such. Then I would be able to configure the proper DNS name for each Send connector. However, I'm a little nervous to do this as I have not touched the Send connectors before and they are working right now and I don't want to cause a big problem. Also, would I need to create separate internal IPs assigned to the server for each Send connector so the firewall natting can be mapped to the proper connector?

    Does this seem like the right approach? Any tips/advice/etc much appreciated! thanks...

  • #2
    Re: Reverse DNS/Send or Receive connectors question

    So I went ahead and added Receive connectors, and all's well. The Reverse DNS lookups are functioning normally now. However when I try to add similar Send connectors that are bound to specific IPs on the server, and disable the out-of-the-box 'To_Internet' Send connector, messages sit in the queue with the error 'A matching connector cannot be found to route to the external recipient'. As soon as I re-enable it, they send out. I would like to set up the Send connectors as well, any have an idea what I'm doing wrong?


    • #3
      Re: Reverse DNS/Send or Receive connectors question

      This isn't going to work as you expect.

      First - any tests conducted from the Internet are not going to give you valid information, because when they make a connection from the Internet they are seeing the results of the Receive Connector, not the Send Connector. Therefore making changes there is a waste of time, and will simply complicate matters.
      The FQDN value on the Receive Connector should be either null, the server's FQDN or the NETBIOS name of the server.

      Next - there is no way to bind outbound traffic to different IP addresses depending on the IP address being used. Hopefully you are using a router to manage those connections and do not have multiple default gateways on the machine. If so, then you should decide which connection is primary and route all SMTP traffic out through that one.
      The other way round this is to use a smart host on the Internet, this can be a server you run, or a third party service. Then configure the Send Connector to send email to that smart host. Then it doesn't matter which route the email takes between the two servers. That is what I do myself as I have multiple connections for my home office.

      Finally, there is no "out of the box" Send Connector, Exchange doesn't create one unless this is SBS. Therefore that connector was created by someone. As you cannot setup Send Connectors in the same way, using specific IP addresses (because Send Connectors belong to the org, not the server), not really sure what you have done here.

      Simon Butler
      Exchange MVP

      More Exchange Content:
      Exchange Resources List:
      In the UK? Hire me:

      Sembee is a registered trademark, used here with permission.


      • #4
        Re: Reverse DNS/Send or Receive connectors question

        OK I think I'm good to go then. My goal is just to ensure that all my public DNS stuff and Exch Connectors are configured properly so that we don't have email delivery issues caused by a misconfiguration that leads spam filters to believe they should block us.

        Here's what I have now:
        1 Send connector, FQDN is set to proper public dns name
        3 Receive connectors, each bound to a unique IP on the server.
        3 public DNS names & MX records that point to each of our ISP data lines. Each dns name is set on the corresponding Receive connector.
        3 firewall/nat rules that route each ISP's line to the proper Receive connector

        Thanks Simon for your reply, appreciate it