Public DNS record for Exchange 2013 server


I hope someone can help. With a bit of investigation, I'm sure I could source the answer to this but am in need of a quick fix hence posting this question.

I use an Exchange 2013 server purely for relaying mail from applications and services. Mails to one domain are failing with the error:

450 4.7.1 <>: Helo command rejected: Host not found

I have been told by the recipients that this is happening because the FQDN of our server does not resolve to a public IP address. So, my first question is, what type of record needs to be created for this? An A record I presume? We have public IP's available.

Secondly, when I have requested this record to be created I have been asked what inbound ports need to be allowed. Is there a simple list of these? I would presume: 25,443,80,465,993. Any others?

Thanks, and sorry for the slightly dumb questions.
Who is Participating?
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.

You should actually know what your HELO command is to start solving this.
Assuming it's properly named as your FQDN, like, you usually set an A record for to your public facing IP number.
HOWEVER, some servers will double check, the reverse DNS. That one you cannot solve by yourself. Some servers will now do a lookup for your public IP number, and only allow further communication if it matches the A lookup earlier. Since you don't own the IP number, the company that does (your ISP probably) will have to set a reverse DNS entry for you (they might charge you some administration costs).
The reasoning is that you are putting quite an effort to get these records straightened out, while a spammer cannot get this done.
Your inbound ports are as follows:
25 incoming mail - plain text SMTP protocol
80 http
443 https
465 SMTPS (secure smtp, SSL enabled)
993 secure IMAP

Only 25 is important for incoming mail. The rest are for your clients retrieving their mail, but it's not necessary if they don't need to use it outside the office.

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
Along the lines of what Kimputer has stated.  You would use the Set-ReceiveConnector commandlet, e.g. -
Get-ReceiveConnector "EX2K13ServerName\Default Frontend EX2K13ServerName" | Set-ReceiveConnector -fqdn ""

Open in new window

I have also read that if you are in a single Exchange environment, you will want to disable 'Exchange Server Authentication' on the 'Default Frontend EX2K13ServerName' connector.

That too can be accomplished with the same commandlet, e.g. -
Get-ReceiveConnector "EX2K13ServerName\Default Frontend EX2K13ServerName" | Set-ReceiveConnector -fqdn "" -AuthMechanism Tls, Integrated, BasicAuth, BasicAuthRequireTLS

Open in new window

Changing FQDN on EHLO for External:

Setting up Authenticated SMTP relaying in Exchange 2013:

Seth SimmonsSr. Systems AdministratorCommented:
you will definitely need 25 as a starter
web server ports should only be exposed if this is has the CAS role and you are allowing users to access OWA
465 and 993 only if you are actually using those services
in addition to the PTR  (reverse DNS record created by your ISP) mentioned earlier, good idea to add SPF record (a TXT record in DNS) as some recipients do check that to verify that server is authoritative to send for that domain

Sender Policy Framework
ishamsiAuthor Commented:
Thanks for the comments everyone. For me, it was fairly simple. I got the firewall guy to map the internal IP of the server to one of our public IPs. He opened inbound ports 25, 443, 80, 465. After this I could telnet to the server from outside our network, using it's IP address. One thing to note was that, the IP he address he mapped it to was different to that which was previously added as a PTR record with our ISP. So I contacted the ISP and got them to change that. I then put an A record in our public DNS that resolves the (new) public IP to the FQDN of the server.

I think one of the things that threw me is that domain suffix of our internal domain is different to our public facing domain and as such, I had never had to create public DNS records for it.

Thanks for the help everyone.
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.