However, if this setting is low but delivery is still taking upwards of a minute then check your average time in SETTINGS > ANTISPAM > RBL LISTS & URIBL LISTS (assuming that you are on a recent build of v16). If there is one taking longer than 1000+ ms that could be the culprit, and if they all are taking longer than 1000+ ms that is definitely the problem (I had this problem on an Incoming Gateway with Win2K8R2 Server where RBLs & URIBLs were taking 20,000+ ms, whereas on Win2K12 the same RBLs & URIBLs took under 70ms on the same network using the exact same DNS Servers...never did run the cause to ground although I pulled my hair out trying).
It certainly could also be latency from your DNS Servers, I would suggest running a DNSPERF and RESPERF to do the following steps from your Mail Server:
- Test the latency between the stub resolver and the DNS Resolver.
- Test the recursion between the DNS Resolver and the DNS Authority.
- Test the internal DNS Resolver delays.
If you have disabled all antispam checks and still experiencing slow delivery then the next thing I would check is your Peak & Avg load CPU and Memory usage. For an example, although the volume of our mail load has remained consistent over the years and our Avg CPU load has never gone above 3-5% we've had to add additional Incoming Gateways and upgrade them 4 times since SmarterMail 4.X to handle the ever increasing Peak demand on CPU & Memory which would top out at 100%...and still despite every upgrade our Spool still occasionally chokes @4 times a year due to Peak traffic resulting in 100% Peak CPU usage which causes delivery delays.
All in all, the problem you are experiencing isn't most likely going to be simple to find (although when all else fails, have you tested your network cable and tried using a different port on your switch?). Ultimately a 1m delay in delivery isn't terribly bad considering RFC allows up to 96 hours for email delivery (although I have seen overly zealous 2FA that are set to 60-120 seconds verification windows so that can definitely be a problem when delivery takes > 1m). When you are working on lowering delivery below 1m the task is challenging as it can be caused by many different things from you registry settings for your network stack, cabling, routing, DNS, CPU and more. You might end up having to install Wireshark on your Mail Server and taking a look at the packets to figure out where the delay ultimately is.