How to troubleshoot unreceived emails that do not bounce back?

First, I've been told that if an email is undeliverable, you always get a bounce back. In other words, the server tells you that it was unable to deliver the email and you are effectively notified that the person you were trying to reach has not heard from you.

I've also been told that spam catchers often just junk the email without notifying the sender. This, in my mind, qualifies as a delivered email, but the spam catcher just moves it to a junk folder.

Sometimes, however, you send an email and never get a reply. A week later you call them up and they say they never got it. You know this person. You've sent them emails before without an issue. Sometimes your "unseen" email was even a reply to their original email. So while you've got them on the phone, you send another, and they don't get it! What are you supposed to do?

To investigate, you might try sending emails to an from all address involved and then check if they are delivered:

1. from your primary to your friend's primary.
2. from your secondary to your friend's primary.
3. from your primary to your friend's secondary.
4. from your secondary email to your friend's secondary.
5. all the reverse orders on the above points, making eight total emails sent.

What can you do under circumstances where one or all of these eight test emails are unreceived and what does it indicate if no "undeliverable" message was returned? Where along the delivery path might the email be halted and how do you fix that?

In my specific circumstance, this has happened recently with two clients (business, so this is vitally important).

With the first client emails were tested:

1. me@my_primary.com to client1@their_primary.com - unreceived, no bounce back, not found in junk.
2. me@my_primary.com to client2@their_primary.com - unreceived, no bounce back, not found in junk.
3. me@my_secondary.com to clientany@their_primary.com - received
4. clientany@their_primary.com to me@my_primary.com - received

With the second client emails were tested:

1. me@my_primary.com to client1@their_primary.com - unreceived, no bounce back, not found in junk.
2. me@my_secondary.com to client1@their_primary.com - received
3. clientany@their_primary.com to me@my_primary.com - received

With both clients they have received emails before from my primary email address, numerous times, but now there was this problem. I suspect other clients have not received some emails because of their lack of response.

My primary emails are through a domain hosted on bluehost with a dedicated IP. According to Bluehost tech support, incoming emails are routed through this IP, but all of Bluehost's outgoing emails are routed through a rotating, proxy IP something or other. Basically, my dedicated IP is never even touched by outgoing emails. This means that outgoing emails are still susceptible to blacklisted IP's caused by other users not behaving themselves. According to Bluehost tech support, there was a slight issue around the time my failed emails were sent and not every domain with failed sends was receiving bounce backs. This could have been my issue.

There was a time when servers would try to bounce all failed email. (There was a time when you could more or less trust everyone on the net, or at least their system administrator.) Times have changed and the majority of email messages are spam.

Even when attempting to sent bounce messages there are conditions which prevent sending of the reply. These should mainly be problems with the originating domain.

The only safe time to bounce a message is before it has been accepted. Many servers accept all messages and only later verify whether they can deliver the message. Once the message has been accepted, it is likely the bounce will be sent to a domain that had their identity spoofed, and be considered back-scatter spam.

Another reason not to bounce messages, is to protect the list of valid email addresses. Bouncing message with no such user errors allows cleaning lists of potential email addresses. This simplifies targeted email campaigns which may be used for phishing.

Email that ranks significantly high on spam indicators is often just dropped. That is what happens to all the '419' scam messages I receive. Certain blacklists are considered reliable enough that your message may be just dropped.

Messages sent from a dynamic IP address is also likely to be dropped as the chances are well over 99% that it is spam. Sorry, there are a lot spambots out there on dynamic IP addresses. A static IP address with DNS passing reverse validation is likely to be valid.

Issues with delivery are best handled by working with your logs and their logs. You should be able to verify in your logs which server your message was delivered to. They should be able to verify from their logs what happened to your message.

There severs which will bounce your message back to you with various indications of the quality of your messages. For this to work you need to have incoming messages working. Then you can start working on outgoing messages.

I've posted somewhat extensively on Email. My article on Detecting Email Server Forgery lists some validation services. My original post on Running an Email Server is a bit of a rant as at the time I was dealing with a number misconfigured servers. Larger organizations are increasing applying policies contained in my http://www.systemajik.com/blog/email-policy/.

Converting some of my earlier comments to an answer, since I believe it is a good general initial step for both hosted and internally run servers:

You did the right thing by running the tests you ran; a concrete set of tests to isolate and reproduce a problem is always a good first step. A good next step in diagnosing this type of problem is to check the logs, although this is not always directly possible if you do not control your mail server.

If you run your own server, check the sending mail server's outgoing queue logs. See if there's anything of note. If you have control over the receiving server, check the logs there as well. The bounce emails you get (or don't get) are generally just a final "summary" of the status, more detailed, higher resolution information can usually be found in the logs.

If you don't run your own server, (e.g. in your case, since bluehost has control), the next step I'd recommend is to call your hosting provider's tech support and explain your situation, asking them if they have any additional logged details that can shed light. In addition, they may have knowledge of some other ongoing issue that is affecting you that you would not have been able to find out on your own - this is especially useful because it saves you the trouble of attempting to investigate a problem that isn't solvable by you. How you proceed further will depend on the results of that conversation.