What diagnosis steps can I do if my emails send, but are not received, not even as spam?
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:
You send from your email software to your server
Your server sends to their server
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 [email protected] 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!
Your outbound SMTP logs indicate that the destination accepted the message. If the destination mail server is kind enough to send a bounceback for any reason, that's all you get. Aside from asking the client (who may not know) what happened to the email, there's not much you can do except guess. You might also be able to look at the transport headers on a message that you received from the client.
Here's a product data sheet for the MessageLabs solution (look at the control actions on page 2)
So this client's mail system is using an enterprise mail security solution, which offers potentially complex policies to block, deny, modify, filter, scan, redirect etc mail based on common factors like:
- Transport headers (Was this message scanned by another product? Has it been flagged for encryption? Is it signed? Do I trust the source mail system?)
- Recipients (Who is allowed to email whom?)
- Subject, attachment restrictions (Is 'V1AGArA' in the subject? Does it contain a .exe?)
- Restricted keywords in text?
- Has the text of the message been classified? (Was this message marked as abusive? Does it contain PII?)
The list goes on and on. I am not entirely familiar with MessageLab's offering, but I work with a similar product that the big bank's compliance, governance, risk, and IT security departments love because it allows those departments to filter, audit, archive, review, analyze, categorize, block mail with an extremely granular level of detail. A lot of our clients are legally required to do common things like:
- Quarantine inbound and outbound mail that can be in potential violation of financial regulations by redirecting the message transparently to the company's legal team to review and approve.
- Rewrite the participants on inbound or outbound messages based on the content of the message.
- Block the message from specific mailboxes based on content or keywords
- Redact and rewrite portions of the message based on document analysis
- Apply additional restrictions and control actions based on region. One example would be due to ITAR regulations a client of mine had. All e-mail from certain geographical regions needed to have extra deep-content analysis policies applied with large subsets of mail volume requiring manual approval to reach end user mailboxes.
And of course, since anything can and will happen in enterprise email, there's always the possibility of the destination mail server simply discarding your message and forging a 200 OK or 250 COMPLETED response to your relay. It happens... I know some clients who configured mail relays to route mail into a black hole relay to eliminate rogue routing loops. Enterprise mail is always fun :)
Update: This answer describes a way to get a diagnostic report on any email (the emails contents, headers and server setup). While very useful for improving my server settings, unfortunately even after fixing everything raised here, my emails still don't get through. I'll leave it here as others might have more luck than I did.
I found several free online email testing services. They generate a one-off email address, you send it an email then click a link, and it gives a report on how various known spam filters would rate that particular email.
They're generally designed for testing newsletters, but suited my purposes fine.
I didn't know which to try, but the first I tried - https://www.mail-tester.com/ - gave useful results.
I used a false [email protected] email account for these, because having a free service to test email accounts for spammyness then selling those email accounts to spam lists is too obvious a business model... :-)
The report gave me useful leads to follow. Here's their verdict:
Not bad. Some inboxes might still refuse you
5/10
And a screenshot of their diagnosis:
(the "message of body contains errors" isn't as bad as it sounds, it's just pointing out there's no unsubscribe link because it's falsly assuming I'm testing a newsletter)
This is what I was looking for: actionable things to try and fix, in the absence of any failed delivery notice.
So I'll now investigate why my email addresses point to the master VPS hostname vps.my-domain.com instead of the mail server hostname mail.my-domain.com, and I'll investigate why the SPF entries - which I set up months ago and which MX tools say are fine - have not fully propogated.
This in particular looks like the root of my particular problem: a quirk of the server configuration that, I imagine, some configurations will consider irrelevant and some will consider fishy:
Update...
Bad news... I've fixed all the issues raised in the Mail Tester report (for anyone interested, see my Server Fault questions about the HELO address issue and the SPF propagation issue). My emails now get a perfect 10/10 from Mail Tester...
Wow! Perfect, you can send
10/10
...but my emails still aren't received by this one weird domain. I'm starting to think I must have somehow been added to an organisation-specific blacklist (maybe someone hit the "spam" button by mistake instead of "reply" or "archive"... not sure if that would explain this?).