MX records

I have an email server named msx-102 that is my network domain and it is set up to except both and
The email address being used is which is a domain purchased from network solutions which hosts our dns for this. but we have our web site hosted by media temple
our media temple site is
or mail goes through a firewall at that is forwarded to the email server.
the system has been up and running a long time and I just took over here but I get errors when I run mx tests from different sites online and have never worked with exchange server before
what mx record and A record should I use.on both the network solutions dns and the media temple dns and both I can only use and not my actual domain mft.
shane mclaneNetwork AdministratorAsked:
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.

arnoldCommented: and zones should have a host record (A) as something like mail, MX, etc. that points to the 50.x.x.x IPS address
Lets say the host you have is mail.
The MX record is for and note in the domain zone @ means the domain name such that
@ IN MX 0 mail
In each will represent the correct MX record in their respective zone.

I have not run a check on the domains to see what the error you might be getting,.
From experience when someone has their domain registered through one entity while at the same time having some functionality (like web hosting in this case) provided by another, one thing to make sure that the site that only one entity has the domain defined in their DNS a servers.

Look at the registration record to see whose NAME servers are reflected as responsible for the domain.  Then Check the DNS record to make sure it is not pointing (NS) record elsewhere.

The reason I bring this issue up is that there are times if one has services through two well known firms, some resources/tools one might use online could rely on one of these providers such that the data you will get will depend on the provider.

I'll check the records and will update if necessary.
arnoldCommented: seems to be using a sendmail as a gateway to shield the exchange server.
The on the other hand has an MX record pointing to a host on the domain that does not exist. points to a 71 IP as the MX host.

The issue could be that for 71 is a provider service that filters (anti-spam, virus, etc) that is then forwarded to your MX server via said provider's email filtering management interface while the domain does not have this service from the other provider and is routed directly to your Exchange server.
shane mclaneNetwork AdministratorAuthor Commented:
The 71 address could be the old media temple IP address they have changed it since I started here and the only anti spam that I know of is GFI mail essentials hosted on the email server. Also the Problem is that our external DNS will only let me but in records for and not because we don't own MFT but thats what the previous administrators set it up as but not sure why. Pretty fresh out of school and didn't learn anything about Exchange or email so I don't want to break our email by changing the DNS records to fix them to pass external tests when it is working right now and there are two MX records in our external DNS but they are both meant for the same email server.. We only have one email server which I would like to add a second but have not been able to convince the boss to make the purchase.

Is it ok to only have the mx record and A record on the external DNS even thought the email server is in our network
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

shane mclaneNetwork AdministratorAuthor Commented:
Network solutions has these records
Host      TTL      Numeric IP
www       7200
@ (None)       7200
* (All Others)       7200
mail       3600
msx-102       7200

MXMailServer(Preference)       TTL       7200       
MXMailServer(Preference)       TTL       7200

Medial temple our web site host
 .       43200  A
 *.       43200  A
autodiscover .       43200  A
ftp .       43200  A
www .       43200  A
mail .       43200  A          43200     MX           10

I feel like deleting the MSX-102 record and changing the to 10 and then in our network change our email server name to mail from MSX-102 and join it to the Multifeeder domain from the mft domain its in just not sure how many problems that would cause and if I would have to go around on everyones computer in the domain to fix their email or maybe I should change the mft domain into the multifeeder domain or am I over complicating this
Svet PaperovIT ManagerCommented:
I would recommend hiring a consultant to do the setup. Basically, your Exchange could be member of internal domain and in the same time it can have external name. The setup is not complicated if you know what you are doing.

Your MX records seam correct. However, I am little bit confuse because you say that the MX is registered on the Medial Temple web site while the MXToolbox says it’s reported by a Network Solution server (which makes more sense). If Network Solution is the authoritative DNS (where the NS records are pointed to) for that domain you should enter all address records there.
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
OK, I'm going to chime in here and hopefully provide some clarity. First off, you did yourself a GREAT DEAL of GOOD by including your actual domain names in your question. (Some user try to obfuscate things, which leads to a lot more back-and-forth questions because they don't know the right [pertinent] information to present. In this case, with real data, I was able to query DNS myself to see what was going on... well done.)

