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

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 <server.domain.net>: 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.
2 Solutions
You should actually know what your HELO command is to start solving this.
Assuming it's properly named as your FQDN, like mailserver.domain.com, you usually set an A record for mailserver.domain.com 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.
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 "mail.contoso.com"

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 "mail.contoso.com" -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.

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

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