How not to set up your DNS (part 24)
I'll start with the traditional illustration of DNS results:
; dig +short mx officedepot.se. 50 odmailgate.officedepot.com. 40 officedepot.com.s10b2.psmtp.com. 30 officedepot.com.s10b1.psmtp.com. 20 officedepot.com.s10a2.psmtp.com. 10 officedepot.com.s10a1.psmtp.com.
What I can't easily illustrate is that none of the hostnames under
psmtp.com exist. Instead, it seems that officedepot.com has shifted
its current mail handling to outlook.com, based on their current
MX. While odmailgate.officedepot.com resolves to an IP address,
18.104.22.168, that IP address does not respond on port 25 and
may not even be in service any more.
(It is not Office Depot's problem that we're trying to mail officedepot.se, of course; it is due to a prolific spammer hosted out of scaleway.com that is forging the envelope sender of their spam email from 'bounce@<various domains>', including officedepot.se and 'cloud.scaleway.com'.)
This does point out an interesting risk factor in shifting your mail system handling when you have a lot of domains, possibly handled by different groups of people. In an ideal world you would remember all of the domains that you accept mail for and get in touch with the people who handle their DNS to change everything, but in this world things can fall through the cracks. I suspect it's especially likely to happen for places that have enough domains that handling adding and removing them has been automated.
(It's been a while since the last installment; for various reasons I don't notice other people's DNS issues very often these days. I actually ran across a DNS issue in 2017 that I was going to post, but I ran into this issue and never finished the entry.)