Email migration and MX records

[Matthew Richardson]

Bruce Johnson via bind-users <bind-users at lists.isc.org> wrote:-

>We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain.

This is probably more of an email than a DNS question.  In any event, I
have reasonably regularly undertaken such moves for clients.  You are
correct that the email often cannot be setup on the system until it is
removed from the old.

Trying to achieve this with a simple MX change WILL result in some email
being rejected/bounced.

>In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well )

Sensible...

>Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address?

Depending on what you mean by "bogus", this approach has the scope to end
badly.  It might work, but it might not.  Furthermore, you will not know
whether is did work or not.  Indeed, different senders may produce
different results.

An approach which should cause queuing (which I do not recommend) would be
to have a hostname & IP as the MX, which is under your control and which
does NOT have an SMTP server running.

>Or are we approaching this in the wrong way?  Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly.

You have correctly identified "we want to stop accepting email from
anywhere until the whole process has been changed".

My approach, as has been suggested by others, is to have a temporary email
server as an intermediate MX (ie only ONE MX server), which has a hard
delivery rule to the real OLD mail server.  In order for this to work, the
old and new mail servers have to be configured not to do any DNS based
processing on messages from the temporary server; specifically not SPF or
DNSBL.

Just before the migration, configure the server not to deliver the email
but hold it in a queue.

When the work is complete and tested, configure the temporary server to
deliver email to the new mail destination.

Once dequeued and everything is working, change the DNS MX to point to the
new destination.  After TTL expiry (plus a bit), remove the temporary
config re SPF etc from the new server.

Doing this fairly often, I keep a temporary server for the purpose, in my
case a fairly simple Postfix configuration.  This also allows one to see
all the logs and (if one wishes) take copies of emails in transit to assist
with troubleshooting or for resubmission.

>As it’s been explained to me the main campus tenant cannot start accepting email for our domain  until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport setup)

This sounds plausible.

Hope this helps.

--
Best wishes,
Matthew