E-mail being received up to 18 hours after it was sent


Over the past few days, users have made comments on e-mails which have been delivered to them, but the 'sent' date and time are from the previous day. I have 2 examples:

1 - sent 20/04/2009 @ 17:15. Received - 21/04/2009 @ 11:18
2 - sent 20/04/2009 @ 16:31. Received - 21/04/2009 @ 14:31

I have run searches on Surfcontrol E-mail filter and they're shown as being received on the times that we received them.

Do you know of any issues which would cause this? It only happens a handful of times per month, but I want to find out if it's a problem our end or if it's externally with the senders.

I don't think it's our server as the e-mail filter is running fine and if any messages are isolated, I have to release them from the queue before a user gets them.

I'd appreciate any comments, ad if any of you have experienced this in the past.

Thanks in advance!
Rob SamuelIT ManagerAsked:
Who is Participating?
you would have to ask their mail admins if they are

you can't - geylisting is an anti-spam technique implemented at the reciever's side that refuses the initial attempt at sending, forcing the sender to retry. It is effective because most spam engines aren't rfc compliant and will not re-queue a failed attempt for later

only way to find out if someone is greylisting is to ask them, after you start seeing delivery problems with their site
This sounds like your ISP or external company is queuing mail. Have you spoken to them about this yet?

Also do you use an external company to scan your mail before it comes in? If so have you made any changes recently? I would speak to them first
There is a connectivity problem soewere between the originating system and your own - this is causing mail to queue up for several hours before it is being delivererd

have you investigated the smtp headers to see the route the problematic mails have taken to get to you? The headers should also show you where the delay occured
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

Rob SamuelIT ManagerAuthor Commented:

Apologies for the delay in response - been a busy few days here. I've spoken to Skynet who we have our domain with and they seem to be getting 'message deferred' errors every now and again - which seems to affect messages which arrive 24 hours after being sent. Could you have a look at the text below and let me know your thoughts.

What could I do to resolve this error, as some of our consultants are receiving delayed e-mails.

As your server is the primary mx, emails to xxxxxxxxxx.com will only go to our servers if there is some sort of problem with yours. I can see the email from xxxxxxxxxxxx@sky.com coming in at 16:31 yesterday:

Apr 20 16:31:39 vulture sm-mta[85664]: n3KFVcO4085664:
from=<xxxxxxxxxxxxx@sky.com>, size=3469, class=0, nrcpts=1, msgid=<b55055a00904200830i503c52ep2e325afe21599ed8@mail.gmail.com>,
proto=ESMTP, daemon=MTA, relay=ey-out-1920.google.com []

After that, your server reset the connection as I can see several entries like the following:
Apr 20 16:55:29 vulture sm-mta[93770]: n3KFVcO4085664:
to=<ruth@xxxxxxxxxx.com>, delay=00:23:50, xdelay=00:00:00, mailer=esmtp, pri=123469, relay=[], dsn=4.0.0, stat=Deferred: Connection reset by []

Apr 21 13:52:37 vulture sm-mta[3637]: n3KFVcO4085664:
to=<ruth@xxxxxxxx.com>, delay=21:20:58, xdelay=00:00:00, mailer=esmtp, pri=3633469, relay=[], dsn=4.0.0, stat=Deferred: Connection reset by []

Until it was eventually delivered today at around 14:31:
Apr 21 14:31:05 vulture sm-mta[15375]: n3KFVcO4085664:
to=<ruth@xxxxxxxxxx.com>, delay=21:59:26, xdelay=00:00:00, mailer=esmtp, pri=3723469, relay=[] [], dsn=2.0.0, stat=Sent

I look forward to your comments,

Thanks in advance,
looks like they are greylisting at the receiver's end
Rob SamuelIT ManagerAuthor Commented:
so, xxxx@sky.com is greylisting our server?? How can I ensure our server is not greylisted anywhere? On MXToolbox, we're not on any blacklists.
Rob SamuelIT ManagerAuthor Commented:

Thanks for the comment, that makes sense as the delays are only occuring with a handful of domains. We are also getting a handful of 554 errors from domains as well - would that relate to the same issue?

Especially after moving offices (and IP addresses), our old IP is probably listed with the majority of domains. I've had our SPF records updated and a thorough test on MX toolbox shows everything looks OK.

Are there any alternative sites to MX Toolbox which provide a facility to test?
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.