Since I am getting things ready to switch over Exchange. I've just noticed there are so many existing A records and NS (name server) records as below
domain.com 86400 IN NS ns32b.ssggrp-wc.com. domain.com 86400 IN NS ns32a.ssggrp-wc.com. www.domain.com 86400 IN MX 50 mail.domain.com. domain.com 86400 IN MX 50 mail.domain.com www.domain.com 86400 IN A 198.66.X.Y domain.com 86400 IN A 198.66.X.Y webmail.domain.com 86400 IN A 198.66.X.Y smtp.domain.com. 86400 IN A 198.66.X.Y mailhost.domain.com. 86400 IN A 150.101.Y.Z mail.domain.com. 86400 IN A 198.66.X.Y ftp.domain.com 86400 IN A 198.66.X.Y cp.domain.com 86400 IN A 198.66.X.Y
As you can see there are only 2 MX records and one A record that I am interested and going to change
www.domain.com 86400 IN MX 50 mail.domain.com domain.com 86400 IN MX 50 mail.domain.com mail.domain.com 86400 IN A 198.66.X.Y
How about the rest? does it mattet if I leave them as is? Thanks a lot.
Posts: 897
Joined: 4.Jan.2007
From: Chicago, IL
Status: offline
I would just take a step back and look at what you need for your implementation to work 100% for mail flow. You can then go try your best and find what those other records are for.
What I personally see as essential are the following: MX record for each Accepted Domain A record in which the MX record points to PTR record for your sending server's IP. The PTR record can really be any valid A record but I typically try to have the Send Connector's SMTP Address match the PTR record in which there is a valid A record for which points to the Sending Server's IP.
There are other optimal things as well such as having an SPF record to prevent spoofers and having a custom Internet Receive Connector with an SMTP Banner FQDN which matches your A address. Etc...
So try to validate the above and then look at what your other records are for. But having the above should get you fully functional.
Hi Elan Thank you for your response and helful blog that I've read through.
Thought I'd let you know that we already tested sendng/ receiving internally fine. Externally: Sending out to the internet emails (gmail, hotmail...) was fine, Using Telnet (thank you Simon) to send an email from the internet emails was OK as well meaing that we can receive emails from outside world. Does it mean that all the DNS settings are OK?
From the previous post, all A and MX records I took from the DNS setting in the Account Control Panel website where I need to change the MX record pointing to our public IP address, so that all inbound emails will come to our Exchange, I hope it makes sense to you.
Because there are so many A and MX records already there, it is confusing me. Please excuse me, if I asked too much.
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
It would seem that the host has setup www.domain.com as a subdomain, with MX records. So you could send an email to user @ www.domain.com and it would be delivered. Most odd and unnecessary.
The reset are A records and have little to do with Exchange email delivery.
As I've never done before, now I start worrying, on 24-12-08 I switched over by changing IP address of A record (mail.domain.com) to our public IP address provided by ISP, and now both POP3 and Exchange cannot receive any emails from external, supposedly POP3 should be still working, but now POP3 clients cannot log on POP3 server anymore. Even worse I cannot open Account Control Panel website for this domain. Should I wait one more day because it has only been 24 hours?
Additional Info: When I first switched over, I did send an email, then I got a Undeliverable Email Notification, but now I no longer receive those emails. Is it a good sign? Thanks
Thank you and Merry Christmas
Regards
< Message edited by ctvu -- 25.Dec.2008 5:01:35 PM >
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
In your POP3 client was it using mail.domain.com as the POP3 server? If so that would stop you from collecting email. You would need to switch over to the IP address.
Control Panel access shouldn't have been affected either - but again try using the IP address instead. Most ISPs/domain hosts will have their control panel on a single IP address for all of their hosts, so if you have made an error on your own domain you could use another address to access it.
Thank you Simon. You're quite right. Now I have to use IP address to access to the Account Control Panel. Everything seems in order, but I have not been able to receive emails from outside at all. I double checked with our hosting domain support, they said the A record and MX record that I changed on 24-12-08 look perfect. I did NSLOOKUP and set type=MX, yes it is pointing to our public IP address. I can do TELNET to send emails from outside, and they were able to receive them. The internal users can send outgoing/ or internally emails. Because the internal Domain name is domain.com.local that is different from the internet one domain.com and we use john.smith@domain.com Should I reconfigure the DNS for domain.com in the DNS server?
Additional info: I cannot Telnet from outside (connection failed), I even turned off Trend Micro Agent on my laptop. But when I am inside the network then I am able to. There is something missing here. I am running out of time and clues.
Any help would be much appreciated.
Regards
< Message edited by ctvu -- 27.Dec.2008 2:10:12 AM >
Posts: 4093
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
If you cannot telnet in to your server from outside then something is wrong with the port.
It could be blocked, by your firewall or your ISP. Check your default gateway is set correctly. Ensure that anonymous is enabled on the SMTP virtual server. Ensure that there are no connection restrictions on the SMTP virtual server. Ensure that your firewall isn't scanning SMTP traffic as well.
If you cannot telnet in to your server from outside then something is wrong with the port.
It could be blocked, by your firewall or your ISP. Check your default gateway is set correctly. Ensure that anonymous is enabled on the SMTP virtual server. Ensure that there are no connection restrictions on the SMTP virtual server. Ensure that your firewall isn't scanning SMTP traffic as well.
Simon.
Thank you very much Simon. You are indeed a super legend. It turned out our Cisco ASA Firewall was blocking port 25 (SMTP) , once I found out that unable to telnet from outside, I realised that must be the Cisco firewall. Everything is OK now. Without your help and support, I would not be able to survive. Once again very much appreciated.