Delayed Email Delivery


I have an issue where from select domains, occasional emails are being delivered several hours after being sent to us.  We have an Exchange 2010 server with its anti-spam in place, Trend Micro's ScanMail 12 installed on the Exchange server, and a SonicWALL firewall.  We have no cloud solutions in place.  When I look at the message header info, all it shows is a time difference between when the sender sent it and Exchange received it.  In most cases, the senders are not getting any type of delay message sent to them.  As it is so sporadic, it is very hard to troubleshoot (as I can't automatically replicate the issue).  I don't have any deep inspection/quarantine zones in place, at least not ones that would automatically release the email after some time.  The header info usually shows that the SCL is 2 or less.

I'm hoping that someone can give me a suggestion or two as to where I need to look.

Any help will be greatly appreciated.

Thank you,

Who is Participating?
JerAuthor Commented:

It appears that the issue is likely due to the senders.  As I've been collecting info, I'm finding that most of the sending servers are on at least one blacklist.  I didn't find this to be the case initially, as many of the emails that I was researching were a week old or older.  It is possible that the server was being delisted.  As previously mentioned, I'm finding that over half of the delayed emails are from a Google email server, so I can't just allow the IP(s).  Anyhow, I do think that it is weird that the emails are delayed, but not rejected.  However, as the last 5 different delayed senders have all been blacklisted, I don't think it is coincidence.  None of our AV products would hold an email for further inspection, but our network router/firewall does use RBLs, so that may be coming into play. Using (Message Header Analyzer) and MxToolbox has been very helpful.  Anyhow, thanks for the input and assistance.
☁ François Peroux ☁Infrastructure ConsultantCommented:

Any chance with the ScanMail 12 to have more details from the logs ? Maybe those emails are analyzed before delivered and could cause this time lapse ?

Since when you have this issue ? Any change on your configuration ?
JerAuthor Commented:
Been looking at the logs, but they have not suggested anything.  Users didn't initially communicate this, so it is hard to know when it started.  However, I do not believe that there have been any changes to our environment.  If it was our AV, I'd expect a flat quarantine/rejection.  Same with Exchange and our firewall.  Basically, it should be all or nothing.  One of our IPs was showing up on 3 Blacklists for a period, so that could have come into play, but I'd expect that to be an all or nothing issue, too.  The fact that we're receiving the emails expected, but just delayed, is the issue.  And it is just a handful of users/domains.  I've run message header analyzers, but they have not provided any indications of the issue.  They basically just show a long delay for the last hop (external email server -> our internal email server IP).  We don't have an SPF record, currently.  Not sure if that would come into play, as I'd again expect it to be an all or nothing situation.


Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

J SpoorTMECommented:
I would look at the email's headers to find if the emails that get delayed take a similar path.
Sounds like some remote servers have issues sending the email the first time.
This could be due to grey listing or other mechanisms to block spoofers on your antispam solutions.

if this is the case, most likely these senders do not have proper SPF records or similar, triggering your antispam solution to not accept the email first time.

View example configurations and the SonicWALL webui and features on or

Multiply the effectiveness of your APT Sandbox, stop unknown and zero-day attacks at the gateway. See a demo on or

You can also view the Next-Generation Firewalls via or
J SpoorTMECommented:
Also make sure your own SPF records are setup properly.
How did you get blacklisted?
It's easy to get on, but hard to get off, and yes that has tons of impact in receiving emails...

If you have multiple public IP addresses, it's best to One-to-One NAT your exchange inbound and outbound to a unique IP address, make sure this matches your SPF records and vice versa.
JerAuthor Commented:
We got on a blacklist due to one of our users' profile was compromised by the Gozi Trojan.  Once I got that cleaned up, I monitored for 10 days and then de-listed us.  We have been fine since.  We do have unique IPs for outgoing and incoming IPs, so damage was minimal.  The issue was that the attack doesn't use port 25, so it was going out our firewall's IP.  Anyhow, I do plan to make an SPF, but as I haven't done it before and have to take into consideration our secure email product (Zix Corp), I've been just collected info on it.  These email issues are escalating it, though.  I'll look through the links and see what applies.  My general position has been that its the sender and not us, but I do want to make sure that I'm not sitting on a misconfiguration.
J SpoorTMECommented:
Here's a good tool to create the spf record.

What normally happens during an email communication, e.g. I send an email from to your

my email server will do an MX lookup for than establish a direct SMTP connection.
if this fails, my server qill put it in the queue and will retry later.

What is your MX record pointing to?
If it's poiting to your own network directly, it sounds like the remote servers are not able to deliver the email at first touch.

From the email header, you can see which paths it took. See if there's a pattern in there and if there's an inbetween MTA agent which is causing the grief.
J SpoorTMECommented:
also check if your antispam solution has an outbound anti-zombie protection mechanism to prevent such issues.

good practice is to have your LAN users and your Email server go out of different public IPs. And only allow outbound SMTP from the email server. This so that an infected enduser will not put you on a blacklist :)
JerAuthor Commented:
Not abandoned.  People go on PTO and work on other items.  That said, I've checked through all of our AV, firewall, and Exchange products/services.  There is absolutely nothing that would hold an email for 1-6 hours.  Everything is either allowed after initial inspection or rejected after initial inspection.  Out of a handful of impacted senders, I'm seeing that half are using Google servers, so there is something there.  I'm implementing an SPF record today.
JerAuthor Commented:
Not really resolved, but the evidence suggests that it is out of our control.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.