For mail to work, you need MX records -- which are just pointers to (names that resolve to) A records. For decent mail service, that (those) IP address(es) must have non-generic PTR records as well.

For your domain, you have:                86400   IN      MX      10  =->  =->
-- THIS IS PERFECT! The MX record returns a name that resolves to an A Record (not a CNAME), and the IP address of that A Record resolves to a real FQDN. I would guess mail flow for is working properly.

BUT for your domain, you have        7200    IN      MX      10         -=> RESOLUTION FAILURE!        7200    IN      MX      20  -=> -=>

So you have TWO problems with
 - FIRST, your PRIMARY mail server (lowest weight) doesn't even RESOLVE, so all mail is reverting to the other server
 - SECOND, your other server has a GENERIC PTR record associated with its IP address.... not all, but MANY large mail providers WILL NOT deliver mail to such a server.

Now at the onset, you said both domains were using the same MS Exchange server (eventual destination of inbound mail)... and you also implied that the mail for was running smoothly... so, if it was me, I would choose one of 2 paths:

1) If I don't care about keeping the domain spaces separate, simply change the MX records for to be exactly what the MX records are for (That is, delete the entry and change the msx-102 host name to
 - or -
2) But, if I wanted to maintain a (false) sense of separation between the 2 domains, I would delete the MX record, and change the entry to point to an A-Record that also resolves to Again, if it was me, I would just make the A record for resolve to

Lastly, if there is some reason for the host that is at being the MX server for the domain, you have to call Comcast and have a more reasonable PTR record created. My suggestion would be whatever the hostname you use in your MX record (as-is, that would be

FWIW: No other parts of your DNS are affecting mail flow. Websites are another matter you didn't address in your question.

I hope this helps you resolve your issue.


PS: I am assuming your internal mail clients are connecting to the Exchange Server -- and most likely on a LAN IP -- so none of this would affect them. If they are using msx-102 (which doesn't resolve to the outside world currently), then an A-record pointing to the right location is the right thing to do -- no sense making the clients change (forcing n-changes, 1 per mailbox at a minimum) when you can fix it in DNS with only 1 change.

No rule says that you can only have 1 A-Record point to any IP address (but it is generally NOT a good idea to have more than 1 PTR record for any 1 IP address).
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
One thing to add:

There seems to be also a question about WHERE to make any changes:
 - If you are changing things in the domain (which I DO NOT recommend) you would need to go to either or
 - If you are changing things in the domain, you would need to go to the nameservers at (which is Network Solutions).

I will re-iterate my statement above, which is to say that I think your problems are solved with 2 changes:
 - Make only 1 MX record (vs. 2), and
 - Either use in that 1 MX record, or use an entry in that points to the address.

Final note: It DOES NOT MATTER if the MX record for multifeeder is pointing to some other domain name, and it does not matter if the PTR record for the IP address uses a different domain... just so long as it isn't generic.

shane mclaneNetwork AdministratorAuthor Commented:
Not sure if you saw but is only in our actual network domain inside our firewall a non public ip range domain name must be owned by someone else the only domain we own and is public is but when who ever set up this network they for some reason named it mft in active directory.

Right now I feel safe deleting the msx-101 and changing the mail.multifeeder to the only MX record Just wish I had set this network up from scratch, they didn't remove domain controllers or email servers correctly
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
I was wondering about that -- 3-letter domain names are rare! :)

Still, there are some things that need to be done:
 1) delete the MX record that points to a non-existent record ( -- from what you've said, that is a LAN domain name to begin with, so it CANNOT be right!
    - Brief aside: you do know you'll never be able to access the "real", right?
 2) fix the PTR record for -- and to do that, you have to call Comcast (your ISP). The entry you want is
 3) fix the SMTP greeting of the host answering -- it should say, not

Also, there are some minor issues -- like the server isn't allowing TLS connections, and appears to have an old-fashioned connection delay (used to be used to combat SPAM) that should be disabled.

