We ran into an interesting issue with a client the other day, one that had an easy solution – but highlighted the problems with people using free email services such as Outlook.com / Hotmail.com / Live.com / Yahoo.com / Gmail.com.
People that use free email for business use are setting themselves up for issues. Free email providers are not reliable and can cause problems for both inbound and outbound mail.
So what happens if your business email is rejected for delivery by one of these giant email providers? What can you do about it? Where does one trace the problem to? Who do you contact to resolve the issue?
When a business can not get their email through to a “free mail service provider” the person using the service will always blame the sender stating “I can get email from other people – so it has to be your end”…. this is an oversimplified view and the reality behind email delivery systems are much more complex.
Every so-often, a client will contact us saying something like “our email is not being received by clients at XYZ.com free email provider”. As their web site hosting provider, we are usually the first point of contact when anything goes wrong – and the detective work begins…
The first step is to gather more information from the client:
- Did the email bounce back with any error messages? If so, what was the exact error? Always keep a copy of the error message.
- If you did not receive bounce back or error message, what was the exact date and time the original message was sent, and what was the recipeint’s email address?
- What is the sending outbound mail configuration? We need to know what mail servers your are sending your mail through.
The next step is usually to check if the client domain / email server is listed on any common blacklists.
Blacklists are publically available lists of mail servers that have been known to send spam. These have varying degree’s of accuracy / relevancy and it is up to individual mail server administrators as to which lists should be used to filter / block email from being delivered. A quick check at mxtoolbox.com and multirbl.valli.org will usually show whether a mail server has been listed.
If there are no public blacklist hits then, things get a bit more involved. We then start looking for:
- any issue with the sending domain authentication records
- any issue with the delivery and receiving MTA’s (mail transport agent) requiring a delivery trace and checking of mail delivery logs where possible. We can not check logs on 3rd party services such as Google or iiNet.
A litth about domain level email authentication:
More and more mail service providers are requiring “domain level” authentication of email being delivered. These systems were created to reduce the amount of spam reaching inboxes and include specifications such as DKIM, SPF and DMARC records. These records are added to a domain’s DNS entries. This is a little complicated and we won’t go into detail here – but it will suffice to say that quite a few delivery issues can be attributed to issues with these records. If these records are all in-order than we need to look elsewhere for the cause. [more info on DKIM, SPF and DMARC here]
Transport Level Logs
MTA issues arrise at the mail transport level. Basically, when an email is sent out via our mail SMTP servers, it is first authenticated by a user account (to check if that person is allowed to send email via our servers) and then sent out to a receiving MTA (the recipient’s mail server). If there are any issues such as failed connections, rejected mail delivery, message considered SPAM then there is a logged entry locally of the MTA transaction.
A successful transaction or “handover” of the email from our server to the receiving MTA is logged as “accepted” or “rejected”. If rejected there is almost always further information as to why the transaction failed or was refused – e.g. spam, malformed headers or other error code.
If the message was delivered through Cyanweb’s mail servers, then checking of mail logs by our team is fairly straight forward. If the email is being sent via a 3rd party service or server then the client will need to contact that mail service provider for support.
So what happens if the sending MTA says the email was “successfully delivered” from the delivering server but the end user does not receive the message?
If everything is ok with the domain authentication (DKIM SPF and DMARC), and the domain and IP are not on a Public blacklist, and the MTA says the email was successfully delivered AND the email is not in the recipient’s email or spam box, then this is usually where things go dark and the mail trail can be lost.
Without direct response and assitance from the receiving MTA server administrator (i.e. Google or other receiving mail provider), not much more can be done. With free email service providers there is little chance of getting any information from the receiving MTA as to what happened to an email after it was delivered to them.
Once an email leaves our servers as “successfully delivered”, we are usually unable to track it further. This is where mail delivery becomes 100% out of our control and is the responsibility of the next MTA agent in the chain. So if everything is in order our end then the fault lies with the free email provider – though we can still try to find a solution.
For example, in a recent client case, an email sent to Hotmail.com was successfully delivered from our mail server to Hotmail.com’s receiving MTA without error or rejection. This means the email was accepted for delivery, was not blocked or spam filtered and marked as accepted. From there, once in Microsoft’s hands, the emails were just dissappearing. The client domain and email server were not on any known blacklists, and even Microsoft’s own SNDS framework was showing the IP / Mailserver to be clear and without issue.
In this case – which is extremely rare to see – there was absolutely no explanation in all the log records our end, nor from Microsoft as to why emails from a specific client on a specific domain and mail server were being accepted by Hotmail.com – then sudenly dissappearing. All other senders on that mail server, with the same IP were having no issues whatsoever delivering to Hotmail.com.
Mission Critical Email
If your business web site or local systems deliver mission critical emails such as order notices, invoices or other electronic digital marketing (EDM’s) that send to Free Mail providers, you may want to look at specialised STMP mail delivery services. Just because your email is marked as sent, doesn’t always mean it’s arriving at it’s intended destination.
Cyanweb Solutions now offer dedicated SMTP solutions via a parnership with SendGrid. Have a look at our dedicated SMTP services to see if they might be of use. As always, we are here to help with any questions or problems you may have.