Exchange 2010 Receive Connector, One Server, One NIC, *.local Domain Configuration


I've have a question about the right way to configure a Receive Connector for a single Exchange 2010 Server without an Edge server.

I have a *.local internal domain name for the Microsoft domain. The default receive connector is Default EX1 and is bound to port 25 and under the "Specify the FQDN this connector will provide in response to HELO or EHLO:" I have the *.local domain. (from what you I know you don't want to mess with this).

Now I need to configure a Receive Connector for the *.com external FQDN domain so that I have a *.com domain under the field for "Specify the FQDN this connector will provide in response to HELO or EHLO:". And it will provide the correct HELO response to external queries for blacklist purposes, etc.

In configuring the second receive connector I had to configure a 2nd IP address on the same one NIC as two receive connectors can't be on the same port (port 25) with the same IP address.

This has been working for the last year in one setup but is it the correct way of doing this?

I seen examples on Microsoft's websites where there's only one receive connector but that's because they used a *.com for an internal domain name, rather than the *.local which is what I've known to use as the recommended practice.

Using a *.com domain name would eliminate the need for the second one as your HELO EHLO response field can just be your external domain name such as

I'm about to setup another network with a single Exchange server and am trying to determine if I should make it a *.com local domain or a *.local based on the above.

Thanks a bunch.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

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.

If you speak to a lot of people, they will tell you the best practice is to install an Edge Transport server. Unfortunately, most sites smaller than several thousand users do not often have the resources to run a dedicated edge network just for email delivery, so I expect that option is out for you!

The problem you will face with the "Default <Server Name>" receive connector is in its default Authentication options: Exchange Server authentication is, by default, enabled. This prevents you from changing the FQDN to a value other than the server's internal FQDN/NetBIOS name. As you would expect, Exchange Servers need to be able to communicate with each other on a network, so it is advisable to leave this default configuration enabled. Even if you are a single server setup now, you don't necessarily know when you may require the ability to talk to multiple Exchange Servers on the network.

There's no real "best practice" I'm aware of which describes how best to configure this, except using an Edge Transport server. That said, there's a number of options which I would typically opt for:
In a single-server deployment, disable Exchange Server as an authentication method on the default receive connector. This gives you the freedom to change the FQDN on the connector to a value other than the server's internal FQDN (ServerName.domain.local), but does mean you are meddling with default permissions setups
add an additional IP address and bind a receive connector with anonymous authentication to that IP, as you have done already
or, enable anonymous authentication on the default connector, don't change any other parameters, and the leave the HELO/EHLO response in the default setting (the FQDN of the server)
You may be surprised by the last possibility above, but this is an entirely possible configuration. I know of many servers which employ this set-up and have no problems sending or receiving email.

RFC 5321, at least in my interpretation, is quite loose in the regard of what should be returned in the server's 220 response at the start of the SMTP session. The most I could find is: (section 3.1)
SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems.  Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns.
and section 2.3.5:
Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP.  In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs... are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs
So, based on section 2.3.5, you may be in breach of the SMTP RFCs by not specifying the proper FQDN on your receive connector, but in my experience, this has never posed a problem - and I think the RFC is quite loose in this regard. There's nothing in the RFC (at least, nothing I can find or recall) which explicitly states the nature of the initial 220 response at the beginning of an SMTP session.

Now, all of that is for receiving. What does matter is the HELO/EHLO your server announces when sending email. In Exchange 2007 and 2010, the send and receive connectors are split, as are the FQDNs configured on them. (In Exchange 2003, the name for sending and receiving was the same, and configured on the SMTP Virtual Server). As an anti-spam technique, most anti-spam software will do a Forward-Confirmed reverse DNS (FCrDNS) check on the name you present in your HELO/EHLO announcement when sending email. It is critical, therefore, that this name is a valid, publicly resolvable name. This is what you configure on your send connector.

In all honesty, I have a couple of servers which are still configured with their default property on the receive connector, and have no issues sending and receiving email. Whether I am in breach of the RFCs, I am not completely sure, but I'm fairly convinced based on the above that I am not. What matters is that the outbound HELO/EHLO is correct, and this is set correctly on all those servers I manage.

How you go about this is entirely up to you. Adding the additional IP address is definitely a valid and acceptable method, but also increases complexity with your Exchange deployment. I've also fiddled with authentication parameters to make use of the default connector.

It's entirely up to you, but as I'm sure the above has proven, there's no 100% definite answer!

RFVDBAuthor Commented:
Hi Tigermatt,

Thanks for the VERY comprehensive answer. I just went on a long vacation as you answered and just came back. Will be reviewing this in the next couple of days and will then get back to you.

Best, Jonathan

More than welcome, and no worries on the delay. Just let me know if you do have any questions and I'll be happy to answer them.

I hope you enjoyed your vacation!

Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

RFVDBAuthor Commented:
Thanks a lot for the comprehensive answer. I guess my last question revolves around the following:

1) From what I know you need to have a Reverse pointer record pointing to your outgoing SMTP Public IP address otherwise you get blacklisted? But your SMTP outgoing address doesn't have to be the same as your MX record right? Or do external mail/spam servers compare your reverse pointer IP address to the IP address or FQDN of your MX Record?