FWIW: Check out to test your server and settings.


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
shane mclaneNetwork AdministratorAuthor Commented:
Ok I'm working on all of those things but what exactly do I need on my internal DNS server. Do I only need a msx-102 because it is a local machine and is on or dns domain. I know that incoming email don't touch our dns so not sure how important that is I know all of our outgoing emails have no problem well that I know of. I will check the changes I made to the DNS in a day or so giving them time to update through everywhere.
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
internal dns won't really affect mail delivery. The mail server has to have an Internal DNS name, but that's also a requirement for AD.

Internal mail will be delivered with no DNS (other than the internal DNS used to identify the exchange server) (and that is not an MX record, just an A record).

External mail will be delivered by Exchange using external DNS name resolution, as configured on your Exchange server (unless overridden in Exchange -- but you can override ANYTHING, so that's not really worth mentioning).

your internal DNS server should match the external/public DNS entries for public domains which seems to be what is going on. public domain as well as used for the AD.  The consequence is that your internal DNS is authoritative for but if you look at the public registration record other servers are listed
This is so that users from the LAN can access the same resources as those outside.

Your internal could reference the internal IP of the Server

I think this MX question is ...... going into other matters, it might be best to start a separate question to address a specific item of interest to you.
shane mclaneNetwork AdministratorAuthor Commented:
I have actually fixed everything that has been failing the external tests now and updated all dns record and sped up the smtp response time by about 800% now all I have left is
SMTP TLS       Warning - Does not support TLS.   which I though I had set right but still throwing that error
On which server? STARTTLS is not an option on either of your mail servers.

Are you talking about using TLS/SSL when you want to send emails out from the LAN or when remote to the domain?
shane mclaneNetwork AdministratorAuthor Commented:
SMTP TLS       Warning - Does not support TLS.
Connecting to

220 Service ready [671 ms]
250-Requested mail action okay, completed
250-SIZE 30000000
250 OK [686 ms]
250 Requested mail action okay, completed [671 ms]
550 Requested action not taken: mailbox unavailable [811 ms]

When I do a test from  I get the error about saying I don't support it even though I feel like I did everything right to set it up and made sure I enabled it in the firewall as well.

MXTB-PWS3v2 3588ms
Your server is not enabled to support TLS a, the STARTTLS option is missing from the response to the ehlo greeting.

Double check that the connector has a certificate which is needed for starttls.
Similarly for ssl/TLS connection.

Difference starttls starts as a plain text connection on port 25 and then negotiates an encryption session.
While the other starts an encrypted session from the get go.
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
2 quick things to point out:
 - First, you don't have to purchase a public Certificate (depending upon the source, they can be expensive) -- a self-signed certificate should be fine (and lack of a certificate is, in my experience, the most common reason why Exchange doesn't offer a TLS connection).
 - Second, the SSL (that is, encrypt from the get-go on a separate port) options to the mail protocols (SMTP, Submission, POP, & IMAP) are all pretty much deprecated (that is, not being recommended anymore) in favor of STARTTLS (start unencrypted, then negotiate an encrypted connection) -- which can use the same ports as the "standard" protocols.

The TLS connection that works on Exchange (on port 25) is, by definition, a STARTTLS connection.... and, again, it is likely not being offered because there is likely no certificate (not even self-signed) available to encrypt the data with.

SSL/TLS can be a BEAR to understand -- even for some professionals -- unless you just keep a 10K foot perspective on it and just let the magic happen.

I don't know which Exchange you use, but at least as a starting point, try the link here (which is for Exchange 2010).

shane mclaneNetwork AdministratorAuthor Commented:
I have a bought certificate that I have assigned to both connections and when I telnet from a domain computer in my network and run ehlo It shows the STARTTLS but when I run the test from the mxtools website it shows it does not support it. The exception through our firewall I made for port 587 ended it having an affect on our vpn so I disabled it till I can investigate it in more depth.

Can I control what port that STARTTLS operates on
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.