Bruce Johnson via bind-users <bind-users@lists.isc.org> wrote:- >Were 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 >Universitys 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 its been explained to me the main campus tenant cannot start accepting >email for our domain until weve transferred the email domain between >tenants, so we cannot just change the MX record in our DNS server to the >Universitys (a Cisco Ironport setup) This sounds plausible. Hope this helps. -- Best wishes, Matthew -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