Or do they compare the header information (where it says the FQDN server info, etc.) in the email to the Reverse PTR Record?

2) Is the HELO/EHLO response on your MX record actually tested by external mail/spam servers for the correct DNS name matching your MX record - for spam reasons? Or does it not matter if it says mail.domain.local or

Thank again

Hi Jonathan,

...need to have a Reverse pointer record pointing to your outgoing SMTP Public IP address otherwise you get blacklisted?

Yes, you need to have what is known as forward-confirmed reverse DNS resolution on any public IP addresses which you issue mail to the Internet from. This means that a PTR lookup on the address should return some hostname, say If a forward DNS lookup is then performed using that hostname, the outbound IP address should be returned again - i.e. you should be able to go full circle by looking up the PTR record and then using that result in a further A record lookup.

You do have to be careful with this though. Many ISPs will create default PTR records for IP addresses in the zone; these are often rejected by spam filtering services, even if they would otherwise satisfy the requirement above, so I would not advise keeping the PTR record if at all possible. Your ISP will be able to change it.

I was wrong on my original comment above - I said the FCrDNS needed to be on the EHLO/HELO announcement as set in your send connector, but that's incorrect! My fault. The FCrDNS is literally just using the physical IP address your server is appearing to the Internet as and performing the two DNS lookups I outlined above.

Further, while the EHLO/HELO response in your send connector does need to be a valid domain name, it is not permitted for a mail transfer agent to reject mail on the basis of a faulty EHLO/HELO header:

An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis
-- RFC 5321 (Section 4.1.4)

Of course, whether every MTA out there heeds that section of the RFC, I cannot comment. It is definitely advisable to use a valid, publicly routable domain name for your outbound HELO, which means you also satisfy the next requirement:

The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal...
-- RFC 5321

But your SMTP outgoing address doesn't have to be the same as your MX record right?

Correct. Many, many people claim that these records need to match, but there is absolutely no requirement for that to be the case. If it were, all the third-party cloud-based spam filtering services would run into problems! With those services, the customer typically routes their inbound MX to the cloud-based service, but they issue email to the Internet directly (not via the cloud service). In that case, the records would not match and so there would be all sorts of issues to contend with! In reality, this works just fine across the Internet, so this claim is supported!

Is the HELO/EHLO response on your MX record actually tested by external mail/spam servers for the correct DNS name matching your MX record - for spam reasons?

There is a system called callback verification in which a receiving server opens an SMTP session back to one of the MX records listed on the sender's email address domain, and then mimics an SMTP session to try to decipher whether the address is valid or not. However, this is a technique which I have not seen commonly used, simply due to the significant overhead it would involve on large systems - and it also has the propensity to make the checking server (which is legitimate) look like a spammer performing a dictionary harvest.

I'm not aware of any widespread use of going to the lengths of connecting back to the server listed in the sender's MX record and then explicitly checking the EHLO/HELO response sent back for validity. As per the above RFC outtakes, technically that does need to be a valid domain, but nothing can be inferred or blocked based on EHLO/HELO responses, and it would be a massive performance hit to be connecting back to sending servers all the time.

does it not matter if it says mail.domain.local or

On the inbound, my professional opinion is that it does not matter. From a strictly technical perspective, you are probably in breach of the RFC section I quoted above (domain names, where used, must be fully qualified and resolvable) but I have seen plenty of MTAs configured (even one such example which dealt with tens of thousands of messages for thousands of users on a daily basis) with their default server.domain.local on the inbound receive connector and have never had a problem.

So, strictly, it should be on the inbound receive connector, but in reality, it does not cause an issue. Your outbound configuration, DNS wise, is much more critical.

I thought you might appreciate the following two screenshots which I have taken from the administrative console of my favourite anti-spam product, Vamsoft ORF. This is a product I have been using for years with massive success. There are also cloud services, including one from Microsoft, which also work really well.

The part I like about Vamsoft is that there is no "content scanning" (bayesian filters and such) - everything it uses to filter spam is based on very rigid interpretation of the RFCs. I tend to trust that the software has interpreted the RFCs correctly! Here are two outtakes from the "HELO Blacklist" and "Reverse DNS" filters:

Reverse DNS filterHELO/EHLO filter
RFVDBAuthor Commented:
Hi Matt,

Wow, thanks for the comprehensive answer. I wish I could give more than 500 points for your answers!

So basically in its most simplest form, this is what I get from the above that I would need to have in place:
1) The sending domain needs to have an MX record, whatever WAN IP that points to, we don't care - they don't do EHLO/HELO checks on the MX record.
2) The send connector's External IP however that its coming from needs to have an A record in place so that you get FCrDNS - it DOES NOT NEED TO MATCH AN MX RECORD, JUST AN A RECORD.
3) The send connector EHLO/HELO response doesn't need to match the FCrDNS, but for the sake of those off-RFC spam filters out there, why not match it. :)

Thanks a bunch!

Best, Jonathan
Yes, that looks exactly right to me. Well done for distilling that from my verbose answers above (you've probably noticed I like to answer with lots of detail!).

Best of luck with it all and let me know if I can be of any additional assistance,


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
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.