Every now and then somebody will contact you via a method that they wouldn’t normally use and say something like “did you get the email I sent to you a few days ago”. If the answer to this is “no, I did not receive your email” then the following might be useful.
SMTP (Simple Mail Transport Protocol) servers, classically, should never blackhole email. To blackhole an email message, years ago, was a bad thing and meant that your mail server, or the recipient’s mail server was probably malfunctioning. A receiving SMTP server should either accept and deliver an email, or return a message to the sending server explaining why it was unable to deliver the email. Likewise, a sending SMTP server should either successfully transmit an email to a destination mail server, or deliver an NDR (non-delivery report) back to the user who tried to send the email.
Of course that was before spam became a problem. Now it is standard practice to silently drop emails in certain circumstances. However this does occasionally lead to the problems described at the start of this article. Spam is simply such a huge volume of email now that it would take significant extra server resource to deal with it according to the original “proper” SMTP methodology. You also don’t necessarily want a spammer’s mail server to know if an address they’ve tried to send to is legitimate or not – if they know it exists, or just that a particular internet server is an SMTP server, they’ll likely just send more junk to it.
Diagnosis and troubleshooting
So how to diagnose the “never received” email problem?
Firstly, ask the sender if they received an NDR. If they did, their mail system will usually have provided a log of the conversation when it was trying to talk to your mail system, and this will often be quite helpful.
If they never received an NDR, check your mail system logs to see if you can see any trace of their mail system trying to connect to your mail system. Many companies route all their email though a third party spam/malware filter (e.g. Symantec Email Security.cloud, Microsoft Exchange Online Protection), so this is a good place to start – if you can’t see any emails being received from your sender’s email address there then you can rule out any problems with your internal mail servers.
You can also use online tools such a the Microsoft Remote Connectivity Analyser or MX Toolbox to check that your mail servers (or a third party’s) are configured correctly. From a command prompt (on Windows) you can also get your MX records:
nslookup -type=mx rcmtech.co.uk 126.96.36.199
where 188.8.131.52 is a Google public DNS server, you can change this to use any DNS server you like.
Has the sender been blacklisted?
If a sender’s domain sends spam, or too much spam, it might be blacklisted. You can check this by using MX Toolbox and/or talking to your third party spam filter vendor. If a domain is blacklisted, spam filtering systems will frequently silently drop all (or most) mail send out from it.
Not all failures are bad
When using these tools, it helps to know a bit about how MX record preference values work, and tricks that mail filtering companies use to try and cut down on the amount of spam they have to process. Your MX (mail exchanger) DNS record will usually have more than one entry, because you’ll (ideally) have a primary mail server (or cluster of servers) and one or more lower priority servers in case your primary server is unavailable.
A sending SMTP server will use the lowest preference number server first. It will only use a server with a higher preference number if all lower preference number servers are unavailable or reject the message/communication attempt.
In the case of MessageLabs, the server addresses are actually server clusters. Also, the clusterna names are all spam traps, and will never accept any email. This is because spammers apparently often deliberately send to higher preference number servers because historically they might have no or less spam filtering applied to them, and they would normally only be used on the rare occasions when the primary server (lowest/lower preference number) was unavailable. No correctly configured/normally functioning sending mail server would ever pick one of the “a” servers. This is important to know because some SMTP testing tools will test all servers in the MX records for a domain, and so now we know that in the case of messagelabs.com servers, we can expect a failure from the clusterna server, but not from the clustern one!