Outlook – Our outgoing emails are all being delayed

Dude! You broke my Outlook! I hadn't noticed anything wrong with it, until I read your post and was able to reproduce the exact behavior you described!

OK, so at first I was baffled. And then it occurred to me that the problem is due to operator error, triggered by poor UX design. (At least, that was my problem, and I assume you're in the same boat.)

The setting that I believe you are referring to is on the "Options" ribbon, in the "More Options" section: the button labeled Delay Delivery. Pressing this button opens a dialog that allows you to set the delay-delivery settings. What was not immediately obvious to me is that pressing this button ALSO automatically enables the delay (with a 5pm default time, as you said). If you close the dialog box at this point the fact that the email is now in the "delay mode" is indicated by the fact that the Delay Delivery button is now glowing gold. (The idea is that you can press the Delay button, then immediately press Close, thereby toggling the delay mode ON.)

To disable the delay mode, simply click that button again and uncheck the "Do not deliver before" box, then close the dialog. Notice that the Delay Delivery button is no longer glowing gold. Your email will be delivered immediately.

The mistake that we both made was that we tried to confirm that the delay mode was disabled by opening the dialog box and expecting to see the checkbox still unchecked. But the act of opening the dialog automatically sets that checkbox (as I explained above). So it looks like the value was never unset when in fact it was.

This is poor UX design, in my opinion, because it does not conform to the form & behavior of other similar ribbon buttons in MS Office. This button is acting like a "partial" toggle button. It should have instead been designed like the "Crop" button that is used in the "Picture Tools" Format ribbon: The top half of the button should be a toggle (press on/ press off), and the bottom half should open the settings dialog (with an inverted triangle on the button, as an indicator). Such functionality would be less prone to the confusion that stymied us.

Oh, and by the way, welcome to superuser!

Email troubleshooting can be divided into "sender" and "recipient" issues. Since you are able to send to other people the Sending side is probably working fine. You need to investigate the Recipient side to locate the problem.

Looking at the logs is a good step and can tell you where your messages are getting to and where they are not. Normal email flow goes like this:

1. You send from your email software to your server

2. Your server sends to their server

3. Their server sends to their email client

In this case you can see from the logs that their server seems to be

cluster5.us.messagelabs.com

Messagelabs is an email filtering service that is now owned by Symantec. Message filtering services like this are used to remove all the spam and junk email before the messages are sent to the client software. This means that any messages blocked by messagelabs will not turn up in any spam or junk email folders in the client software. They will just disappear and the recipient will never see any sign of them. On rare occasions they may get a message saying that "a message from someone@example.com has been blocked. Contact your IT dept to unblock it."

This sounds very similar to what has happened here. Technically you should get a bounce response from messagelabs like the guy in the link you posted but this is not guaranteed. They may just silently delete your message if they think it is spam. Usually messagelabs will provide an interface for the IT department at their customer where blocked messages can be released. You can ask your contact at the company to check with their IT team for any blocked messages from your email address. At least you can if you have some other way of contacting them!

Other useful general troubleshooting steps: If you didn't have access to the log files you can find out what the server should be for any domain by looking up the "MX records"

For example here: http://mxtoolbox.com/

The MX record is what an email server looks for to find out where they should send your email.

You can then initiate a manual connection to the server listed in the mx record to see if it is accepting email and what error messages you might get. Use a telnet program like Putty: http://www.putty.org/ and telnet to the email server on port 25. Some of the commands you will need are listed here: http://www.yuki-onna.co.uk/email/smtp.html

So now you can connect to their mail server and send an email using your email address as the "From" address and see how the server responds directly. Any email error codes that are returned can be looked up in google or here: http://www.serversmtp.com/en/smtp-error

Once you have checked that you can connect to the server it may tell you why your email is being rejected as spam or for some other reason, but the reason may not be easy to decipher. At this stage I would suggest you ask the messagelabs customer to contact their support number with the error codes (or lack of them) that you received from their server. Since you are not a customer of messagelabs you can't log a problem or ask messagelabs to check the settings on their customer's account. Their customer will have to ask that themselves. This would be similar for any other mail filtering provider.

Hopefully the error code would point you to a particular problem, like your server being listed on a block list or lacking a SPF record and you can fix that yourself because dealing with a mail filtering provider at third hand is never fun. The last problem I had like this took over three months to resolve before the fault was located and messagelabs fixed it.

I will defer to the answer by kubanczyk for details on SPF and DKIM settings because they seem to be much more knowledgeable than I am!

Good luck!