2

We are having issues with our exchange 2013 server. The server is running Windows Server 2008 R2 Standard.

The issue we're having is that our Exchange server isn't receiving internet emails. It can currently send mail out to internet addresses, and send and receive internal emails from the current email server. I have checked the settings of the receive connectors and everything seems correct. We have tried everything that we can think of.

We can send and receive email locally, and send out to a gmail account. However, we don't get the reply email from the gmail account to the inbox.

Thanks in advance!! Image is of the DNS settings on the exchange server. enter image description here

14
  • 3
    Then that is your first problem. – mfinni Sep 3 '14 at 16:39
  • 1
    It looks like you might be using the Sonicwall hosted email security product. When that is configured inbound email is typically first routed to that service, scanned for email, then forwarded to the destination email server configured within the service. Do you have a login that you can access the Sonicwall hosted Email Security service to check the settings? Specifically there should be a setting where you can enter the hostname or public IP address of your exchange server for final delivery. You may also be able to see the queued messages when logged in to the control panel. – petemcdonnell Sep 11 '14 at 19:07
  • 1
    The DNS settings for Exchange have nothing at all to do with how it receives messages; they are only used when sending messages. – Massimo Sep 26 '14 at 16:00
  • 1
    Try to telnet to 173.10.197.225 on port 25. There's something anwering there, and it says 220 sjl0vm-cass01.colo.sonicwall.com ESMTP SonicWALL (8.0.1.2353). This is not an Exchange server. – Massimo Oct 2 '14 at 20:56
  • 2
    @DerronR, your firewall should forward TCP port 25 to your Exchange server, not answer it on its own. – Massimo Oct 6 '14 at 14:57
5

This looks like a DNS problem.

First of all, a little tip: it's quite useless to obscure your IP address while you post your DNS names... we have DNS resolution too :)

Ok, let's have a look at it. autodiscover.clearspaninc.com and owa.clearspaninc.com seem to be defined, but they can't be resolved, at least from my network. This prompted me to have a look at the NS record for the clearspaninc.com domain:

Non-authoritative answer:
clearspaninc.com        nameserver = ns0.directnic.com
clearspaninc.com        nameserver = ns1.directnic.com

ns0.directnic.com       internet address = 74.117.217.20
ns1.directnic.com       internet address = 74.117.218.20

Ok, let's stop here for a moment. You posted a screenshot from what clearly looks like a Microsoft DNS server, but those listed here are definitely not your servers: it looks like your DNS domain is actually managed by your ISP, not by you. Thus, anything you write in your DNS server is simply going to be ignored by the rest of the world.

And, indeed, the problem seems to be here. For me (and for the rest of the world), the name mail.clearspaninc.com resolves to 173.10.197.225, and when doing a telnet mail.clearspaninc.com 25, this is what I get:

220 sjl0vm-cass04.colo.sonicwall.com ESMTP SonicWALL (8.0.1.2353)

Whoops. This definitely isn't your Exchange server.

7
  • I had my NIC settings set up wrong, but I've changed them to what they're supposed to be. What you hit was my firewall.if you could try again to see what you can resolve, I'd appreciate it. – Derron R Sep 11 '14 at 19:03
  • +1 for being helpful and humorous – nate Sep 11 '14 at 19:05
  • @DerronR Your NIC hasn't anything at all to do with this. You are looking at your DNS server, but that server is not authoritative for your DNS domain: everything you put inside it is simply ignored by the world. You have to configure the real DNS servers for your domain, i.e. those managed by directnic.com. – Massimo Sep 11 '14 at 20:33
  • I've taken what you've said and implemented it, but the same problem remains. I've posted an image of the current DNS settings from the EAC on the Exchange server. – Derron R Sep 26 '14 at 15:44
  • You're looking at the wrong place again. In the EAC you are configuring the DNS servers that Exchange uses to find the destination domains when sending messages. This has nothing at all to do with how it receives messages. – Massimo Sep 26 '14 at 15:57
1

From an outside network try using telnet to telnet into the smtp port.

telnet IP 25. You should get a reply. where IP is your external IP address.

in some cases people redirect smtp.domain.com to their ip. In which case telnet smtp.domain.com 25

1
  • I was able to connect using smtp.domain.com 25. – Derron R Sep 3 '14 at 18:21
0

First of all, check if the various transport services are running; then use netstat to check if there's actually something listening on TCP port 25 on your Exchange server.

Next step: from the server itself, do a telnet localhost 25; you should get an answer from Exchange's SMTP server. You can also do the same from another computer in the same network.

If everything looks ok from the inside, try connecting to your external IP address's on TCP port 25. Try this from an actual external computer, because depending on your firewall configuration, this could fail if you try it from inside your network (due to a phenomenon called Hairpin NAT).

If you can't connect successfully from the outside, then you have a firewall problem; if you instead can, then double-check if the MX record for your domain is actually pointing to your public IP address.

If even this is ok, then your Exchange server is very likely receiving external messages, but it's rejecting them for some reason; the SMTP logs should be able to tell you why.

3
  • I have tried everything but checking from an external network, which I am working on setting up. I could connect to both the localhost and our public IP address using 'telnet address 25'. Once I get the results from the external test, I'll post them here. Thanks for the direction! – Derron R Sep 11 '14 at 15:21
  • I was able to connect to our public IP address from an external network. I will post an image of our DNS records concerning our Exchange setup – Derron R Sep 11 '14 at 18:02
  • Looks like a DNS issue; see my new answer. – Massimo Sep 11 '14 at 18:51
0

Your problem has been answered several times above. When email is routing from an external source to your domain, it first goes to the DNS server that is the start of authority (soa) for your domain. Your DNS server is not the soa for your domain (for external name resolution), your ISP's DNS server is. The ISP has not delegated the soa for your zone to you. Because of this, Your ISP must add an MX record that points to the exchange server in your domain. This record tells the soa dns server where to send email for your domain. The email traffic will then be sent to your dns server which will resolve it to your exchange server. You can also ask your ISP to delegate your zone to you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.