I also went from 7242 but to 7503, I'd only read the changes to that point and was satisfied that there were no gotchas... so wrong. 7482 states 'Fixed: Some RBLs or URIBLs are taking an excessive amount of time to resolve, which causes spool delays.' My URIBL average times went up just like yours and after looking into the network communications I found that mailservice.exe spends an excessive amount of time trying to talk to a configured DNS server that spends most of its time offline. I’ve removed the IP address of the offline backup DNS server and times spent in spool have gone down from 20 minutes to 20 seconds.

My DNS offline/online configuration is nothing new so the difference appears to stem from the changes in 7482.

Dear support, I see that SM does its own DNS lookups rather than using the OS, there needs to be code that detects dead DNS servers and only retries them every xx minutes or on a service restart.

@Steve, that is a wonderful idea of retaining a copy of dead DNS servers with a limited retry or not until service restart. I have added this to our list.

I also note that SM does no honour OS level DNS server address changes, during a DR exercise I moved to a new DNS server IP address at the OS level (old server taken offline) which resulted in hours of mail issues until I noticed/restarted the SM service.