Mission Critical Email
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 is the exact message? – always keep and forward a copy if possible
- if you did not get a bounced back message what was the exact date and time the message was sent and what was the recipeint’s email address?
- what is your outbound mail server configuration? – we need to know if you are using our mail servers or are you sending through another 3rd party?
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 show whether a mail server has been listed.
If there are no public blacklist hits then things get a bit more complicated. We then start looking for:
- an issue with the sending domain authentication records
- an issue with the delivery MTA (mail transport agent) requiring a delivery trace and checking of mail delivery logs
- or an issue with the receiving MTA, which unfortunately we have no access to or control of as they belong to recipient’s provider
On domain 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 things like DKIM, SPF and DMARC records added to a domains DNS entries. This is a little complicated and I won’t go into detail here – but it will suffice to say that most 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 always further information as to why the transaction failed or was refused – e.g. spam, malformed headers, other error code etc…
If the message was delivered through Cyanweb’s mail servers then checking of these 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. For us to help with your service issues we do need to host your web site and email services.
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 spam box, then this is usually where things go dark and the mail trail is often lost.
Without direct response and assitance from the receiving MTA server administrator, 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 can not track it anymore. 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 then the emails were just dissappearing. The client domain and email server were on no known blacklists, and even Microsoft’s own SNDS framework was showing the IP / Mailserver as clear.
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 rejected by Hotmail.com. All other senders on that mail server, with the same IP were having no issues whatsoever delivering to Hotmail.com.
The quick and easy solution turned out to be just switching SMTP outbound servers for the client.
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.