Hi. We migrated realfoods.co.uk to Cloudflare. All website functionality was fine. However, email functionality broke. Sending out from realfoods.co.uk mailboxes was fine. Sending in from all non-realfoods.co.uk mailboxes consistently failed with the following error:
“This is the qmail-send program at smtp2.interdns.co.uk. {IP} does not like recipient. Remote host said: 553 sorry, that domain isn’t in my list of allowed rcpthosts; no valid cert for gatewaying (#5.7.1) Giving up on {IP}.”
We left it for 8 hours, but these errors didn’t stop, so we had to abandon the migration. However, when we switched nameservers back to our old host, it took over 24 hours before the email problems stopped.
We’re used to DNS changes taking maybe up to an hour, but surely big companies which require email continuity migrate to Cloudflare and 24 hours seems excessive.
Now we wonder if the problem was we just didn’t leave it long enough. Is 24 hours normal for email DNS changes to stabilise?
Thanks for clarifying. I don’t think this will fix our issue though - because it was with receiving email, not sending - and our mail DNS record wasn’t proxied.
Also - any ideas why there would be a 24 hour delay after we switched back our nameservers before our email started working again properly. I would normally expect 15-60 minutes maximum for nameserver changes to be picked up.
Nameserver changes can take up to 48 hours and the time is dependent on both TTL and caching by third-party revolvers. It is not something that should be done casually. Pausing Cloudflare is far more predictable and expedient when troubleshooting.
Thank you for your reply. I know theoretically it can take up to 48 hours, but practically it seems to be more like 30-60 minutes at most. I agree nameserver changes shouldn’t be done casually. Is it normal for email records to take longer to change? Our TTL was always set to a fairly short timeframe - certainly < 1 hour for all records. I guess there’s no other way to speed things up?
It is easy enough to check DNS in real time as long as you know which servers to ask. That can be a helpful way of identifying why unexpected results are occurring. There is good documentation on eliminating or minimizing downtime.