How long does MX record take to update?

My MX record for my domain points to IP of a smarthost in our DMZ that scans e-mail before delivering to our internal Exchange servers.

Since I will be putting a new/different smarthost up with a different IP, I will need to update the MX record to point to the new device.

Does anyone know how long that usually takes?
Since I can't keep the same IP for the new appliance (due to restructuring of our subnets), is there a way to make the process go quicker?
Or should we just expect downtime for e-mail for an hour or so?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

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.

Depends on the TTL value set for your domain in question. This value is in seconds. Other servers on the internet usually adhere to this value (if it says 86400, it means 1 day).
If this value is too high, and you have full access to all your DNS settings, first lower it to something you want, wait 1 day (or whatever the TTL setting was), THEN do the MX record change.
If you DON'T have full access to your DNS settings (hidden by your provider), and you can't get your provider to follow up on your request to change the TTL value, you're stuck to this TTL setting and you probably will have intermittent mail problems for about 1  day (or whatever the TTL setting was).

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
garryshapeAuthor Commented:
Network person says its 1 hour, but it says 900 seconds next to it.
Any harm in lowering it to like, 5 mins, or 300 seconds, for at least the day we plan to change the MX pointer?

Would it be better to add a 2nd MX record with lower priority and then be faster to change the priority for the day of change? That way we have a fall back plan if new appliance doesn't work properly?
Indeed, adding a second MX record is a good solution too.
The 7 Worst Nightmares of a Sysadmin

Fear not! To defend your business’ IT systems we’re going to shine a light on the seven most sinister terrors that haunt sysadmins. That way you can be sure there’s nothing in your stack waiting to go bump in the night.

garryshapeAuthor Commented:
Do you know how long a priority shift is to take effect?
Is it the same as changing IP of an mx record I guess?
So if we add a second MX record, pointing to new appliance, then on the day of change to use the new smarthost, we go ahead change the priority of mx record to go to the new smarthost.
garryshapeAuthor Commented:
Or, could you have two MX records with same priority, that way if something's wrong with one smarthost, at least not everyone will be affected. then we could change priority of the second mx record to lower so the one that is working will be used only.
Having the same priority is useful for 2 ONLINE servers. Since you are changing over, 1 will have downtime. If you set it at the same prio, the user will get a 50% (or even 100% during the physical change over) chance of failing, and will IMMEDIATELY get a NDR/bounce back. He will resend the mail again, and will end up with the same chances of the email getting through.
If you DO set the prio in a "normal" way, the mail will be held in the queue, and the user won't have to deal with NDR/bounce messages. If you move fast enough with the migration, you'll have the server online just before the other mail server's sending retry.
BTW, this is just an estimation of how mail servers will behave, as it's not always detailed how a particular mail server handles failures in relation to prios.
garryshapeAuthor Commented:
Sorry I mean I think we could leave them both online. They are both online right now, second one's just not in production.
In the end, we would be taking 1 online server down as we don't pay for support on it any longer.
If both are just as reliable, sure, make them same prio
Tracking errors and mail flow will be more complicated, as you need to trace two paths.
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.