Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 822
  • Last Modified:

Mail issues with multiple MX records

I have a client who's in-house Exchange server went down this weekend and they did not have any type of service or appliance that would capture and queue the e-mail until it was brought back online (sans the sending servers auto-retry policies).  While I was working on the Exchange server, I setup a second MX record and pointed it to a one of my servers where I installed hMailServer and configured it to mirror the e-mail accounts on their Exchange server.  Here are what the MX records look like:

MX Record 1:  Priority-0  Destination-mail.domain.com

MX Record 2:  Priority-15 Destiantion-mail2.domain.com

Eventually I got the Exchange server online and all e-mail again began flowing properly to it; or so I thought.  I decided to leave my temporary backup e-mail solution in place until I could speak with my client more about the need for a queuing service / appliance or fail-over e-mail server.

This morning I was running a check to make certain my client's Exchange server was still running as expected, which it is.  I then decided to check the backup e-mail server and noticed some e-mail had come in even after I fixed the Exchange server.  I did quick a comparison of a few accounts and sure enough they are receiving e-mails on both the Exchange server and hMailServer.  To be clear, they are not duplicate e-mails being received on both servers.  Rather, several e-mails will go to the Exchange server and then several will go the hMailServer...and so on.  As a result, I have removed the second MX record to force all e-mail to go to the Exchange server.

My question:  Why would e-mail still route via the second MX record if the server pointed to from the first MX record is up and receiving e-mail?  I thought MX Priority 0 was much higher than MX Priority 15?  Can some please help explain why this is happening?

Thank you!
0
Yort
Asked:
Yort
  • 4
  • 2
  • 2
1 Solution
 
LeeDerbyshireCommented:
It might just be down to propagation delays. There is a nice DNS propagation tester here:

http://www.whatsmydns.net/
0
 
YortAuthor Commented:
LeeDerbyshire - thank you for the quick reply.  I am a bit confused by your response.  After I added the second MX record it took about 30 minutes to propagate and for e-mail to start flowing into the backup hMailServer; I never made any changes to the first MX record.  Once the main Exchange server was online, all e-mail, theoretically, should have started flowing to it since its MX record has the highest priority.
0
 
LeeDerbyshireCommented:
I'd be surprised if it was propagated worldwide in 30 minutes. These things tend to spread outwards around the world. I've had DNS changes that took over a day to completely propagate. I'm just suggesting that emails sent within a certain timeframe (again, I'd suggest a period of one day since the first change) could be misrouted as the sending servers might pick up the older MX record.

Of course, it could be something else completely. But if it's all working okay now, then I'd suggest this kind of delay as a possible cause for it previously going wrong.
0
Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

 
YortAuthor Commented:
LeeDerbyshire - Unfortunately, all is not working OK.  But I never changed the original MX record, thus, propagation shouldn't be an issue in this matter.
0
 
Simon Butler (Sembee)ConsultantCommented:
DNS propagation - that doesn't exist.
No such thing.

There is only one thing that has to propagate worldwide and that is name server changes. If you didn't make a change to the name servers then that shouldn't matter.

The only thing that has to propagate is between the DNS servers of the DNS host that you are using. I would be surprised if that has happened here.

Therefore it is perfectly possible for a DNS change to be fully effective in 30 minutes. It depends on whether the remote side has cached the information or not.
It is that cache that people are referring to when they talk about propagation - where the DNS information is cached either on your own DNS server or another server that you are using upstream. Depending on the cache configuraiton it can take 48 hours before the change is fully effective.
If you know that you are doing a change in advance, turning the TTL time down on the record can help, but not everyone follows that.

To answer the specific question, this is a common misnomer. MX records as far as I am concerned are equal, the cost means nothing. Servers will deliver to all hosts in the MX records. You need to ensure that any "backup" server is either able to cope with the traffic and know what to do with it, or isn't responding at all, therefore forcing the sending party to use the other host. Spammers will actively target higher cost MX record hosts, because they often have less protection because of the misunderstanding aobut MX record behaviour.

Simon.
0
 
YortAuthor Commented:
Sembee2 - thank you for your reply.  What you say makes a lot of sense in that the e-mail being delivered to the backup server is all spam.  What, in your opinion, is the best way to make the server not respond?  The options I see are:  Leave the second MX record in place and stop the backup server mail service, or remove the second MX record and leave the server online.  Thoughts?
0
 
Simon Butler (Sembee)ConsultantCommented:
Take out the MX record.
Another option I have used in the past is to use a dynamic DNS service.
While you are live, the dynamic DNS points to the same IP address as the "real" MX record. However if the server or link goes down, then you can switch the MX record to point to the backup service. Due to the nature of dynamic DNS services, that change will be live within a few minutes, without having to wait for cache to update.

Simon.
0
 
YortAuthor Commented:
Simon - Thanks again.  I opted to take the second MX record our and leave the backup server live.  Should the main server fail again, I can quickly add the second MX record.

Appreciate your insight.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

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